Re: [tlug] Disk I/O bottleneck: how to solve?

["Jonathan Q" <jq@example.com>]

On 9/4/2002, "Jean-Christian Imbeault" <
>
>I don't think there is any thrashing going on. It's a web server and I
think
>there just are too many requests coming in.


OK, in that case, it's possible that you just aren't keeping enough spare
Apache processes in reserve. As I'm sure you know, Apache forks off processes
to handle new connections, and keeps several standing by as spares.  You might
want to take a look at your settings for minimum and maximum number of spares
in httpd.conf and adjust those to see if it improves your performance
(increase the numbers, of course, don't shrink them :-).  Be aware that this
will use up more memory, but IIRC you are OK on memory right now.  However,
keep tabs on memory use as you experiment with the number of Apache spares.

As Shimpei (I think?) noted, separating the content from the log disk will
also help.  If you can't put another disk in the machine right now, consider
using an external log host.  If you have another machine in that location and
it has adequate disk space, you can use it as your log host. 

If you don't want the log packets going out the same interface that apache
binds to (will mess up your MRTG readings), you can put a second NIC in each
box and I think you can bind syslog to the address of the second NIC (don't
promise; I've never tried it and feel too lazy to Google right now).

Another thing that may help in addition to the above is to remove the CD-ROM
drive and put a second disk on other ATA header and run them as RAID 1
(mirrored), while still logging to an external log host. This won't help your
disk writes any (in fact, they will take longer), but it will cut the read
times by about 50% because it will read half the data from each disk, in
parallel, then assemble it into the whole.

That will also help you a lot in the event of disk failure, since a disk
failure in RAID 1 means you just run off the other disk until you can replace
it and rebuild the mirror.  A disk failure with the current single disk means
that if your web server goes down with a disk crash, it's going to stay down
for a long time while you get a new disk, reinstall the OS, apply the security
updates, and restore the web content from backup.  If you're lucky and it does
it at the start of your work day, you might finish the job by the end of the
business day. That assumes you have the disk already, the install media, the
restore media, and you're ready to go pretty quickly.  If you have to go buy a
disk and gather up the stuff, it's going to take longer.

Jonathan


GPG key: DF12B4EF (5399 C834 3ABB C3AF 610C  5345 D5D6 E6EA DF12 B4EF)
gpg --keyserver pgp.mit.edu --recv-keys  DF12B4EF