私は長い間 (おそらく 7 年) 24 時間 365 日 Debian を実行しているマシンを持っています。2 週間前、サーバーの場所を移動し、Debian Jessie (wheezy を実行していました) にアップグレードすることにしました。
すべて順調に進みましたが、5 ～ 6 分ごとにサーバーが約 20 秒間接続に応答しなくなりました。
それがいつ起こるかをチェックするスクリプトを作成しました。時間は次のとおりです。
2017-01-12 16:16:05 TIMEOUT!
2017-01-12 16:21:49 TIMEOUT!
2017-01-12 16:27:32 TIMEOUT!
2017-01-12 16:33:13 TIMEOUT!
2017-01-12 16:39:01 TIMEOUT!
...
2017-01-12 17:07:59 TIMEOUT!
2017-01-12 17:13:47 TIMEOUT!
2017-01-12 17:19:25 TIMEOUT!
サーバー上で仮想マシンを実行していますが、パケットは遅延なく正常に到達しています。サーバー上のさまざまなポート (80、443、9000 など) をテストしましたが、すべてタイムアウトになりました。たとえば、ssh を実行しているサーバーで、タイムアウト中にコマンド (たとえば、「ls」を 3 回入力する) を実行すると、回復後に 3 つの「ls」を受信して実行します。
サーバーのログを確認しましたが、関連する情報は見つかりませんでした。
編集: ping を実行したままにしておくと、タイムアウトが表示されません。
編集2: さて、もう1つ奇妙なことがあります。サーバーでsshにアクセスし、ping 8.8.8.8 (またはおそらくテキストを出力する任意のコマンド) を実行すると、タイムアウトが発生し始めますが、ping のテキスト出力は問題なく表示されます。CTRL+C でキャンセルすると、ping の最小/平均/最大ステータスが表示されますが、コマンド (たとえば「ls」) を入力すると、サーバーが再び使用可能になるまで待機して、ファイルのリストが表示されます。
編集3: つまり、ディスク関連の問題かもしれません。sda は Samsung SSD 840 Pro 120GB です。
iostats は次のように表示します。
通常の行動:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 2.00 0.00 20.00 20.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-0 0.00 0.00 0.00 2.00 0.00 20.00 20.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 2.00 0.00 20.00 20.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
タイムアウト動作:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 136.00 0.00 69124.00 1016.53 127.69 1053.93 0.00 1053.93 7.35 100.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 16.00 0.00 18.50 0.00 540.00 58.38 0.10 5.51 0.00 5.51 1.19 2.20
dm-0 0.00 0.00 0.00 1.00 0.00 4.00 8.00 521.34 363490.00 0.00 363490.00 1000.00 100.00
dm-1 0.00 0.00 0.00 1.00 0.00 4.00 8.00 521.35 363492.00 0.00 363492.00 1000.00 100.00
dm-2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
答え1
使用後iostatそしてiotop診断の結果、問題はデータベースをディスクに永続化する redis-server にあり、データベースの増大により、何らかの理由でディスクに書き込まれた内容がネットワーク トラフィックをブロックし、それがタイムアウトの原因 (ディスクへの書き込みの集中) であることが分かりました。
ディスクに永続性が必要ないため、これを無効にしたところ、再び正常に動作するようになりましたが、redis-server がなぜこのように動作するのかはわかりません。