LSI Megaraid 475 Performance Tuning

Der in vielen 3-4 Jahre alten Servern (HP, Dell, etc.) verbaute LSI/AMI Megaraid U3-SCSI-Controller wird seit langem von dem Linux Kernel unterstützt. Bei einem Update von Mandrake 8.2 auf Debian Sarge verschlechterte sich die Performance jedoch erheblich (Schreibrate: 7MByte/s anstelle von vormals 16MByte/s). Dieses Howto beschreibt wie die Schreibrate mit wenig Aufwand deutlich gesteigert werden kann. Wer nicht lange lesen möchte: Einfach beim Modul megaraid_mbox die Option max_sectors auf 512 setzen (ACHTUNG: Bei einer Reinitialisierung oder bei einem Konsistenz-Check des RAIDs im laufenden Betrieb kann dieser Wert zu Problemen führen).

• HP Netserver tc4100 mit 2x Pentium3 1400MHz Prozessoren
• LSI Megaraid 475 U3-SCSI-Controller (WriteBack aktiviert)
• 3x HP U3, 18GB, 10k Platten (konfiguriert als RAID5)
• 1GB RAM (4x256MB)
• Der Server wurde 2003 in Betrieb genommen

• Mandrake 8.2 mit Kernel 2.4.19
• Debian Sarge mit Kernel 2.6.8-3 / 2.4.27-2

Unter Mandrake 8.2 ergab eine Messung mit bonnie++ auf einem ext3-Dateisystem und einer 2GB großen Testdatei eine Schreibrate für blockweises Schreiben von 16MByte/s und eine Leserate von 22MByte/s. Die bonnie++ Ausgabe habe ich leider nicht mehr. Diese Werte waren, abgesehen von der schwachen Leserate für diese Konfiguration nicht schlecht. Der Standard-Kernel der Mandrake 8.2 war ein 2.4.19-32. Dieser enthielt den Megaraid Treiber (Modul: megaraid) in der Version 1.18.

Auf dem Server wurde zuerst der 2.6er Kernel mit dem megaraid-Treiber 2.00.3 (Modul megaraid) installiert. Es wurde der Standard Debian Kernel ohne weitere Optimierungen verwendet. Bonnie++ lieferte gerade einmal 5455KByte/s für blockweises Schreiben, und erfreuliche 32677 KByte/s für blockweises Lesen. Unzufrieden mit diesem Ergebnis habe ich den Kernel 2.4.27 installiert, aber auch diese Werte waren nicht wirklich zufriedenstellend:

start 'em...done...done...done...
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
test00           2G            7402   3  5971   4           15533   4 546.3   2
test00,2G,,,7402,3,5971,4,,,15533,4,546.3,2,,,,,,,,,,,,,

In diesem Kernel wird die Megaraid-Treiber Version v1.18k verwendet im Gegensatz zu 1.18 in dem Mandrake Kernel. Beide Treiber sollten sich daher nur minimal Unterscheiden und die 1.18k sollte allenfalls kleine Bugfixes enthalten. Wo also kommt der große Performance-Unterschied her? Google half leider nicht weiter. Es gab zwar einige Diskussionen zu diesen RAID-Karten, aber es scheint sie kaum noch jmd. einzusetzen. Zumindest habe ich keine Antwort auf mein Problem gefunden. Es hätte nicht viel gefehlt und wir hätten den SCSI-Controller getauscht.

Aber vielleicht liefert ja das Changelog eine Antwort:

 * Version 1.18a
 * Mon Mar 11 11:38:38 EST 2002 - Atul Mukker <Atul.Mukker@lsil.com>
 *
 * RAID On MotherBoard (ROMB) - boot from logical or physical drives
 *
 * Support added for discovery(ROMB) vendor and device ids.
 *
 * Data transfer length for passthru commands must be valid even if the
 * command has an associated scatter-gather list.
 *
 *
 * Version 1.18b
 * Tue Apr 23 11:01:58 EDT 2002 - Atul Mukker <Atul.Mukker@lsil.com>
 *
 * typo corrected for scsi condition CHECK_CONDITION in mega_cmd_done()
 *
 * Support added for PCI_VENDOR_ID_LSI_LOGIC with device id
 * PCI_DEVICE_ID_AMI_MEGARAID3.
 *
 *
 * Version 1.18c
 * Thu May 16 10:27:55 EDT 2002 - Atul Mukker <Atul.Mukker@lsil.com>
 *
 * Retrun valid return status for mega passthru commands resulting in
 * contingent allegiance condition. Check for 64-bit passthru commands also.
 *
 * Do not check_region() anymore and check for return value of
 * request_region()
 *
 * Send valid sense data to appliations using the private ioctl interface.
 *
 *
 * Version 1.18d
 * Wed Aug  7 18:51:51 EDT 2002 - Atul Mukker <atul.mukker@lsil.com>
 *
 * Added support for yellowstone and verde controller
 *
 * Version 1.18e
 * Mon Nov 18 12:11:02 EST 2002 - Atul Mukker <atul.mukker@lsil.com>
 *
 * Don't use virt_to_bus in mega_register_mailbox when you've got the DMA
 * address already. Submitted by Jens Axboe and is included in SuSE Linux
 * Enterprise Server 7.
 *
 * s/pcibios_read_config/pci_read_config - Matt Domsch <mdomsch@dell.com>
 *
 * remove an unsed variable
 *
 * Version 1.18f
 * Tue Dec 10 09:54:39 EST 2002 - Atul Mukker <atul.mukker@lsil.com>
 *
 * remove GFP_DMA flag for ioctl. This was causing overrun of DMA buffers.
 *
 * Version 1.18g
 * Fri Jan 31 18:29:25 EST 2003 - Atul Mukker <atul.mukker@lsil.com>
 *
 * Write the interrupt valid signature 0x10001234 as soon as reading it to
 * flush memory caches.
 *
 * While sending back the inquiry information, check if the original request
 * had an associated scatter-gather list and tranfer data from bounce buffer
 * accordingly.
 *
 * Version 1.18h
 * Thu Feb  6 17:18:48 EST 2003 - Atul Mukker <atul.mukker@lsil.com>
 *
 * Reduce the number of sectors per command to 128 from original value of
 * 1024. Big IO sizes along with certain other operation going on in parallel,
 * e.g., check consistency and rebuild put a heavy constraint on fW resources
 * resulting in aborted commands.
 *
 * Version 1.18i
 * Fri Jun 20 07:39:05 EDT 2003 - Atul Mukker <atulm@lsil.com>
 *
 * Request and reserve memory/IO regions. Otherwise a panic occurs if 2.00.x
 * driver is loaded on top of 1.18x driver
 *
 * Prevent memory leak in cases when data transfer from/to application fails
 * and ioctl is failing.
 *
 * Set the PCI dma_mask to default value of 0xFFFFFFFF when we get a handle to
 * it. The previous value of 64-bit might be sticky and would cause the memory
 * for mailbox and scatter lists to be allocated beyond 4GB. This was observed
 * on an Itenium
 *
 * Version 1.18j
 * Mon Jul  7 14:39:55 EDT 2003 - Atul Mukker <atulm@lsil.com>
 *
 * Disable /proc/megaraid/stat file to prevent buffer overflow error during
 * read of this file.
 *
 * Add support for ioctls on AMD-64 bit platforms
 *                      - Sreenivas Bagalkote <sreenib@lsil.com>
 *
 * Version 1.18k
 * Thu Aug 28 10:05:11 EDT 2003 - Atul Mukker <atulm@lsil.com>
 *
 * Make sure to read the correct status and command ids while in ISR. The
 * numstatus and command id array is invalidated before issuing the commands.
 * The ISR busy-waits till the correct values are updated in host memory.

So wirklich aufschlußreich ist dies leider auch nicht, allenfalls die Änderung in 1.18h machte mich neugierig:

 * Reduce the number of sectors per command to 128 from original value of
 * 1024. Big IO sizes along with certain other operation going on in parallel,
 * e.g., check consistency and rebuild put a heavy constraint on fW resources
 * resulting in aborted commands.

Ich änderte also in dem Kernel 2.4.27 in der Datei kernel/drivers/scsi/magaraid.c den Wert für max_sectors_per_io auf 1024. Hier das bonnie++ Ergebnis

start 'em...done...done...done...
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
test00           2G           10207   4  7351   5           21440   5 551.5   1
test00,2G,,,10207,4,7351,5,,,21440,5,551.5,1,,,,,,,,,,,,,

Noch nicht so gut wie mit dem alten Kernel, aber immerhin deutlich besser als vorher.

Im nächsten Schritt, änderte ich diese Option im 2.6.8er Kernel. Praktischerweise ist dieser Wert hier eine Modul-Option (max_sectors_per_io). Scheinbar gab es doch noch mehr, die mit dem Wert von 128 nicht glücklich waren

Hier wieder die Werte:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
test00           2G 15304  68 15066   9  8831   5 18584  79 28266   7 439.0   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP /sec %CP
                 16   450   5 +++++ +++   606   5   390   4 +++++ +++  208   2
test00,2G,15304,68,15066,9,8831,5,18584,79,28266,7,439.0,1,16,450,5,+++++,+++,606,5,390,4,+++++,+++,208,2

Das kann sich schon eher sehen lassen, aber im Vergleich zu max_sectors_per_io=128 ist die Leserate etwas gesunken. Also habe ich mal den Wert 512 probiert:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
oracle           2G           16249  10  8438   5           25455   6 437.5   1
oracle,2G,,,16249,10,8438,5,,,25455,6,437.5,1,,,,,,,,,,,,,

Die Schreibrate hat sich nochmal verbessert, aber die Leserate ist weiter gesunken.

Die bisherigen Tests wurden alle mit dem anticipatory io-scheduler durchgeführt. Für einen Server wird jedoch der deadline io-schduler empfohlen. Hier die Werte:

Reading intelligently...done
start 'em...done...done...done...
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
test00           2G           16699  10  9048   5           26760   6 640.9   1
test00,2G,,,16699,10,9048,5,,,26760,6,640.9,1,,,,,,,,,,,,,

Die Werte haben sich nochmal leicht verbessert, aber so ganz zufrieden war ich auch damit noch nicht.

In den neueren Kerneln (> 2.6.8) ist ein neuer Megaraid-Treiber (megaraid_mbox, Version 2.1 bzw 2.2). Um diesen zu testen installierte ich aus dem Debian-Backports Archive den Kernel 2.6.16 sowie die neue udev Version. Das Modul megaraid_mbox bietet ebenso wie das Modul megaraid die Möglichkeit den Wert für max_sectors_per_io zu verändern, die Option heißt hier jedoch max_sectors. Auch hier ist der Standardwert 128 und ein Test mit diesem Wert brachte eine ähnliche Performance wie mit dem 2.6.8er Kernel. Mit max_sectors=128 sowie dem deadline-scheduler leifert der Controller eine richtig gute Performance.

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
test00           2G 14762  66 16692  12  9656   6 18288  80 37753  10 651.5   3
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16   532   6 +++++ +++   503   4   556   6 +++++ +++   220   2
test00,2G,14762,66,16692,12,9656,6,18288,80,37753,10,651.5,3,16,532,6,+++++,+++,503,4,556,6,+++++,+++,220,2

Mit diesen Werten macht es dann auch wieder Spaß auf dem RAID zu arbeiten und die Datenbank wurde auch spürbar schneller. Ein neuer RAID-Controller wurde eingespart und der Server bekam noch eine Remote-Karte spendiert Schade nur, dass dies nirgends dokumentiert wurde. Der folgende Eintrag im Source-Code ist da alles andere als ausreichend:

        /*
         * Comment the following initialization if you know 'max_sectors' is
         * not defined for this kernel.
         * This field was introduced in Linus's kernel 2.4.7pre3 and it
         * greatly increases the IO performance - AM
         */
        host->max_sectors = 128;

— Nils 2006/09/13 11:29