最近、ハードウェアの移行後、デスクトップDebian Stretchシステムに影響を与える奇妙なI / O一時停止が発生し始めました。各停止中に発生する一般的な症状は次のとおりです。
WebブラウザChromiumと対話できません。何も機能しません：Webページのスクロール（通常これが一時停止を確認する方法です）、タブ切り替えなど。 Web や Chromium UI ではマウスオーバーの動作もありません。
仮想端末内では新しいプロセスを実行できなくなりました。たとえば、新しいタブを開い
mate-terminalたがシェルは表示されず、カーソルだけが点滅します。停止する前にシェルが開いていた端末でコマンドを入力できますが、通常は起動しませんsudo something。RStudioのような他のプログラムはディスクに何も保存できず、保存しようとすると中断されます。
journald -f一時停止が十分に長い場合は、journald自動的に再起動することをログに表示できます。たとえば、次のようになります。sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Main process exited, code=killed, status=6/ABRT sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Unit entered failed state. sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Failed with result 'watchdog'. sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Service has no hold-off time, scheduling restart. sty 30 14:03:54 liori-pc systemd[1]: Stopped Flush Journal to Persistent Storage. sty 30 14:03:54 liori-pc systemd[1]: Stopping Flush Journal to Persistent Storage... sty 30 14:03:54 liori-pc systemd[1]: Stopped Journal Service. sty 30 14:03:54 liori-pc systemd[1]: Starting Journal Service... sty 30 14:03:54 liori-pc systemd-journald[23935]: Journal started sty 30 14:03:54 liori-pc systemd-journald[23935]: System journal (/var/log/journal/2318080f60e357aaf765e98d0000035c) is 2.1G, max 4.0G, 1.8G free.dm_cryptを使用すると、1つの
dmcrypt_writeプロセスが単一のCPUコアの100％を占め始めました。その後、このシステムからdm_cryptを削除しましたが、停止現象は引き続き発生します。私は
/proc/meminfoこのDirty数が数メガバイトを超えないことを観察しました。停止中にこの数字が変わらないことは注目に値します。まれに、「情報：「一部のプロセス」の操作は120秒以上ブロックされました」という形式のカーネルメッセージを受け取ります。ここで、「一部のプロセス」は通常、mdX_raid5、chromium、またはそのスレッドのいずれかです。ログの例。
当初、私の設定は、単一の1TBドライブ（現在の）パーティションに単一の600GB ext4ファイルシステムでした/dev/sdd。次に、LVMベースのraid5、bcache（キャッシュがSSDドライブにある）、dm_cryptを使用して3×6TBドライブ（）に移動しました/dev/sd{b,c,e}。この時点で停滞が始まりました。デバッグ中にLVM-raid5で単純化し、bcacheやdm_cryptはまだ中断されませんが、今はあまり頻繁に発生していないようです。
このストールは1日に数回発生し、通常は数分間続きます。私は特定のディスク操作を明示的に要求してそれを破ることができることに気づきました。場合によっては、リモートシステムからそのシステムにSSHを介して接続するか（ほとんどの場合）、cat /dev/sdb >/dev/nullまたはcat /dev/sdc >/dev/null（時には1つ、時には他のものが機能しない）で壊すことがありますcat /dev/sde >/dev/null。役に立ちます）。すると止まっていたすべてが突然再び動き始めました。
したがって、問題は、次のいずれかまたは相互作用が原因であると疑われます。
- ハードドライブ：3つのハードドライブはすべてSeagate Skyhawk ST6000VX0023です。そのうちの2つはこの設定で以前に使用されておらず、3番目は半年です（
/dev/sdc）。 - ディスクコントローラ：マザーボード：
Gigabyte Z68X-UD3H-B32つのコントローラがあります。Marvell 88SE9172ドライブの1つはチップセット内蔵コントローラ（Intel® Z68）に接続されており、他の2つのコントローラはソフトウェアで確認できます（どこがどこにあるかを確認できますか？）。 - コントローラカーネルドライバのいくつかのバグ。
- LVMまたはraid5のいくつかのバグ。
これはいくつかのバックポートパッケージ、特にカーネルがインストールされたDebian Stretchシステムです4.19.0-0.bpo.1-amd64。 Intel Core i7-2600k、16GB RAM。
この時点で私はアイデアが不足していました。この問題をさらにデバッグするにはどうすればよいですか？
編集：4秒ごとにこれらのドライブの1つからランダムセクタを読み取るスクリプトを開始しましたが、これまで中断せずに2日が経ちました。したがって、一部のシステムコンポーネント（LVM？raid？）が必要な場合、一部の低電力モードではデバイスを正しく起動できないようです。
編集：このシステムにアクセスできなくなったため、これ以上の仮説をテストすることはできません。私が言うことができるのは、このスクリプトを実行した後に一時停止が発生しなくなることです。しかし、デバッグする方法を知りたいです。
答え1
6TBモデルでは、Seagate Skyhawkモデルの「準備待機」時間は23〜30秒です。 1TBモデルの場合、この数値は6ミリ秒です。 2TBに切り替えると、遅延時間が大幅に増加します。あなたのドライブがアイドル状態になり、I / Oのみをバッファリングしてドライブに書き込もうとすると、回転中に停止するようです。
ドライブは、アクティブ、アイドル、スタンバイ、およびスリープの4つの電源管理モードをサポートします。マニュアルの関連部分説明する:
「ドライブがアクティブ機能（読み取り、書き込み、またはナビゲーション）を実行するたびにスタンバイタイマーが再初期化され、指定された遅延時間からゼロまでカウントダウンが開始されます。ドライブアクティビティが必要になる前にスタンバイタイマーがゼロに達すると、ドライブはドライブはアイドルモードとスタンバイモードの間スタンバイモードになり、ディスクアクセスが必要なときにアクティブモードに戻ります。
Linux内でスタンバイモードを削除するために電源管理モードを変更することは容易ではありません。ドライブベンダーはこの種のユーティリティを提供しますが、通常はISOを起動するかWindows専用ユーティリティを使用する必要があります。 hdparmを使用して待機タイムアウトを調整することに成功しました。はじめにチュートリアル。