Ubuntu 14.04を使用して30分間実行した後ハイブリッドSSDを使用する多くのプロセスがありますiotop
。たとえば、geditで空のファイルを開いて閉じると、dconf書き込み設定のために閉じるのに2秒かかることがあり、これは同様の方法で他のユーザーにも影響します。システム全体。
straceを使用してfsync呼び出しを再追跡し、そこでsyncコマンドを使用してそれを再現しました。
要約すると、sync
端末で単に繰り返し実行するのに1〜2秒かかりますが、稼働時間は30分後にのみ可能です。
これを実証するために、同期を実行するのにかかる時間に基づいて稼働時間を秒単位で出力するスクリプトを作成し、毎秒実行しました。
while true;
do
cat /proc/uptime | awk '{printf "%f ",$1}'; /usr/bin/time -f '%e' sync;
sleep 1;
done;
上記のスクリプトを実行して約1時間待ってから(システムがアイドル状態)、gnuplotに結果を表示しました(y =同期実行時間(秒)、x =稼働時間(秒))。
グラフは約1780(1780/60 =約30分)でピークに達します。
この時点では、スクリプト以外のものをディスクに書き込まないでください。したがって、最初の同期の後、ページキャッシュにほとんど何もないはずであり、その後の各同期はスクリプトに書き込まれる内容を正確に記録します(約100バイト)。 。
たとえば、再起動後も問題は解決しません。 30分間スピードが遅くなるのを待ってから再起動すると、スピードの低下が発生し続けます。電源を切ってからもう一度入れると、30分後に問題がなくなります。
もう一つの興味深い点は、上記の画像を見直して速度低下が発生する領域を拡大すると、次のような結果が生じることです。
最高点と最低点は最低点から最低点にほぼ10秒ごとに繰り返され、最高点と最低点は落ちながらねじれもします。
また、速度を遅くする前にhdparmテストを実行しました(hdparm -t /dev/sda
および)。hdparm -T /dev/sda
/dev/sda:
Timing cached reads: 23778 MB in 2.00 seconds = 11900.64 MB/sec
/dev/sda:
Timing buffered disk reads: 318 MB in 3.01 seconds = 105.63 MB/sec
不況の間:
/dev/sda:
Timing cached reads: 2 MB in 2.24 seconds = 915.50 kB/sec
/dev/sda:
Timing buffered disk reads: 300 MB in 3.01 seconds = 99.54 MB/sec
これは、物理ディスクの読み取りは影響を受けませんが、キャッシュの読み取りは影響を受けることを示しています。これは、ハードドライブではなく、システムバスに関連しているという意味ですか?
私が試した解決策は次のとおりです。
ハードドライブの速度低下設定を変更すると、ハードドライブがスリープモードに入ることがあります。
hdparm /dev/sda -S252 #(set it to 5 hours before spindown)
ファイルシステムのログタイプをソートではなく書き込み保存に変更すると、パフォーマンスは向上する可能性がありますが、30分間遅くならない稼働時間を考慮していなかったため、問題は解決されませんでした。
30分後に発生するように見えるため、CRONを無効にします。
CPU使用量は良好で完全にアイドル状態なので、どのプロセスのせいにも回すことはできませんが、セッションマネージャ(lightdm)を含むすべてのサービスをオフにしようとしましたが、問題が低いと考えて何もしませんでした。
30分後に入ってきた新しいプロセスを分析すると、何の変化もありませんでした。 PSの出力前と後を比較してみると違いはありませんでした。
この問題は、わずか2週間前から何もインストールされず、更新も行われていない状態で発生し始めました。この質問ははるかに低いレベルだと思うので、ここで助けてくれて本当にありがとう。私は何も知らず、正しい方向を指すことでさえも役立ちます。たとえば、ページキャッシュが更新されていることを確認する方法はありますか?
問題のディスクで書き込みキャッシュが有効になっており、書き込み障壁も無効にしてみました。ハードドライブのスマートデータは、ハードドライブ自体には何の問題もないことを示唆していますが、再起動後も持続するため、ハードドライブが不思議なことをしていると疑われます。
編集する:
私はそれを完了しました:
watch -n 1 cat /proc/meminfo
...メモリがどのように変化するか、特にダーティラインと書き換えラインを見ると、これがHDディスクバッファのようです。ほとんどゼロに保たれ、最大300kbまで維持されます。 syncを呼び出すと、期待どおりにゼロにフラッシュされますが、ダーティページがなく、ディスクバッファに0kbがある場合にsyncを呼び出すと、速度が遅くなってもIOはロックされ続けます。ページキャッシュと書き込みキャッシュをフラッシュする方法がない場合は、同期で何ができますか?
答え1
これらの症状はほとんどの飽和IOシステムと非常に一致していますが、OS /ユーザースペースの観点から発生するIO負荷を大幅に排除しながら、ドライブが独自のテストを実行している可能性があります。すべての分野を読んだ。これはsmartctlで照会可能/調整可能でなければなりません(クエリには少なくとも1つのsmartctl -cが使用されます)。
今急に来て消え始めた理由は次のとおりです。
- ドライブがライフサイクルの特定のステップ(記録されたセクタの数、回転時間など)を通過し、ドライブのファームウェアが検索の1つをトリガーしました。
- 私はこれがsmartctlを介してもトリガーされる可能性があると思うので、一部の自動化されたプロセスはそれをトリガーするかもしれません。
- スキャンのいずれかをトリガし、進行中または開始済みとしてマークします。ドライブがしばらく点灯している場合は、最初からやり直すか、中断した部分から再起動します。