kjournaldがほとんど静止しているファイルシステムで非常にアクティブなのはなぜですか？
注：これは、回答を書く「プロセスの文書化」の質問です。幸いなことに、serverfaultはすでにこれを解決するのに役立ちました。なぜなら、他の人がそれを評価できるように私の状況を書き留めることで、何が起こっているのかを理解できたからです。
- Debianサーバーでext3ファイルシステムを使用しています。
- filesに関してメインファイルシステムで発生するアクティビティはごくわずかですが、
kjournald（iotopを介して表示）からの膨大なアクティビティがあります。 - このアクティビティは定期的にバーストして発生し、全体の平均書き込みが約2 MB /秒に上昇します（SSDを入手したいので、このレートは実際には非常に寛大な書き込み耐久性を深刻に脅かすのに十分なので、私にとっては大きな懸念事項です。現在のモデル）。
- 問題のファイルシステムを
noatime,nodiratimeでマウントしました。 - ファイルシステムのジャーナルコミット間隔を5秒から300秒にすでに増やしました。
何が起こっている？ （ネタバレ：それはユーザースペースのものでした。私は主に、おそらく直感に反する根本的な問題を強調するためにこれを書いています。）
何が起こったのかを見てください。このサーバーで実行されるメインアプリケーションは、非常に大規模で人口の多いディレクトリツリーを管理し、所有権とアクセス許可がやや最適ではない状態でそのツリーにファイルを書き込みます。そのアプリケーションにそれを変更させるのはかなり不快であり、ファイルの所有権とアクセス許可を適度に迅速に修正する必要があるため（多少の遅延は問題ありませんが、それほど多くはありません）、毎分大量にスローするcronジョブを設定しましたchown -Rおよびchmod -R大規模で人口の多いディレクトリツリー。それが起こっている間、すべてがうまく動いているように見えたので、私は言った、ええと、それはやり過ぎですが、それはうまくいきます、私はそれと一緒に暮らすでしょう。
ただし。結局のところ、chownまたはchmodを実行すると、ジャーナル可能なextファイルシステムのメタデータが登録されます変更が行われたかどうかに関係なく。したがって、ファイルシステムでは実際には何も変更されていませんでしたが、膨大な量のメタデータが生成され、ジャーナルがコミットされたときにディスクから地獄を叩き出しました。おっと。
そこで、chownとchmodをfindジョブに変更しました。これらのジョブは、変更する前に変更が必要なファイルを実際に検索し、平均書き込み速度は2 MB/sから多分50 kB/s。わーい。