Auf DL380p-Gen8-Servern mit XFS auf LVM auf RAID 1 + 0 mit 6 Festplatten führt eine identische Arbeitslast zu einer Verzehnfachung der Festplattenschreibvorgänge auf RHEL 6 im Vergleich zu RHEL 5, wodurch Anwendungen unbrauchbar werden.

Beachten Sie, dass es mir nicht darum geht, das co6-System so weit wie möglich zu optimieren, sondern zu verstehen, warum sich co6 so wild anders verhält, und das zu lösen.

vmstat / iostat

Wir haben ein MySQL-Replikationssetup mit mysql 5.5. MySQL-Slaves auf Gen8-Servern, die RHEL 6 als Betriebssystem verwenden, arbeiten schlecht. Eine Überprüfung mit VMSTAT und IOSTAT zeigt, dass diese Server die zehnfache Auslagerungsaktivität und die zehnfache Anzahl von Schreibvorgängen auf das Festplattensubsystem ausführen. blktrace zeigt, dass diese Schreibvorgänge nicht von mysql, sondern vom Kernel initiiert werden.

Centos 5:

[dkaarsemaker@co5 ~]$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0     12 252668 102684 10816864    0    0     8   124    0    0  9  1 90  0  0
 1  0     12 251580 102692 10817116    0    0    48  2495 3619 5268  6  1 93  0  0
 3  0     12 252168 102692 10817848    0    0    32  2103 4323 5956  6  1 94  0  0
 3  0     12 252260 102700 10818672    0    0   128  5212 5365 8142 10  1 89  0  0

[dkaarsemaker@co5 ~]$ iostat 1
Linux 2.6.18-308.el5 (bc290bprdb-01.lhr4.prod.booking.com)  02/28/2013

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.74    0.00    0.81    0.25    0.00   90.21

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      277.76       399.60      5952.53 2890574849 43058478233
cciss/c0d0p1      0.01         0.25         0.01    1802147      61862
cciss/c0d0p2      0.00         0.01         0.00     101334      32552
cciss/c0d0p3    277.75       399.34      5952.52 2888669185 43058383819
dm-0             32.50        15.00       256.41  108511602 1854809120
dm-1            270.24       322.97      5693.34 2336270565 41183532042

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7.49    0.00    0.79    0.08    0.00   91.64

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      300.00        32.00      4026.00         32       4026
cciss/c0d0p1      0.00         0.00         0.00          0          0
cciss/c0d0p2      0.00         0.00         0.00          0          0
cciss/c0d0p3    300.00        32.00      4026.00         32       4026
dm-0              0.00         0.00         0.00          0          0
dm-1            300.00        32.00      4026.00         32       4026

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.25    0.00    0.46    0.21    0.00   95.09

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      507.00       160.00     10370.00        160      10370
cciss/c0d0p1      0.00         0.00         0.00          0          0
cciss/c0d0p2      0.00         0.00         0.00          0          0
cciss/c0d0p3    507.00       160.00     10370.00        160      10370
dm-0              0.00         0.00         0.00          0          0
dm-1            507.00       160.00     10370.00        160      10370

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.33    0.00    0.50    0.08    0.00   94.09

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      318.00        64.00      4559.00         64       4559
cciss/c0d0p1      0.00         0.00         0.00          0          0
cciss/c0d0p2      0.00         0.00         0.00          0          0
cciss/c0d0p3    319.00        64.00      4561.00         64       4561
dm-0              0.00         0.00         0.00          0          0
dm-1            319.00        64.00      4561.00         64       4561

Und auf Centos 6 verzehnfacht sich die Anzahl der ausgelagerten und der Festplattenschreibvorgänge:

[root@co6 ~]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 361044  52340 81965728    0    0    19  1804   36  110  1  1 98  0  0  
 0  0      0 358996  52340 81965808    0    0   272 57584 1211 3619  0  0 99  0  0  
 2  0      0 356176  52348 81966800    0    0   240 34128 2121 14017  1  0 98  0  0 
 0  1      0 351844  52364 81968848    0    0  1616 29128 3648 3985  1  1 97  1  0  
 0  0      0 353000  52364 81969296    0    0   480 44872 1441 3480  1  0 99  0  0  

[root@co6 ~]# iostat 1
Linux 2.6.32-279.22.1.el6.x86_64 (bc291bprdb-01.lhr4.prod.booking.com)  02/28/2013  _x86_64_    (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.08    0.00    0.67    0.27    0.00   97.98

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             373.48      1203.02    115203.05   11343270 1086250748
dm-0             63.63        74.92       493.63     706418    4654464
dm-1            356.48      1126.72    114709.47   10623848 1081596740

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.25    0.00    0.19    0.06    0.00   99.50

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             330.00        80.00     77976.00         80      77976
dm-0              0.00         0.00         0.00          0          0
dm-1            328.00        64.00     77456.00         64      77456

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.38    0.00    0.19    0.63    0.00   98.81

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             570.00      1664.00    128120.00       1664     128120
dm-0              0.00         0.00         0.00          0          0
dm-1            570.00      1664.00    128120.00       1664     128120

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.66    0.00    0.47    0.03    0.00   98.84

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             317.00       448.00     73048.00        448      73048
dm-0             34.00         0.00       272.00          0        272
dm-1            309.00       448.00     72776.00        448      72776

Eingrenzen

Server der Generation 8 mit RHEL 5 und Server der Generation 7 mit RHEL 5 oder 6 weisen dieses Problem nicht auf. Außerdem zeigt RHEL 6 mit ext3 als Dateisystem anstelle unseres Standard-XFS das Problem nicht. Das Problem scheint wirklich irgendwo zwischen XFS, Gen8-Hardware und Centos 6 zu liegen. RHEL 6 zeigt auch das Problem.

Edit 29/04: Wir haben qlogic HBA's auf der G8 Maschine hinzugefügt. Die Verwendung von XFS im Fibre-Channel-Speicher zeigt das Problem nicht. Es liegt also definitiv irgendwo in der Interaktion zwischen xfs / hpsa / p420i.

XFS

Das neuere xfs in Rhel 8 scheint in der Lage zu sein, die zugrunde liegende Streifenbreite zu erkennen, jedoch nur auf p420i-Controllern, die den hpsa-Treiber verwenden, und nicht auf p410i-Controllern, die cciss verwenden.

xfs_info-Ausgabe:

[root@co6 ~]# xfs_info /mysql/bp/
meta-data=/dev/mapper/sysvm-mysqlVol isize=256    agcount=16, agsize=4915136 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=78642176, imaxpct=25
         =                       sunit=64     swidth=192 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=38400, version=2
         =                       sectsz=512   sunit=64 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

sunit / swidth sind beide 0 in allen Einstellungen, die oben als OK markiert sind. Wir scheinen nicht in der Lage zu sein, dies zu ändern, weder in mkfs noch mit der Option noalign mount. Wir wissen auch nicht, ob dies die Ursache ist.

Riesenseiten

Andere Leute mit XFS-Problemen auf Rhel 6 sagen, dass das Deaktivieren von Riesen-Seiten und besonders transparenten Riesen-Seiten von Vorteil sein kann. Wir haben beide deaktiviert, das Problem ist nicht verschwunden.

Wir haben bereits viele Dinge ausprobiert und beobachtet, keines der folgenden hat geholfen:

• Verwenden von numactl, um die Speicherzuordnung zu beeinflussen. Wir haben festgestellt, dass g7 und g8 ein unterschiedliches Nummernlayout haben, es wurde kein Effekt festgestellt
• Neuere Kernel (so neu wie 3.6) schienen dies nicht zu lösen. Auch Fedora 17 wurde nicht verwendet.
• iostat meldet keine Verzehnfachung der Schreibtransaktionen, nur der Anzahl der geschriebenen Bytes
• Die Verwendung verschiedener E / A-Scheduler hat keine Auswirkung.
• Das Mounten des entsprechenden Dateisystems noatime / nobarrier / nopdiratime hat nicht geholfen
• Das Ändern von / proc / sys / vm / dirty_ratio hatte keine Auswirkungen
• Dies geschieht sowohl auf Systemen, die auf 2640- als auch auf 2670-CPUs basieren
• hpsa-3.2.0 behebt das Problem nicht

XFS und EL6 sind in einen hässlichen Zustand geraten ... Ich habe XFS auf EL6-Systemen vorerst aufgegeben, da einige Upstream-Funktionen / Änderungen in den Red Hat-Kernel übernommen wurden ...

Dies war eine Überraschung und sorgte für einige Panik: Warum verbrauchen meine XFS-Dateisysteme plötzlich mehr Speicherplatz und sind voll mit spärlichen Dateien?

Seit November 2012 gibt es in der XFS-Version, die in neueren Kerneln ausgeliefert wird 2.6.32-279.11.1.el6, ein störendes Lade- und Leistungsproblem, das auf Red Hat Bugzilla 860787 zurückzuführen ist . Seitdem hatte ich eine unvorhersehbare Leistung und höhere Ausführungswarteschlangen als der Durchschnitt.

Für neue Systeme verwende ich ZFS oder nur ext4. Bei älteren Systemen friere ich sie ein 2.6.32-279.11.1.el6.

Versuchen Sie, mit den folgenden Schritten auf diese Version zurückzusetzen:

yum install kernel-2.6.32-279.11.1.el6.x86_64

Aufgrund des von Ihnen verwendeten RAID-Controllertyps sind zusätzlich die typischen Optimierungen in der Reihenfolge:

Hängen Sie Ihre XFS-Dateisysteme ein noatime. Sie sollten das Optimierte Framework auch für folgende Zwecke nutzen :

tuned-adm profile enterprise-storage

readahead, nobarrier und I / O lift auf eine gute Grundlinie zu setzen.

Bearbeiten:

Es gibt viele Empfehlungen zur Optimierung des XFS-Dateisystems. Ich habe das Dateisystem in den letzten zehn Jahren ausschließlich verwendet und musste gelegentlich Parameter anpassen, da grundlegende Änderungen am Betriebssystem auftraten. Ich habe keinen dramatischen Leistungsabfall wie den Ihren erlebt, aber ich verwende auch kein LVM.

Ich halte es für unvernünftig, zu erwarten, dass EL5 aufgrund der unterschiedlichen Kernel-Generationen, der kompilierten Standardeinstellungen, der Scheduler, der Pakete usw. genauso wie EL6 funktioniert .

Was würde ich an dieser Stelle tun?

• Ich würde die mkfs.xfs-Parameter untersuchen und wie Sie die Systeme erstellen. Verwenden Sie die XFS-Partitionierung während der Installation oder erstellen Sie die Partitionen nachträglich? Ich erstelle das XFS-Dateisystem nach der Installation des Hauptbetriebssystems, da die angegebenen Parameter flexibler sind.

• Meine Erstellungsparameter mkfs.xfs -f -d agcount=32 -l size=128m,version=2 /dev/sdb1für mkfs.xfs sind einfach: Zum Beispiel.

• Meine Mount-Optionen lauten: noatime,logbufs=8,logbsize=256k,nobarrierIch würde zulassen, dass die dynamische XFS-Vorabzuweisung nativ ausgeführt wird, ohne sie einzuschränken , wie Sie es hier getan haben. Meine Leistung verbesserte sich dadurch.

• Also benutze ich kein LVM . Vor allem auf Hardware-RAIDs ... Vor allem auf HP Smart Array-Controllern, auf denen einige LVM-ähnliche Funktionen vorhanden sind, die dem Gerät eigen sind. Mit LVM haben Sie jedoch keinen Zugriff auf die fdiskErstellung von unformatierten Partitionen. Eine Sache, die von EL5 auf EL6 geändert wurde, ist die Partitionsausrichtung im Installationsprogramm und wechselt zu fdisk, um den Startsektor an einer Zylindergrenze festzulegen.

• Stellen Sie sicher, dass Sie Ihre HP Smart Array-Controller und -Laufwerke mit dem aktuellen Versionsstand ausführen. An diesem Punkt ist es sinnvoll, den gesamten Server auf die aktuelle Firmware-Version von HP Service Pack for ProLiant zu aktualisieren . Dies ist eine bootfähige DVD, die alle erkannten Komponenten im System aktualisiert.

• Ich würde die RAID-Controller-Einstellungen überprüfen. Pastebin die Ausgabe von hpacucli ctrl all show config detail. Hier ist meins. Sie möchten ein Cacheverhältnis, das auf Schreib- und Lesevorgänge ausgerichtet ist. 75:25 ist die Norm. Die Standard - Streifengröße von 256K sollte in Ordnung für diese Anwendung sein.

• Ich würde dies möglicherweise ohne LVM versuchen.

• Was sind Ihre sysctl.confParameter?

Wir hatten das ähnliche Problem und stellten fest, dass es an der Änderung der XFS-Protokollversion liegt. Version 2-Protokolle berücksichtigen die mit mkfs.xfs verwendete Streifenbreite. Wenn Sie viel fsync ausführen, kann Ihre Raid-Karte diese Logs nicht mehr fälschen. Sie können es testen, indem Sie die Partition ohne jede Geschwindigkeitseinstellung formatieren (dies macht bei RAID 1 + 0 keinen Unterschied). Sie können dies mit blktrace / seekwatcher überprüfen, um festzustellen, ob es sich um eine große Menge von Protokollaktualisierungen handelt.