Linuxバックグラウンドフラッシュを制限する（ダーティページ）
Linuxでのバックグラウンドフラッシュは、保留中の書き込みデータが多すぎる（/ proc/sys/vm/dirty_background_ratioで調整可能）か、保留中の書き込みのタイムアウト（/ proc/sys/vm/dirty_expire_centisecs）に達したときに発生します。別の制限に達していない限り（/ proc/sys/vm/dirty_ratio）、書き込まれたデータがさらにキャッシュされる可能性があります。それ以上の書き込みはブロックされます。
理論的には、これにより、他のプロセスを妨げることなくダーティページを書き込むバックグラウンドプロセスが作成されます。実際には、キャッシュされていない読み取りや同期書き込みを行うプロセスは妨害されます。ひどく。これは、バックグラウンドフラッシュが実際に100％のデバイス速度で書き込み、この時点での他のデバイスリクエストが遅延するためです（道路上のすべてのキューと書き込みキャッシュが満たされているため）。
フラッシュプロセスが実行する1秒あたりのリクエスト数を制限する方法、または他のデバイスI/Oを効果的に優先する方法はありますか？
Sysbenchで多くのベンチマークを行った後、私はこの結論に達しました：
（パフォーマンスの観点から）生き残るために
- 悪質なコピープロセスがダーティページをフラッディングする
- ハードウェアの書き込みキャッシュが存在する（おそらくそれなしでも）
- 同期読み取りまたは1秒あたりの書き込み（IOPS）が重要です
すべてのエレベーター、キュー、ダーティページキャッシュをダンプするだけです。 ダーティページの正しい場所はRAM）にあります。
Dirty_ratio（または新しいdirty_bytes）をできるだけ低く調整しますが、シーケンシャルスループットに注意してください。私の特定のケースでは、15 MBが最適でした（echo 15000000 > dirty_bytes）。
RAMのギガバイトがダーティキャッシュの代わりに読み取りキャッシュのみに使用されるため、これはソリューションよりもハックです。この状況でダーティキャッシュがうまく機能するために、Linuxカーネルバックグラウンドフラッシュは基盤となるデバイスが要求を受け入れる速度を平均化し、それに応じてバックグラウンドフラッシュを調整する必要があります。
比較のための仕様とベンチマーク：
ディスクにゼロをdd 'する間にテストしたところ、sysbenchは巨大な成功を示し、16 kBでの10スレッドのfsync書き込みが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、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、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チップセット）
- 12 Seagate Barracuda 1 TBディスク
- LinuxソフトウェアRAID 10の10
- カーネル2.6.32
- ファイルシステムxfs
- Debian不安定
要約すると、この構成は、アイドル状態で高負荷の場合でも、シーケンシャルトラフィックで不足していたデータベーストラフィックの場合でも、フル負荷の状況でも適切に機能するようになりました。シーケンシャルスループットは、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コントローラーのモデル番号は次のとおりです：2045、2405、2405Q、2805、5085、5405、5405Z、5445、5445Z、5805、 5805Q、5805Z、5805ZQ、51245、51645、52445。
「WBT」を含むカーネル：
ブロックレイヤーの改善 、LWN.net
ライトバックスロットリングを使用すると、[ブロックレイヤー]は、CoDelネットワークスケジューラーから借用した戦略を使用して、過度のI/Oレイテンシなしで最大のパフォーマンスを得ようとします。 CoDelは、ネットワークパケットの観測された最小遅延を追跡し、それがしきい値を超えると、パケットのドロップを開始します。 I/Oサブシステムでは書き込みの削除は避けられますが、カーネルが読み取りと書き込みの両方の最小待機時間を監視し、それがしきい値を超えると、バックグラウンドの書き戻しの量を減らし始めるという同様の戦略に従いますそれが行われています。この動作は4.10で追加されました。 Axboeはかなり良い結果が見られたと言いました。
WBTでは、新しいblk-mqブロックレイヤーに切り替える必要はありません。つまり、CFQまたはBFQ I/Oスケジューラでは機能しません。 WBTは、deadline/mq-deadline/noop/noneスケジューラで使用できます。新しい「kyber」I/Oスケジューラでも動作すると思います。
待機時間を制御するためにキューサイズをスケーリングするだけでなく、WBTコード バックグラウンドライトバック要求の数を制限します は、計算されたキュー制限の比率として。
ランタイム構成は/sys/class/block/*/queue/wbt_lat_usecにあります。
検索するビルド構成オプションは次のとおりです
/boot/config-4.20.8-200.fc29.x86_64:CONFIG_BLK_WBT=y
/boot/config-4.20.8-200.fc29.x86_64:# CONFIG_BLK_WBT_SQ is not set
/boot/config-4.20.8-200.fc29.x86_64:CONFIG_BLK_WBT_MQ=y
あなたの問題文はWBTの作者によって100％確認されています-よくできました:-)。
[PATCHSET] block：buffered writeback throttling
時間の夜明け以来、バックグラウンドでバッファリングされた書き戻しは失敗しました。バックグラウンドバッファーライトバックを実行しても、フォアグラウンドアクティビティにはほとんど影響がありません。これがバックグラウンドアクティビティの定義です...しかし、私が覚えている限り、大量のバッファライターはそのように動作していません。たとえば、私がこのようなことをした場合：
$ dd if=/dev/zero of=foo bs=1M count=10k私のラップトップで、Chromeを起動してみます。基本的には、バッファリングされた書き戻しが完了するまで起動しません。または、サーバー指向のワークロードの場合、大きなRPM（または同様のもの）のインストールがデータベースの読み取りまたは同期書き込みに悪影響を及ぼします。それが起こるとき、私は人々が私を怒鳴らせます。
最近のいくつかのテストの結果はここにあります：
https://www.facebook.com/axboe/posts/101540746513429
パッチセットの詳細については、以前の投稿を参照してください。
/ proc/meminfoのDirtyの平均はどれくらいですか？これは通常、/ proc/sys/vm/dirty_ratioを超えてはなりません。専用ファイルサーバーでは、dirty_ratioをメモリの非常に高い割合（90）に設定しています。これを超えることはありません。あなたのdirty_rationは低すぎます、あなたがそれに当たると、すべてがクラップアウトし、それを上げます。