You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@kafka.apache.org by yazgoo <ya...@gmail.com> on 2016/02/11 16:24:16 UTC

LVM overhead

Hi everyone,

I have multiple disks on my broker.
Do you know if there's a noticeable overhead using LVM versus multiple
log.dirs ?

Thanks

Re: LVM overhead

Posted by Jens Rantil <je...@tink.se>.
Hi,


I suggest you run a micro benchmark and test it for your usecase. Should be pretty straight forward.




Cheers,

Jens





–
Skickat från Mailbox

On Thu, Feb 11, 2016 at 4:24 PM, yazgoo <ya...@gmail.com> wrote:

> Hi everyone,
> I have multiple disks on my broker.
> Do you know if there's a noticeable overhead using LVM versus multiple
> log.dirs ?
> Thanks

Re: LVM overhead

Posted by Pete Wright <pw...@rubiconproject.com>.
There will be some slight lvm overhead, depending on your configuration,
but in my experience it will be negligible.  I would suggest avoiding
creating *any* snapshots when using LVM though as that will decrease
performance pretty quickly.

For kafka it is unlikely you will want to create any snapshots of your
datastores - so you will probably OK.

In my environment we use an HBA with a baterybacked cache, then create
RAID-10 volumes in hardware.  Then we overlay XFS on top of that volume.
 This seems to be a pretty optimal configuration in our environment as
we can obtain greater IOPS from a RAID-10 volume as opposed to what you
would get in a single disk (and the battery helps reduce the likelihood
of data corruption in a power failure event).

LVM will give you bit better perf in theory as well (assuming you create
a stripe of disks) although there will be greater overhead managing the
stripe in software as opposed to hardware.

Hope this helps!

-pete

On 02/11/16 07:24, yazgoo wrote:
> Hi everyone,
> 
> I have multiple disks on my broker.
> Do you know if there's a noticeable overhead using LVM versus multiple
> log.dirs ?
> 
> Thanks
> 

-- 
Pete Wright
Lead Systems Architect
Rubicon Project
pwright@rubiconproject.com
310.309.9298