私たちのアプリケーションは、巨大なリングバッファ（30〜150TB）でディスクにデータを書き込みます。新しいファイルは、古いファイルの削除中に記録されます。したがって、定義によると、ディスクは常に「ほとんどいっぱいです」。
これ作家このプロセスは、約100〜150 Mbits / sの正味入力速度でさまざまなファイルを生成します。データファイルは、1 GBの「データ」ファイルと複数の小さなメタデータファイルが混在しています。 （入力速度は一定ですが、新しいファイルセットは2分ごとに作成されます。）
別の削除者30秒ごとに「最も古い」ファイルを削除するプロセスです。ディスクの空き容量が15 GBに達するまで削除され続けます。
したがって、安定して実行されると、すべてのデータパーティションの空き容量は15 GBしかありません。
存在するこの問題ファイルシステムの速度低下に関して憂鬱なダニエルコメントしました：
同期の中断は、単にファイルシステムが最新の操作を一貫して保存するのに苦労していることを意味します。その時点で、ディスク上のデータを移動しようとします。詳細はわかりませんが、ファイルシステムが真剣に断片化されている場合は、ext4がこれに対処することを確信しています。ファイルシステムがほぼ100％いっぱいになると悪いです。 100％に近い容量でファイルシステムを利用する唯一の合理的な方法は、一部のファイルで静的に初期化してから同じファイルを上書きすることです（断片化を防ぐため）。おそらくext2/3に最適です。
ext4はこのアプリケーションに適していない選択ですか？これでリアルタイムで実行されているので、断片化、速度低下、またはその他のパフォーマンス制限を防ぐためにext4をどのように調整できますか？ ext4で変更するのは非常に難しいでしょう...
（静的に生成されたファイルを再構築することは、アプリケーション全体を再構築することを意味します）
ありがとうございます！
私を編集する
サーバーには50〜100 TBのディスク（24台のドライブ）が接続されています。 Areca RAIDコントローラは、24台のドライブをRAID-6 RAIDセットとして管理します。
そこで、それぞれ5TBから10TBの範囲の複数のパーティション/ボリュームに分割されました。したがって、ロールのサイズはそれほど大きくはありません。
「作成者」プロセスは、「十分な」スペースを持つ最初のボリュームを見つけ、そこにファイルを書き込みます。ファイルが作成されたら、プロセスを繰り返します。
新しいシステムでは、ボリュームが順次充填されます。すべてのボリュームが「いっぱい」になると、「十分な」スペースが利用可能になるまで、「プログラムの削除」プロセスは最も古いファイルの削除を開始します。
時間が経つにつれて、他のプロセスの操作により、ファイルの時系列順がすべてのボリュームにランダムに分散されます。
編集2
ランはfsck1〜2％の非常に低い断片化を示しています。しかし、同時に遅いファイルシステムへのアクセスは、他のさまざまなシステムコールのために実行に時間がかかることを追跡しましたfclose()（fwrite()5〜60ftello()秒！）。
これまで、この問題に対する解決策はありません。詳細については、この問題を参照してください。非常に遅い（200秒）fwrite（）/ftello（）/ fclose（）をデバッグする方法は？
無効にsysstatし、raid-check改善があることを確認しました。
答え1
原則として、リングバッファの書き込みを厳密にすると断片化に問題が発生する理由がわかりません。簡単なようです。私の考えでは、この説明はより一般的な書き込み作業量に基づく推奨事項です。しかし、リンクされた質問を見ると本当の問題があるようです...
断片化に興味があるので、それを測定する方法を検討する必要があります！ e4defrag存在する。 2つのオプションしかありません。 -c現在の状態のみが表示され、デフラグは実行されません。 -v各ファイルの統計を表示します。すべてのオプションの組み合わせが有効です（オプションなしを含む）。実行中のシステムに対するパフォーマンスの影響を制限する明示的な方法はありませんが、e4defrag個々のファイルに対する実行をサポートしているため、直接速度を制限できます。
（XFSにもデフラグツールがありますが、私は試したことがありません。）
e2freefrag空き領域の断片化を表示できます。 もしCFQ IOスケジューラを使用している場合は、低いIO優先順位で実行できますionice。
引用された推測は間違っており、Stephen Jeterの答えは正確でした。 ext4 は自動デフラグを実行しません。記録されたデータを「シャッフル」しようとしません。
この奇妙な誤解を放棄すると、「ext2 / ext3」を提案する理由はありません。それ以外の場合、現在カーネルにext3コードがありません。 ext4 コードは ext3 をマウントするために使用されます。 ext3 は ext4 のサブセットです。特に比較的大きなファイルを生成する場合、範囲を使用しないことは愚かなように見えます。これはext4に固有の機能です。
私は「絞首刑」がジャーナリングとより頻繁に関連していると思います。 （ファイルシステムの進行中）の説明を参照してください。bcachefs-
テールレイテンシは長年にわたりext4ユーザーの悩みでした。ロギングコードや他の場所の依存関係により、マルチスレッドワークロードでの単純な操作（切断）などの30秒以上の遅延が発生する可能性があります。誰も問題を解決する方法がわからないようです。
bcachefsがIOでスレッドをブロックする唯一の理由は、スレッドがそれを明示的に要求した場合（キャッシュされていない読み取りまたはfsync操作）、またはリソースが使い果たされた場合（完全停止）です。 IO の実行中にフォアグラウンド操作をブロックするロックは維持されません。 bcachefsはまだリアルタイムファイルシステムではありませんが（IOのリアルタイム予約機能が不足しています）、いつかリアルタイムファイルシステムになる可能性があります。
XFSを使用して上記の問題をどの程度回避できるかを説明するように依頼しないでください。わかりません。ただし、代替ファイルシステムの設定テストを検討している場合は、XFSが私が試す最初の設定です。
ext4でロギングを無効にすると、どのような影響があるかについて多くの情報を見つけようとしています。少なくともパフォーマンスをチューニングするときに考慮される一般的なオプションの1つではないようです。
なぜsys_sync（）を使うのかわかりません。一般的に避けるのが最善です（例：ここ）。これが実際にあなたの問題を説明しているかどうかはわかりませんが、範囲を狭くしようとしている間に発生した不幸なようです。
答え2
別の方法がありますが、もう少し複雑です。
10個または20個などの小さなパーティションをたくさん作成します。 LVM2このような状況で役に立ちます。次に、次のようにリングバッファの形式でパーティションを使用します。
パーティションの1つは常に「アクティブ」パーティションであり、完全またはほぼ完全になるまで新しいデータがそのパーティションに書き込まれます。ヘッドルームを残す必要はありません。アクティブパーティションがいっぱいになった場合、または次のデータブロックを収容するのに十分な空き容量がない場合は、次のパーティションに切り替えると、そのパーティションがアクティブパーティションになります。
削除プロセスは、常に少なくとも1つの完全に空のパーティションが利用可能であることを確認します。そうでない場合 – これが重要な部分です – それは単に再フォーマット最も古いパーティションからまったく新しいファイルシステムを作成します。この新しいパーティションは、後で断片化を最小限に抑えたり、まったく使用せずに新しいデータを受信したりできます。
答え3
この問題は、ほぼ確実にext4 delalloc（遅延割り当て）のデフォルトのext4マウントオプションが原因で発生します。同期（明示的同期または定期的に実行される暗黙的な同期）まで、新しいファイルを書き込む場所を決定するのに遅延が発生します。ファイルシステムがいっぱいになった場合、このタスクには、ディスク上の既存のファイルを移動して新しいファイルの連続ファイルを作成することが含まれます。 。スペース。
マウントオプションにnodellallocを追加すると、問題が解決する可能性があります。これにより、元の書き込みが発生したときにext4が強制的にスペースを作成します（スペースを作成するために既存のファイルを移動する必要がある場合）。ファイルシステムがいっぱいになると、生の書き込みが遅くなり、バッファキャッシュが書き込みに使用できないように見えます。しかし、データがファイルに残っているので、同期が完了するまで問題を遅らせるよりも優れています。システムに長い時間がかかりました。電源が切れると、バッファキャッシュが失われる可能性があります。
通常、delallocは、作成する新しいファイルの合計サイズを知ってから、ファイルを配置する場所のみを決定することによって断片化を最小限に抑えるので、これが推奨されます。ただし、nodellallocを使用しても、ext4は可能な限り事前に大きなスペースを選択しようとしているため、断片化を減らすのに効果的です。