A quick and easy performance improvement

[Richard Lynch]

Julian Field wrote:

>
>
> Richard Lynch wrote:
>
>> uxbod wrote:
>>
>>> Why not hold the bayes on a RAM partition, and have a cronjob that 
>>> periodically backs it up throughout the day so that changes are not 
>>> lost if the server crashes ?
>>>  
>>>
>>
>> That would definitely improve things.  Seek time in RAM is zero!
>>
>> While monitoring disk I/Os (iostat 1) I was surprised at the high 
>> number for bayes.  I didn't expect to see it so high.  One my systems 
>> it was actually higher than the I/O for the mail queues.
>
>
> That's very interesting.
>
> Most people these days just use 1 big partition for / and nothing 
> else. So it won't be available to them. So why is this an improvement 
> when /var/spool and /.spamassassin are on the same partition? I can 
> see why, if they are on different partitions, though you're still 
> relying on the mapping of sector number --> physical hard disk 
> location. But if / and /var/spool are on the same partition anyway, 
> why would it run any faster?
>
I can't see why it would either.  If you're using one large partition 
changing the directory structure wouldn't be worth anything as far as 
performance goes.  In my case they are on different partitions.

> I am sorely tempted to say that you have merely cancelled out the 
> speed slowdown caused by splitting / and /var onto different 
> partitions. If they are both on the same partition anyway, and are 
> being written to a lot, they will end up very close to each other by 
> virtue of how the filesystem is likely to work.
>
> I think that splitting / and /var slowed your system down. You have 
> just cancelled that out.
>
> Thoughts?

I think you're right.  Is it uncommon to have / and /var on different 
partitions?   The sysadmins here argue for separate partitions because 
it lessons the likely hood of the rootfs filling up.  They say that it 
can hose your system to the point that you can't even logon to fix it.  
So, we split / and /var (and others).  I think all of our unix systems 
are that way.  Is this a bad practice? 

-- Rich

-- 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: rich.vcf
Type: text/x-vcard
Size: 308 bytes
Desc: not available
Url : http://lists.mailscanner.info/pipermail/mailscanner/attachments/20060726/b8649cc0/rich.vcf