Koozali.org: home of the SME Server
Legacy Forums => General Discussion (Legacy) => Topic started by: kruhm on July 06, 2005, 05:27:34 PM
-
Maximize your hard drive's potential.
#PRE-POST NOTES
SME V6.0.1
IDE drives
intended for newer equipment (last 5 years)
substitute 'hdx' with your drive hda, hdb, hdc, hdd, etc...
nothing should go wrong but...
BACKUP BEFORE USING!
USE AT YOUR OWN RISK!
IF SOMETHING GOES WRONG YOU ARE RESPONSIBLE! NOT THIS THREAD!
#TEST HD
You can test your hd before you begin by doing a
hdparm -tT /dev/hdX
I get:
Timing buffer-cache reads: 128 MB in 0.14 seconds =914.29 MB/sec
Timing buffered disk reads: 64 MB in 19.78 seconds = 3.24 MB/sec
hmmmm... sluggish
#SEE CURRENT SETTINGS
by default the safest options are select during the SME install on an IDE drive.
You can look at your current settings by doing a:
hdparm /dev/hdX
I get:
/dev/hdc:
multcount = 0 (off)
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 24321/255/63, sectors = 390721968, start = 0
busstate = 1 (on)
#OPTIONS AVAILABLE
You can speed up your system by turning on some of the features on your hd.
You can see different features that may be on your drive by:
man hdparm
Basically the top 4,
multcount: Short for multiple sector count. This controls how many sectors are fetched from the disk in a single I/O interrupt. Almost all modern IDE drives support this.
I/O support: This is a big one. This flag controls how data is passed from the PCI bus to the controller. Almost all modern controller chipsets support mode 3, or 32-bit mode w/sync. Some even support 32-bit async. Turning this on will almost certainly double your throughput.
unmaskirq: Turning this on will allow Linux to unmask other interrupts while processing a disk interrupt. What does that mean? It lets Linux attend to other interrupt-related tasks (i.e., network traffic) while waiting for your disk to return with the data it asked for. It should improve overall system response time, but be warned: Not all hardware configurations will be able to handle it. See the manpage.
using_dma: DMA can be a tricky business. If you can get your controller and drive using a DMA mode, do it.
#CHANGE SETTINGS
People will argue over what's best here but basically I want (safe for most newer hardware):
hdparm -m16 -c3 -u1 -d1 -X69 -W1 /dev/hdX
-m16 -- Sets the number of sectors to use for IDE block mode (multicount)
-c3 -- Sets the I/O support (I/O Support)
-u1 -- Enables unmasking of interrupts. Greatly improves performance.(unmaskirq)
-d1 -- Enables DMA
-x69 -- Specifies UDMA transfer mode (change to your setting, see notes)
-W1 -- Enables cache writing on drive
#TEST HD AGAIN
You can test your hd after settings
hdparm -tT /dev/hdX
I get:
Timing buffer-cache reads: 128 MB in 0.13 seconds =984.62 MB/sec
Timing buffered disk reads: 64 MB in 1.14 seconds = 56.14 MB/sec
Now that's more like it.
#KEEP SETTINGS
You can test your settings but during reboot the settings don't keep.
We have to put them in /etc/sysconfig/harddisks in the 'EXTRA_PARAMS' line (see notes):
EXTRA_PARAMS="-m16 -c3 -u1 -d1 -X69 -W1"
#REBOOT
/sbin/e-smith/signal-event reboot
#FINAL TEST
Test to see if settings kept
hdparm /dev/hdX
I get:
/dev/hdc:
multcount = 16 (on)
I/O support = 3 (32-bit w/sync)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 24321/255/63, sectors = 390721968, start = 0
busstate = 1 (on)
Good, they kept after the reboot.
#THAT'S IT
you are done for the day. have a :pint:
#NOTES:
-You can find the DMA capabilties of your drive by doing a:
hdparm -i /dev/hdx (Notice the DMA modes listed; the * indicated the selected mode if UDMA is on)
-To enable UDMA, you use -Xxx where xx is the transfer mode.
Here's how it stacks up:
-X64 : UDMA 0 (ATA 16)
-X65 : UDMA 1 (ATA 25)
-X66 : UDMA 2 (ATA 33)
-X67 : UDMA 3 (ATA 44)
-X68 : UDMA 4 (ATA 66)
-X69 : UDMA 5 (ATA 100)
-X70 : UDMA 6 (ATA 133) (AFAIK only some Maxtor drives do this)
-the /etc/sysconfig/harddisks is for all HD's.
-you can have different settings for each HD by creating /etc/sysconfig/harddiskhda (hdb, hdc...)
-if you can't enable UDMA, some newer motherboard/chipsets aren't included in the default kernel (2.4.20)
-then upgrade to Sleepy's kernel (2.4.26) per his howto (fyi- this is single-processor only, hyperthreading won't work)
-I'm interested in what SATA drives get, please post your HD results.
-I've gathered the previous post from several sources, i'm no way an expert.
-This document is open for discussion & editing.
-Most posts concerning this are outdated or conflicting. I just wanted to provide some info for the general SME admin.
-
Thanks for the great hdparm lesson!
-
Yes, very good information - I am curious to check what the settings are for SME7 - I added a link to this thread on the Tweaking FAQ's page:
http://no.longer.valid/phpwiki/index.php/Tweaking%20FAQs#hdparm
-
FYI -Mark Lord, the author of hdparm, posted some good info recently reguarding hdparm & SATA drives.
SATA drives in the 2.6 kernel are handled by the new "libata" SCSI driver. If you add the "ATA passthru" patch (from Jeff Garzik) to your kernel, then hdparm can work with those drives.
Some flags, like "-d", are not supported by libata. Currently, ALL SATA hard drives use DMA, so there is no need for -d. But eventually libata will have to implement ATA PIO (for CF cards..), and at that time it may (or not) begin to support the "-d" flag.
http://freshmeat.net/projects/hdparm/
So i guess the question as hdparm relates to SME 7 is if the patch is in the kernel.
-
I was about to post a new thread request about how best to improve slow/poor sendmail performance on SME 6.01 until my search for 'performance' showed up this hdparm article. excellent.
We were on a SCSI drive on 5.5 a few years ago and then did a clean install to a Maxtor IDE for 6.01.
I was thinking that maybe the IDE drive is holding us back on a P3 933MHz, 1GB RAM machine. So thinking of restoring back to the formatted clean SCSI drive, to see if that helps sendmail performance.
Plus I have been having soooo many Maxtors go bad (about a dozen 120 and 160GB drives over the past year), that I'm getting nervous, since we only have file backup and no real drive image backup solution (i've tried looking and tried some, but no luck so far).
So my point is (sorry!) how many have run hdparm and made changes and have safely improved their SME server performance with this tweak?
Thanks.
-
I ran it on SME 5.5 and 5.6. Hard drive throughput would go from 2~3 mb/sec to the 20's. I usually have not needed to use it on SME 6.X. I usually test with and without the hdparm settings. Most of the time, things work great from the start.
Just a hint, if using software raid, don't add the settings to one drive and not the other. This really seems to mess things up. ;-)
I have stopped using maxtor drives since the 40gb series came out. They started using quantum's hardware starting at this point and their drives became junk, IMO.
I try to stick with Samsung, Fujitsu, and WD (jubilee series only). I like having the 3 year warranty. Yes, I know that Seagate has a 5 year warranty, but I have had to use it many more times then with the above list. YMMV