On Thu, Apr 28, 2005 at 10:17:24AM +0100, Brian Candler wrote:
> > avg-cpu: %user %nice %sys %idle
> > 15.24 0.00 4.25 80.51
> >
> > Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
> > dev8-0 73.47 497.85 171.52 3772606540 1299741856
>
> 73 disk I/O transactions per second is pretty busy.
73 tps is no problem, but unfortunately either iostat or the kernel is
not recent enough to show the amount of iowait time, so you can't tell
where exactly this machine will slow down due to disk I/O.
100 tps tells you that there will be a problem RSN and >120 is pretty
much the limit on random traffic.
Get rid of that single disk and use RAID10, software or hardware. This
single disk will die eventually and cause grief to everybody. I suggest
a stripe size of 32k and a block size of 4k, because that way, you can
create the filesystem with a block group size that does not part the
sum of all RAID0 stripes. Example:
4 disks and RAID10 = 2 RAID0 stripes = 64k = 16 blocks
Now 16 would part the default group size of 32768 blocks, so choose
32760 blocks and the beginnings of all block groups will spread over
both RAID0 stripes. You will notice the effect particularly on
rather empty disks and during fsck.
> Or go for something more efficient. For example, you can get Exim to deliver
> in Maildir format, and then use courier-imap as the POP3 server. That's a
> major redesign in your system though.
Indeed, but it is the most reasonable thing to do to resolve the locking
problem. It also opens the door to IMAP, and once users learn what
IMAP can do for them, they usually stop using POP. A POP-only service
is not going to suffice in the long run. Offering IMAP allows running
a web-based client, like squirrelmail, and folders for spam mail and
mailing lists, something people will ask for eventually.
Michael