Web Hosting Talk







View Full Version : Slow writes of files in RHL 6.1


DavidH
04-22-2001, 08:04 PM
Hello,

Am hoping someone has a quick fix for this one :D

We are moving our clients from a set of servers to another set of servers with a different company.

Both servers are RHL 6.1

The only key item I see right now is the new servers are much much slower at writing files.

Example. I do a vi httpd.conf and edit this file. It is roughly 300k.

It will take about 4 to 5 seconds to save the file.

On the old set of servers, I edit this same file, and it when I go to save it via vi, it saves immediately (no delay).

This is a RHL 6.1 setting? If so, could someone let me know what I need to change to fix this?

This seems to affect Perl scripts that write log files, esp when they are getting above the 500k mark (which really isn't all that big for a log file).

Thanks for any information!

David

JTY
04-22-2001, 09:32 PM
What OS are the old servers? Is the new server SCSI, or IDE? And, was the old server SCSI, or IDE?

DavidH
04-22-2001, 10:17 PM
Both servers are Red Hat Linux 6.1 and are SCSI drives.

The old servers are at Alabanza...

The new servers are at Dialtone...

David

JTY
04-22-2001, 10:40 PM
Hmmm, then they should perform pretty much the same.

Steve33
04-24-2001, 10:25 PM
I had the same exact problem with Dialtone. When the server was first setup it was writing about 10 times slower than the server I moved from and the Dialtone server had more processing power and more ram. Kyle in support was very responsive to the problem and did try to help, he did manage to get the speed a lot faster, although it is still writing about twice as slow as my old server. Below was his response/fix to the problem. I believe the reason why it is still slower is the fact that they use RAID1 which has to write to 2 disks, thus it takes twice as long.

Here's what he had to say:

The problem was related to the 'sync' flag we set on all root filesystems
(and on HW-RAID, it's just one big root system).

The sync flag tells the operating system to synchronously write all data to
disk as it's received, and not to cache. This is good for data integrity,
but not speed.

I've removed the sync flag from the file system, which should speed up disk
writes humongously. You still may not see similar speeds to your old
server; according to the notes I'm reading, it's disk I/O bound, not CPU
bound, so more RAM means more disk cache means more speed.

DavidH
04-24-2001, 10:47 PM
Thanks Steve. Dialtone answered the same way for me yesterday about this. They showed me what to change in the /etc/fstab (going from sync to async).

That did the trick!

David

huck
04-25-2001, 08:40 AM
hdparm can be used to test read/write speeds of your drives. It also provides an interface to tweak some drive settings. Most of the settings are for IDE drives but there maybe some tweaks for SCSI drives. I know for IDE drives this can make read times go from a paltry 3 MB/sec to over 20MB/sec becuase linux often does not enable UDMA on the drive. I do not have a lot of experience tweaking SCSI drives using hdparm, so it may be limited. I do know that there are a lot of settings related to the drivers and SCSI cards that can make a huge difference in performace, but I've never used those either.

the command:
/sbin/hdparm /dev/hd[x]
where x is the device, e.g. hda
will give you all of the info on your drive.

/sbin/hdparm -tT /dev/hd[x]
will give you performance benchmarks for read times

You may want to make sure your drives are not spinning down and that power management software is turned off.

Also check out some server tune-up tips:
http://people.redhat.com/alikins/system_tuning.html


Processes and RAM
Although the server specs are the same, make sure they are configured the same. Check your process lists and make sure their are not uneccessary processes sucking up RAM. Linux is very sensitive to RAM with respect to disk-cache and will try to use as much RAM as possible to cache items. If your new box has a lot of processes sucking up RAM, then you will have a smaller disk-cache -- thus requiring more read-writes from the disk.