時々、Webサーバーがクラッシュして起動するのに数時間かかることがあります。これが原因かもしれないと言われましたfsck
。起動中にのみ実行され、インストール後は X 日と Y だけが実行され、サーバーが長時間実行された場合、次回の再起動時に速度が確実に遅くなるためです。
では、この問題を解決するにはどうすればよいですか? 。について知りましたが、tune2fs
cronjobを再起動して調整する必要がありますか?同意すると言いますtune2fs -i 1w /dev/sda1
。その日以降に実行するようにcronを設定すると(使用できる場合-l
)、次の日付に同期されないかどうか心配されます。そうではありませんか?
不明なもう一つの点は、衝突後にfsckがとにかく実行されることです。すべきですか?実行してから一週間も経っていませんが、まだ遅いでしょうか?
答え1
要約:システムログを調べるか、類似のものを使用してくださいbootlogd
、速度低下が発生する位置を示します。私はそうではないと言いますfsck
。
まず、fsck
起動時に必ず実行する必要はありませんが、いつでも実行できます。おそらく、マウントされていないファイルシステムでのみ実行できることに言及しています。/
他のファイルシステムは、システムが完全に実行されたときにマウントされるため、これが実行できる唯一の時間です。それらファイルシステム
fsck
定期的なスキャンのみを実行している場合は、実際にファイルシステムで矛盾を見つけて修正する必要がある場合を除き、完了するまでに数時間かかることはありません(ただし、大規模ファイルシステムで矛盾が多い場合でも1時間はかかりません)。システムログを確認するか、次のものを使用してください。bootlogd
、速度低下が発生する位置を示します。私はそうではないと言いますfsck
。
fsck
ファイルシステムがダーティとしてマークされているかどうかにかかわらず、定期的なスキャンの目的である明白な副作用がないと、ファイルシステムが一貫性を失う可能性があります。
システムの実行中は、ルートファイルシステムをアンマウントできません。これは、ルートファイルシステムが使用中であるため、そのシステムfsck
で実行できず、これを実行するためのクローンジョブを正しく実行できないためです。fsck
特定の日に強制的に再起動した後、再起動することも可能ですが、それは本当に理解できません。 「同期化されていません」とはどういう意味なのかよくわかりません。
クラッシュ後、fsck
ダーティファイルシステム、つまり完全にアンマウントされていないファイルシステムが実行されます。コンピュータが正常に動作している間にクラッシュが発生しても、はい。fsck
動作します。コンピュータがシャットダウンの最後の段階でクラッシュしても、ファイルシステムは破損しないため、クラッシュは発生しません。