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
mkfs.xfsundmountOptionen. EL6 erkennt die Ausrichtung der Partitionen. HPSA würde für beide Smart Array-Controllertypen unter EL6 verwendet, EL5 würde jedoch CCISS verwenden.Antworten:
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:
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 :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?quelle
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.
quelle
mkfs.xfsBefehlszeichenfolge?