web-dev-qa-db-ja.com

sync / fsyncを呼び出すと、30分の稼働時間後にIO

Ext4でUbuntu14.04を使用して30分間稼働した後、 ハイブリッドSSD iotopを使用してIO）をブロックしている多くのプロセスが表示されます。

この速度低下の根本的な原因は、Unixシステムコール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 =秒単位の稼働時間）：

slowdown graph

グラフが表示される時点は約1780（1780/60 =約30分）です。

この時点では、スクリプト以外はディスクに何も書き込んでいないはずです。したがって、最初の同期後、ページキャッシュにはほとんど何もないはずです。後続の各同期では、スクリプトに書き込まれている内容が正確に書き込まれます。これは、約100バイトまたはそう。

cat /proc/meminfoをチェックすると、ダーティ行（ディスクに保存する必要があるページキャッシュ内のデータ？）とライトバック行（HDディスクバッファ？）がすべてゼロになっています。私の考えでは、syncを呼び出すと、これらのディスクキャッシュがフラッシュされますが、それらのキャッシュに何もない場合でもフリーズするので、他のことをしますか？

この問題は再起動後も解決しません。たとえば、スローダウンを30分待ってから再起動すると、スローダウンは引き続き発生します。電源を切ってから再起動すると、30分後まで問題は解決します。

もう1つの好奇心は、上のグラフを調べて、速度低下が発生している領域を拡大すると、次のようになったことです。

slowdown graph zoomed

山と谷が繰り返されます。これは、谷から谷まで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

実際のディスク読み取りは影響を受けていないが、キャッシュされた読み取りは影響を受けていることを示しています。これは、結局のところ、HDではなくシステムバスに関係していることを意味しますか？

これが私が試した解決策です：

  • HDのスピンダウン設定を変更します（おそらくHDは省電力モードに入っていましたか？）：

    hdparm /dev/sda -S252 #(set it to 5 hours before spindown)

  • ファイルシステムのジャーナリングタイプを順序付けではなくライトバックに変更して、パフォーマンスを向上させます。これを試したときに30分のスローダウンのない稼働時間を説明していないため、問題は解決していません。変更はありませんでした。

  • ラウンド30分後に発生しているように見えるため、CRONを無効にしました。

  • CPU使用率は問題なく、完全にアイドル状態であるため、プロセスのせいにすることはできませんが、セッションマネージャー（lightdm）を含むすべてのサービスをシャットダウンしようとしましたが、問題は低レベルであると考えているため、これは何もしません。

  • 30分に到着する新しいプロセスを分析すると、変更がないことがわかります。PSの出力を前後で比較しましたが、違いはありません。

これは約2週間前に発生し始め、何もインストールされず、その頃に更新は行われませんでした。私はこの問題がはるかに低いレベルだと思っているので、私は無知なので、ここでいくつかの助けを本当に感謝します、正しい方向に私を向けることさえ役立つでしょう。

問題のディスクで書き込みキャッシュが有効になっています。書き込みバリアを無効にしてみました。 SMART HDのデータは、HD自体に問題がないことを示していますが、再起動後もHDが持続するため、HDが不思議なことをしているのではないかと疑っています。

linuxubuntuperformanceunixfilesystems
6
alex.p

これは、問題のドライブに対して SMART data が有効になっていることが原因でした。

SMARTデータを無効にするとこれが解決しました：

Sudo smartctl --smart=off /dev/sda

興味深いことに、ドライブのSMARTデータを再度有効にしても、問題は返されません。これは、SMARTが一貫性のない状態にあったことを示唆しています（自己の間にクラッシュする可能性があります） -テストが実行されていましたか？）そしてそれをオフにしてから再びオンにすると、その状態がリセットされます。

おそらく、ディスクがスピンアップしてループに入ってから30分後に、ある種の内部セルフテストを再実行し続けました。これはハードウェア層にあったため、コンピューターの他の部分はそれが進行していることに気づかなかったため、IOブロッキングの原因となるプロセスはなく、リソースを占有するプロセスもありませんでした。

何が悪いのかを解明しようとしながらSMARTセルフテストを実行しましたが、それでも状態はリセットされませんでした。スイッチをオフにしてから明示的にオンにする必要がありました。

3
alex.p

この問題は再起動後も解決しません。たとえば、スローダウンを30分待ってから再起動すると、スローダウンは引き続き発生します。電源を切ってから再起動すると、30分後まで問題は解決します。

これは、SSD自体にファームウェアのバグがあり、電源を入れてから30分後に表示されることを示しています。

2
MikeyB