A quick and easy performance improvement

[DAve]

Julian Field wrote:
> 
> 
> DAve wrote:
>> Richard Lynch wrote:
>>> 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?
>>
>> Maybe I am showing my ignorance but how? I'm not seeing any 
>> performance issues myself, just curious. I currently have bayes on one 
>> controller/disk pair and the queues on another controller/disk pair. 
>> I've always believed that to be about the best you could do.
> 
> On a different controller/disk pair you will get better performance as 
> you can read/write in parallel. But we were talking about putting the 
> whole setup on one disk where you have to read/write one at a time.
> 

I got on board after I sent the message, sorry about that.

>>
>> Of course it just takes 2 minutes in a terminal if I should move bayes 
>> to the same controller/disk as the queues.
>>
>>>
>>> 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
>>
>> I have always used separate partitions, though others who do as well 
>> have told me I am stupid because I use different partitions than they 
>> do, everyone has an opinion ;^)
>>
>> I keep separate partitions for the sake of fsck, performance be 
>> damned. I've lost data on the far side of a 70gb disk because I had a 
>> failure fsck couldn't fix, (SATA drives and a sad story). I've 
>> isolated /, /tmp, /var, /usr, /data ever since. I keep websites, 
>> backups, ftp directories, mail queues, etc in /data. Depending on the 
>> task the server is doing.
> 
> That's fair enough, that's your choice. Bad experiences with fsck will 
> change your way of working. Personally, I haven't had that trouble, and 
> I always have a reliable well-tested tape backup system in place to 
> handle that, so it's never bitten me badly. But you are quite entitled 
> to your own opinions based on your own experiences, I don't think anyone 
> could have a problem with that, except the trolls :o)

I had a tape once, the drive failed and after three months we never did 
get another drive to read the old tapes without errors. Never trusted 
tapes much after that. Certainly after HP said "Sometimes that happens, 
it's a head alignment issue. Have you tried another old drive?". Now I 
backup to a RAID, to each his own.

I love trolls, and lists that cover mail products attract so many! 
Though, oddly enough, this list doesn't... hmmmm... I have to subscribe 
to qmail/sendmail/postfix/procmail lists to witness really *good* 
flames. What am I to make of that?

DAve

-- 
Three years now I've asked Google why they don't have a
logo change for Memorial Day. Why do they choose to do logos
for other non-international holidays, but nothing for
Veterans?

Maybe they forgot who made that choice possible.