1分間操作がないと、ハードドライブがスリープ状態になるように構成しました。これは以前は非常にうまく機能していました。サーバーはほとんどの場合完全に無音でした。しかし最近、ドライブはより頻繁に目覚めています。
何が彼らを眠らせないのかを確認できますか?これはホームサーバーです。
rc.local:
hdparm -M 128 -S 60 /dev/sda
hdparm -S 60 /dev/sdb
更新:サーバーはUbuntu10.04を実行しています。/tmpと/ var /を備えたOSはSSD上にありますが、sdaとsdbはストレージ/バックアップにのみ使用されます。
更新2:私のsysctl.confから:
vm.swappiness = 1
vm.vfs_cache_pressure = 50
vm.dirty_writeback_centisecs = 1500
vm.dirty_ratio = 20
vm.dirty_backgrounds_ratio = 10
これは実際にはあなたが尋ねる質問への答えではありませんが、根本的な問題に役立つかもしれません。私が知っているツールの1つはiotop
ですが、プロセスから簡単なアクティビティをキャッチするのに役立たない場合があります。
活動の潜在的な原因が非常に多いため、アイドル状態のときにハードドライブをスリープ状態にするのは難しい場合があります。システムが何もしていないと思ったからといって、何かがバックグラウンドで書き込まれていないという意味ではありません。一般的な原因は次のとおりです。
commit
マウントオプションで調整できます。auth
ログエントリをトリガーするため、常習的な違反者です。 -
のすべてのログファイル名の前に/etc/syslog.conf
が必要です。本当にディスクをスピンダウンさせたい場合は、 noflushd を確認してください。それは実際に機能します(または少なくとも以前は、最近はあまり保守されておらず、最新のカーネルで問題が発生する可能性があります)。ただし、これはハックであり、非常に手間がかかることに注意してください。キャッシュがいっぱいになるか、ディスクが読み取りのためにウェイクアップするまで、カーネルの書き込みを停止するだけです。
沈黙を探しているなら、 大いに役立つ テクニックは ディスクをエラスティックから吊り下げる 直接マウントするのではなくすることです。これは消費電力の削減には役立ちませんが、10krpm以上のドライブ(とにかくファンのスクリーマーが必要)がない限り、CPUとマザーボードはアイドル状態でもおそらく主な電力消費です。
詳細ログをオフにしていることを確認してください。ファイアウォールルールによってログに記録されている特定のポートでブロードキャストを送信しているマシンがある場合、ドライブがスピンダウンしないように十分なエントリを簡単に取得できます。 HPプリンターとWindowsマシンは、ローカルネットワーク上の他のマシンをチェックするためにブロードキャストを送信することで有名であり、ほとんどのファイアウォールルールはそれらの要求をログに記録します。
実行しているサービスをチェックして、独自のファイルにログを記録している可能性があるかどうかを確認します。ファムを走らせていますか? swappinessは、RAMからスワップに常に物事をシャッフルしているほど高く十分なサービスを設定しましたか? cronジョブ?
iotop
を試しましたか?