On Dec 14, 2010, at 7:01 PM, Les Mikesell <lesmikes...@gmail.com> wrote:

> On 12/14/2010 5:14 PM, Markus Falb wrote:
>> 
>>> 
>>> But this only helps if you don't know where you will need to grow.  If
>>> you know it is going to be under /var, just give it all the space you
>>> have in the first place and avoid the overhead of lvm.
>> 
>> To quote Jason, the OP: "what should my SWAP space be" ?
>> How should I know ? lvm to the rescue.
> 
> I've never seen a machine that had pushed 2 gigs into swap recover (i.e. 
> whatever was consuming the memory did it faster than jobs could complete 
> and release any).  Increasing performance might have saved them but not 
> adding more swap.
> 
>> lvm also helps if you want to have additional partitions. Maybe one day
>> you recognise that a separate partition for /var/log/httpd would be a
>> good thing.
>> 
>> You are talking about the performance overhead ? Not sure about that. I
>> think the flexibility you gain makes it at least worth thinking about
>> it. Said that, I would be interested in hearing about disadvantages of lvm.
> 
> It really depends on the purpose of the machine.  If it has to be a high 
> performance server, I wouldn't want any extra overhead and I certainly 
> wouldn't want bits and pieces of a partition to be spread into chunks 
> far apart on the disk.  It would be even better to put the busy content 
> on separate drives to avoid seeks as much as possible.

LVM overhead is negligible. It is basically a kernel mapping of virtual memory 
space into 4MB+ extents across drives.

It basically has the same overhead as Linux's virtual memory subsystem.

The chunk size is configurable and chooses a sane default of 4MB (very large 
VGs use larger extents), you can implement striping within using configurable 
stripe sizes. And if max sustained throughput is your goal, set the extent size 
to 16MB or stripe across multiple drives.

-Ross
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Reply via email to