GNU/Linux >> LINUX-Kenntnisse >  >> Linux

Linux-Hintergrundspülung einschränken (schmutzige Seiten)

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.


Linux
  1. Ersetzen Sie Manpages durch Tealdeer unter Linux

  2. So erhöhen Sie das Limit für die Anzahl der geöffneten Dateien in Linux

  3. So begrenzen Sie die CPU-Auslastung eines Prozesses in Linux

  4. Linux:Hintergrundaufgabe beenden

  5. Wie liest man Linux Manpages?

So begrenzen Sie die Netzwerkbandbreite in Linux mit Wondershaper

Erfahren Sie, wie man Manpages effizient unter Linux verwendet

So löschen oder leeren Sie den DNS-Cache in Linux

So installieren Sie Manpages in Alpine Linux

So leeren Sie den DNS-Cache unter Linux

Wie lösche ich den DNS-Cache unter Linux?