私たちは複数の90TBサーバーを持っています（Areca RAID-6は10個のext4パーティションに分割されています）。
アプリケーションは特定のハードウェアデバイスを読み取り、特定の時点でディスクにデータを書き込みます。絶え間ない8〜10MB /秒（アプリはメモリバッファを使用して別々のリーダーと書き込みスレッドを実行します。）
時々ファイル操作はクロール速度で遅くなります。たとえば、fwrite()200バイトのデータを書き込むのに10〜30秒かかり、ftell()ファイルの場所を取得するのに似た時間がかかるなどの現象が発生します。
時々（常にそうではない）、システムが遅くなると、topCPUが0％のすべてのプロセスが表示されます。これはサーバーエラーの発行に似ています。。
減速は数分間続き、後で再び発生します。
速度低下の「毎日の頻度」がないので、cron/anacronなどで実行することを排除しました。
ただし、減速中はシステム負荷が0.4（通常）から3-4に変更されます。非常に高いI / O％を iotop表示することがよくあります。背中が非常に高く表示され、どこかにI/Oボトルネックが発生します。kworker/u16:0+flush-8:112topvmstat%wa
I/Oスケジューラをmq-deadline。
また、アプリケーションは、fsync作成中のオープンファイルを含むファイルシステムで5秒ごとに実行されます。
調整可能なパラメータを見つけるために速度低下の原因が何であるか、数日間インターネット検索をしてみましたが、これまでは運がありませんでした。
継続的な書き込みシナリオのためにLinuxを調整する方法について提案がありますか？
セントース8
# uname -a
Linux 4.18.0-147.el8.x86_64 #1 SMP Wed Dec 4 21:51:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
IOTOP出力
Total DISK READ : 161.32 K/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
b' 10666 rt/0 root 161.32 K/s 0.00 B/s 0.00 % 4.43 % MyWritingApp'
Total DISK READ : 239.58 K/s | Total DISK WRITE : 78.27 M/s
Actual DISK READ: 239.58 K/s | Actual DISK WRITE: 2.20 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
b' 431412 be/4 root 135.01 K/s 0.00 B/s 0.00 % 44.80 % [kworker/u16:8-flush-8:32]'
b' 10666 rt/0 root 104.57 K/s 78.11 M/s 0.00 % 1.88 % MyWritingApp'
b' 8853 be/3 root 0.00 B/s 9.27 K/s 0.00 % 0.01 % [jbd2/sdh1-8]'
b' 1123 ?dif mysql 0.00 B/s 149.57 K/s 0.00 % 0.00 % mysqld --basedir=/usr'
Total DISK READ : 388.68 K/s | Total DISK WRITE : 14.98 M/s
Actual DISK READ: 469.32 K/s | Actual DISK WRITE: 1899.42 K/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
b' 338764 be/4 root 388.68 K/s 0.00 B/s 0.00 % 89.25 % [kworker/u16:0+flush-8:112]'
b' 1123 ?dif mysql 0.00 B/s 955.83 K/s 0.00 % 0.00 % mysqld --basedir=/usr'
b' 2740 be/4 apache 0.00 B/s 1353.76 B/s 0.00 % 0.00 % httpd -DFOREGROUND'
b' 10664 be/4 root 0.00 B/s 1353.76 B/s 0.00 % 0.00 % php /usr/local/dvstor/bin64/DvStorStartRecording.php mode=ASI tsNum=0'
b' 10666 rt/0 root 0.00 B/s 14.04 M/s 0.00 % 0.00 % MyWritingApp'
Total DISK READ : 609.63 K/s | Total DISK WRITE : 15.87 K/s
Actual DISK READ: 609.63 K/s | Actual DISK WRITE: 31.74 K/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
b' 338764 be/4 root 601.70 K/s 0.00 B/s 0.00 % 99.43 % [kworker/u16:0+flush-8:112]'
b' 711 be/4 root 7.93 K/s 0.00 B/s 0.00 % 3.00 % systemd-journald'
b' 9246 be/3 root 0.00 B/s 7.93 K/s 0.00 % 0.00 % [jbd2/sdi1-8]'
b' 933 be/3 root 0.00 B/s 1354.15 B/s 0.00 % 0.00 % auditd'
b' 1966 be/4 root 0.00 B/s 2.64 K/s 0.00 % 0.00 % rsyslogd -n'
b' 2740 be/4 apache 0.00 B/s 1354.15 B/s 0.00 % 0.00 % httpd -DFOREGROUND'
VMSTAT出力
procs -----------------------memory---------------------- ---swap-- -----io---- -system-- --------cpu--------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 2 194048 334164 612708 12537168 0 1 14 1114 13 217 1 2 95 1 0
0 2 194048 329368 614000 12540308 0 0 646 0 5136 6152 1 1 78 19 0
0 2 194048 324640 615288 12543276 0 0 622 96 5249 6541 1 2 79 18 0
0 2 194048 321584 616624 12546188 0 0 664 512 5660 6815 2 2 81 15 0
0 2 194048 317788 617884 12549124 0 0 626 52 6079 7983 2 3 80 15 0
15930768 K total memory
2445452 K used memory
2673404 K active memory
11678768 K inactive memory
318308 K free memory
617888 K buffer memory
12549120 K swap cache
8212476 K total swap
194048 K used swap
8018428 K free swap
入力/出力スケジューラ
# for d in {b..k}; do echo -n "sd${d} " ; cat /sys/block/sd${d}/queue/scheduler; done
sdb [mq-deadline] kyber bfq none
sdc [mq-deadline] kyber bfq none
sdd [mq-deadline] kyber bfq none
sde [mq-deadline] kyber bfq none
sdf [mq-deadline] kyber bfq none
sdg [mq-deadline] kyber bfq none
sdh [mq-deadline] kyber bfq none
sdi [mq-deadline] kyber bfq none
sdj [mq-deadline] kyber bfq none
sdk [mq-deadline] kyber bfq none
答え1
最後に、問題はファイルレベルの断片化に関連していると思います。
高い断片化率は報告されていませfsckんが、他のツールを実行しました（申し訳ありませんが、どのツールが忘れられた可能性がありますfilefrag）、大容量メディアファイルでは断片化が非常に高いことがわかりました。
（ファイルシステムには1GBのビデオファイルがたくさんあります。）
システムレベルの問題に対する解決策は次のとおりです。
- すべてのファイルをバックアップしてxfsに再フォーマットします（もうext4かもしれませんが、xfsを試してみたい）。
fallocate()システムコールを使用して1GBのスペースを事前に割り当てるようにアプリケーションを変更します。
答え2
コミュニティには何の反応もないので、次はこの問題に対する解決策だと思います。
ファイルシステムでロギングを無効にすると、%waすべてのパーティションで高いI / Oロードが発生しないようです。 （はい、これは他のリスクを引き起こす可能性があることを知っていますが、マシンがI / Oを停止することは私たちのアプリケーションでは決して許容されません。）
以下を使用してログを無効にしましたtune2fs。
tune2fs -O ^has_journal <device>
ノートジャーナルを削除した後も、ファイルシステムはext4のままになりますが、parted今度はfileext2ボリュームとして誤って報告されます。blkidボリュームをとして正しく報告しますext4。
ボイテックトレヴニlibpartedこれはエラーであることを示します。ロギングを無効にした後、報告されたファイルシステムの種類は一貫しません。
私を編集する
ロギングを無効にしても、すべてのシステムの問題は解決されるわけではありません。