duコマンドの実行に時間がかかりすぎる
私は走っているdu -shディスクホグを検索するために、さまざまなディレクトリにあります。私は2台の同一のサーバー（Dell PE2850s）を入手しましたが、どちらもRHEL5を搭載しており、一方のサーバーでduを実行すると、他のサーバーよりもかなり時間がかかります。
たとえば、du -sh /opt/foobarサーバーA（約25 GB）で5分かかります。サーバーBでは、同じコマンドで同じ量のデータを使用すると、ほぼ瞬時にレポートが返されます。トップなどを走らせたときに、明白なものは何も見当たりません。
アドバイスは大歓迎です。
そのディレクトリに膨大な数のファイルがあり、ディレクトリの内容が絶えず変化する場合、ディレクトリエントリ自体が時間とともに断片化されます。次に、OSがディレクトリの内容を読み取っているときに、不要なディスクシークが大量に発生します。これは特にext *ファイルシステム（ext4の方が良いかもしれません）と古いReiserFS v3.xファイルシステム（85％を超えた場合など）で特に発生します。
解決策は非常に簡単です。
cp -pr origdir newdir
mv origdir origdir.bak
mv newdir origdir
もちろん、すべてがRAMにキャッシュされている場合、これはそれほど重要ではありません。通常、Linuxは頻繁にアクセスされるファイルをキャッシュし、かなり積極的に低下します。これらのディレクトリの内容を本当にRAMに保持したい場合は、ls -lah /your/dir 2>&1 >/dev/nullをcronに追加します。
編集：ああ、心に浮かんだことが1つあります。サーバーにバッテリーバックアップされたRAIDコントローラーがあり、その中に何らかのキャッシュが組み込まれている場合は、バッテリーに問題がないことを確認してください。バッテリーがなくなり、コントローラーがキャッシュを完全に無効にして、パフォーマンスを非常に悪化させる状況を見てきました。たとえば、HPサーバーはiLOログでコントローラーバッテリーについて何かを伝えます。実際のサーバーヘルスダッシュボードでは、すべてが正常で緑色のように見えますが、これについてはログエントリのみが通知します。
スイッチなしで簡単なduコマンドを試すことをお勧めします。最終的に、どのディレクトリがプロセスを遅くしているのかがわかります。ディスクに問題があるか、その他の理由が考えられます...