Řešení 1:
Po spoustě benchmarkingu se sysbenchem jsem došel k tomuto závěru:
Přežít (výkonnostně) situaci, kdy
- zlý proces kopírování zaplavuje špinavé stránky
- a je přítomna hardwarová vyrovnávací paměť pro zápis (možná i bez ní)
- a synchronní čtení nebo zápis za sekundu (IOPS) jsou kritické
stačí vyhodit všechny výtahy, fronty a špinavé mezipaměti stránek. Správné místo pro nečisté stránky je v paměti RAM dané hardwarové mezipaměti pro zápis.
Upravte dirty_ratio (nebo nové dirty_bytes) co nejníže, ale sledujte sekvenční propustnost. V mém konkrétním případě bylo 15 MB optimální (echo 15000000 > dirty_bytes ).
Toto je spíše hack než řešení, protože gigabajty paměti RAM se nyní používají pouze pro ukládání do mezipaměti pro čtení namísto špinavé mezipaměti. Aby špinavá mezipaměť v této situaci dobře fungovala, musel by proplachovač pozadí linuxového jádra zprůměrovat, jakou rychlostí základní zařízení přijímá požadavky, a podle toho upravit proplachování pozadí. Není to snadné.
Specifikace a benchmarky pro srovnání:
Testováno během dd Když byly na disku nuly, sysbench ukázal obrovský úspěch , zvýšení 10 vláken pro zápis fsync při 16 kB z 33 na 700 IOPS (limit nečinnosti:1500 IOPS) a jedno vlákno z 8 na 400 IOPS.
Bez zátěže nebyly IOPS ovlivněny (~1500) a propustnost byla mírně snížena (z 251 MB/s na 216 MB/s).
dd zavolejte:
dd if=/dev/zero of=dumpfile bs=1024 count=20485672
pro sysbench byl test_file.0 připraven tak, aby byl nesparse s:
dd if=/dev/zero of=test_file.0 bs=1024 count=10485672
volání sysbench pro 10 vláken:
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
volání sysbench pro jedno vlákno:
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
Menší velikosti bloků vykazovaly ještě drastickější čísla.
--file-block-size=4096 s 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 s 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 s 15 MB dirty_bytes na nečinném systému:
sysbench 0.4.12:srovnávací hodnocení vícevláknového systému
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
Testovací systém:
- Adaptec 5405Z (to je 512 MB mezipaměti pro zápis s ochranou)
- Intel Xeon L5520
- 6 GiB RAM @ 1066 MHz
- Základní deska Supermicro X8DTN (čipset 5520)
- 12 disků Seagate Barracuda 1 TB
- 10 v softwaru Linux RAID 10
- Jádro 2.6.32
- Systém souborů xfs
- Debian nestabilní
Stručně řečeno, jsem si nyní jistý, že tato konfigurace bude fungovat dobře v nečinnosti, vysoké zátěži a dokonce i plné zátěži pro databázový provoz, který by jinak byl vyhladověn sekvenčním provozem. Sekvenční propustnost je tak jako tak vyšší, než dokážou poskytnout dvě gigabitové linky, takže není problém ji trochu snížit.
Řešení 2:
I když ladění parametrů jádra problém zastavilo, je ve skutečnosti možné, že vaše problémy s výkonem byly výsledkem chyby na řadiči Adaptec 5405Z, která byla opravena v aktualizaci firmwaru z 1. února 2012. Poznámky k vydání říkají:„Opraven problém, kdy se firmware mohl zablokovat během vysokého I/O stresu.“ Možná, že rozložení I/O, jak jste to udělali vy, stačilo k tomu, aby se zabránilo spuštění této chyby, ale to je jen odhad.
Zde jsou poznámky k vydání:http://download.adaptec.com/pdfs/readme/relnotes_arc_fw-b18937_asm-18837.pdf
I když to nebyl případ vaší konkrétní situace, usoudil jsem, že by to mohlo být přínosem pro uživatele, kteří se s tímto příspěvkem setkají v budoucnu. V našem výstupu dmesg jsme viděli několik zpráv, jako jsou následující, které nás nakonec vedly k aktualizaci firmwaru:
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
Zde jsou čísla modelů řadičů Adaptec RAID, která jsou uvedena v poznámkách k vydání pro firmware, který má opravu vysokého I/O:2045, 2405, 2405Q, 2805, 5085, 5405, 5405Z, 5445, 5445Z, 5805 5805Q, 5805Z, 5805ZQ, 51245, 51645, 52445.