Lösung 1:
Nach vielem Benchmarking mit Sysbench komme ich zu folgendem Schluss:
Um (leistungsmäßig) eine Situation zu überleben, in der
- ein bösartiger Kopierprozess überschwemmt schmutzige Seiten
- und Hardware-Write-Cache ist vorhanden (evtl. auch ohne)
- und synchrone Lese- oder Schreibvorgänge pro Sekunde (IOPS) sind entscheidend
Lassen Sie einfach alle Aufzüge, Warteschlangen und Dirty-Page-Caches fallen. Der richtige Platz für Dirty Pages ist im RAM dieses Hardware-Schreib-Cache.
Stellen Sie dirty_ratio (oder neue dirty_bytes) so niedrig wie möglich ein, aber behalten Sie den sequentiellen Durchsatz im Auge. In meinem speziellen Fall waren 15 MB optimal (echo 15000000 > dirty_bytes
).
Dies ist eher ein Hack als eine Lösung, da Gigabyte RAM jetzt nur noch für Lese-Caching verwendet werden, anstatt für Dirty-Cache. Damit der schmutzige Cache in dieser Situation gut funktioniert, müsste der Linux-Kernel-Hintergrundspüler mitteln, mit welcher Geschwindigkeit das zugrunde liegende Gerät Anforderungen akzeptiert, und die Hintergrundspülung entsprechend anpassen. Nicht einfach.
Spezifikationen und Benchmarks zum Vergleich:
Getestet während dd
sysbench zeigte riesigen Erfolg, Nullen auf die Festplatte zu schreiben , was 10 Threads fsync-Schreibvorgänge bei 16 kB von 33 auf 700 IOPS (Leerlauflimit:1500 IOPS) und Single-Thread von 8 auf 400 IOPS erhöht.
Ohne Last blieben die IOPS unbeeinflusst (~1500) und der Durchsatz leicht reduziert (von 251 MB/s auf 216 MB/s).
dd
Aufruf:
dd if=/dev/zero of=dumpfile bs=1024 count=20485672
für sysbench wurde die test_file.0 so vorbereitet, dass sie unsparse ist mit:
dd if=/dev/zero of=test_file.0 bs=1024 count=10485672
Sysbench-Aufruf für 10 Threads:
sysbench --test=fileio --file-num=1 --num-threads=10 --file-total-size=10G --file-fsync-all=on --file-test-mode=rndwr --max-time=30 --file-block-size=16384 --max-requests=0 run
Sysbench-Aufruf für einen Thread:
sysbench --test=fileio --file-num=1 --num-threads=1 --file-total-size=10G --file-fsync-all=on --file-test-mode=rndwr --max-time=30 --file-block-size=16384 --max-requests=0 run
Kleinere Blockgrößen zeigten noch drastischere Zahlen.
--file-block-size=4096 mit 1 GB dirty_bytes:
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 1
Extra file open flags: 0
1 files, 10Gb each
10Gb total file size
Block size 4Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Calling fsync() after each write operation.
Using synchronous I/O mode
Doing random write test
Threads started!
Time limit exceeded, exiting...
Done.
Operations performed: 0 Read, 30 Write, 30 Other = 60 Total
Read 0b Written 120Kb Total transferred 120Kb (3.939Kb/sec)
0.98 Requests/sec executed
Test execution summary:
total time: 30.4642s
total number of events: 30
total time taken by event execution: 30.4639
per-request statistics:
min: 94.36ms
avg: 1015.46ms
max: 1591.95ms
approx. 95 percentile: 1591.30ms
Threads fairness:
events (avg/stddev): 30.0000/0.00
execution time (avg/stddev): 30.4639/0.00
--file-block-size=4096 mit 15 MB dirty_bytes:
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 1
Extra file open flags: 0
1 files, 10Gb each
10Gb total file size
Block size 4Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Calling fsync() after each write operation.
Using synchronous I/O mode
Doing random write test
Threads started!
Time limit exceeded, exiting...
Done.
Operations performed: 0 Read, 13524 Write, 13524 Other = 27048 Total
Read 0b Written 52.828Mb Total transferred 52.828Mb (1.7608Mb/sec)
450.75 Requests/sec executed
Test execution summary:
total time: 30.0032s
total number of events: 13524
total time taken by event execution: 29.9921
per-request statistics:
min: 0.10ms
avg: 2.22ms
max: 145.75ms
approx. 95 percentile: 12.35ms
Threads fairness:
events (avg/stddev): 13524.0000/0.00
execution time (avg/stddev): 29.9921/0.00
--file-block-size=4096 mit 15 MB dirty_bytes im Leerlaufsystem:
sysbench 0.4.12:Multithread-Systembewertungs-Benchmark
Running the test with following options:
Number of threads: 1
Extra file open flags: 0
1 files, 10Gb each
10Gb total file size
Block size 4Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Calling fsync() after each write operation.
Using synchronous I/O mode
Doing random write test
Threads started!
Time limit exceeded, exiting...
Done.
Operations performed: 0 Read, 43801 Write, 43801 Other = 87602 Total
Read 0b Written 171.1Mb Total transferred 171.1Mb (5.7032Mb/sec)
1460.02 Requests/sec executed
Test execution summary:
total time: 30.0004s
total number of events: 43801
total time taken by event execution: 29.9662
per-request statistics:
min: 0.10ms
avg: 0.68ms
max: 275.50ms
approx. 95 percentile: 3.28ms
Threads fairness:
events (avg/stddev): 43801.0000/0.00
execution time (avg/stddev): 29.9662/0.00
Testsystem:
- Adaptec 5405Z (das sind 512 MB Schreibcache mit Schutz)
- Intel Xeon L5520
- 6 GiB-RAM bei 1066 MHz
- Mainboard Supermicro X8DTN (5520 Chipsatz)
- 12 Seagate Barracuda 1 TB-Festplatten
- 10 in Linux-Software-RAID 10
- Kernel 2.6.32
- Dateisystem xfs
- Debian instabil
Zusammenfassend bin ich jetzt sicher, dass diese Konfiguration in Leerlauf-, Hochlast- und sogar Volllastsituationen für Datenbankverkehr gut funktioniert, der andernfalls durch sequentiellen Verkehr ausgehungert worden wäre. Der sequentielle Durchsatz ist ohnehin höher als zwei Gigabit-Verbindungen liefern können, also kein Problem, ihn ein wenig zu reduzieren.
Lösung 2:
Auch wenn das Problem durch die Optimierung der Kernel-Parameter behoben wurde, ist es tatsächlich möglich, dass Ihre Leistungsprobleme das Ergebnis eines Fehlers auf dem Adaptec 5405Z-Controller waren, der in einem Firmware-Update vom 1. Februar 2012 behoben wurde. In den Versionshinweisen heißt es:„Problem behoben, bei dem die Firmware bei hoher E/A-Belastung hängen bleiben konnte.“ Vielleicht reichte es aus, die E/A so zu verteilen, wie Sie es getan haben, um zu verhindern, dass dieser Fehler ausgelöst wird, aber das ist nur eine Vermutung.
Hier sind die Versionshinweise:http://download.adaptec.com/pdfs/readme/relnotes_arc_fw-b18937_asm-18837.pdf
Auch wenn dies in Ihrer speziellen Situation nicht der Fall war, dachte ich, dass dies Benutzern zugute kommen könnte, die in Zukunft auf diesen Beitrag stoßen. Wir haben einige Meldungen wie die folgende in unserer dmesg-Ausgabe gesehen, die uns schließlich zum Firmware-Update geführt haben:
aacraid: Host adapter abort request (0,0,0,0)
[above was repeated many times]
AAC: Host adapter BLINK LED 0x62
AAC0: adapter kernel panic'd 62.
sd 0:0:0:0: timing out command, waited 360s
sd 0:0:0:0: Unhandled error code
sd 0:0:0:0: SCSI error: return code = 0x06000000
Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT,SUGGEST_OK
sd 0:0:0:0: timing out command, waited 360s
sd 0:0:0:0: Unhandled error code
sd 0:0:0:0: SCSI error: return code = 0x06000028
Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT,SUGGEST_OK
sd 0:0:0:0: timing out command, waited 360s
sd 0:0:0:0: Unhandled error code
sd 0:0:0:0: SCSI error: return code = 0x06000028
Hier sind die Modellnummern der Adaptec RAID-Controller, die in den Versionshinweisen für die Firmware mit dem Fix für hohe I/O-Hänge aufgelistet sind:2045, 2405, 2405Q, 2805, 5085, 5405, 5405Z, 5445, 5445Z, 5805, 5805Q, 5805Z, 5805ZQ, 51245, 51645, 52445.