解決策 1:
sysbench で多くのベンチマークを行った結果、次の結論に達しました。
- 邪悪なコピー プロセスによるダーティ ページのフラッディング
- ハードウェア ライト キャッシュが存在する (存在しない場合もあります)
- 1 秒あたりの同期読み取りまたは書き込み (IOPS) が重要
すべてのエレベータ、キュー、およびダーティ ページ キャッシュをダンプするだけです。 ダーティ ページの正しい場所は、そのハードウェア ライト キャッシュの RAM です。
dirty_ratio (または新しい dirty_bytes) をできるだけ低く調整しますが、シーケンシャル スループットに注意してください。私の特定のケースでは、15 MB が最適でした (echo 15000000 > dirty_bytes ).
数ギガバイトの RAM がダーティ キャッシュの代わりに読み取りキャッシュのみに使用されるようになったため、これは解決策というよりハックです。このような状況でダーティ キャッシュがうまく機能するには、Linux カーネル バックグラウンド フラッシャーが、基礎となるデバイスが要求を受け入れる速度を平均化し、それに応じてバックグラウンド フラッシュを調整する必要があります。簡単ではありません。
比較のための仕様とベンチマーク:
dd の間にテスト済み 'ing zeros to disk, sysbench は大成功を示しました 、10 スレッドの fsync 書き込みを 16 kB で 33 から 700 IOPS (アイドル制限:1500 IOPS) にブーストし、単一スレッドを 8 から 400 IOPS にブーストします。
負荷がない場合、IOPS は影響を受けず (~1500)、スループットはわずかに低下しました (251 MB/秒から 216 MB/秒)。
dd コール:
dd if=/dev/zero of=dumpfile bs=1024 count=20485672
sysbench の場合、test_file.0 は非スパースになるように準備されました:
dd if=/dev/zero of=test_file.0 bs=1024 count=10485672
10 スレッドの sysbench 呼び出し:
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
1 つのスレッドの sysbench 呼び出し:
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
ブロック サイズが小さいほど、さらに劇的な数値が示されました。
--file-block-size=4096 with 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 with 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、アイドル状態のシステムで 15 MB の dirty_bytes:
sysbench 0.4.12:マルチスレッド システム評価ベンチマーク
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
テストシステム:
- Adaptec 5405Z (保護付きの 512 MB 書き込みキャッシュ)
- インテル Xeon L5520
- 6 GiB RAM @ 1066 MHz
- マザーボード Supermicro X8DTN (5520 チップセット)
- Seagate Barracuda 1 TB ディスク 12 台
- Linux ソフトウェア RAID 10 で 10
- カーネル 2.6.32
- ファイルシステム xfs
- Debian 不安定版
要約すると、この構成は、データベース トラフィックのアイドル状態、高負荷、さらには全負荷の状況でもうまく機能することを確信しています。いずれにせよ、シーケンシャル スループットは 2 つのギガビット リンクが提供できるよりも高いため、少し減らしても問題ありません。
解決策 2:
カーネル パラメーターを調整することで問題が解決されたとしても、パフォーマンスの問題は、2012 年 2 月 1 日のファームウェア アップデートで修正された Adaptec 5405Z コントローラーのバグの結果である可能性があります。リリース ノートには、「I/O ストレスが高いときにファームウェアがハングする可能性がある問題を修正しました」と記載されています。おそらく、あなたが行ったように I/O を分散することで、このバグが引き起こされるのを防ぐのに十分でしたが、それは単なる推測です.
リリース ノートは次のとおりです:http://download.adaptec.com/pdfs/readme/relnotes_arc_fw-b18937_asm-18837.pdf
これがあなたの特定の状況に当てはまらない場合でも、将来この投稿に出くわすユーザーに役立つ可能性があると考えました. dmesg の出力に次のようなメッセージが表示され、最終的にファームウェアの更新につながりました:
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
高 I/O ハング修正を含むファームウェアのリリース ノートに記載されている Adaptec RAID コントローラのモデル番号は次のとおりです。 5805Q、5805Z、5805ZQ、51245、51645、52445.