高負荷が原因でサーバーがハングし、エラーが「120秒以上ブロックされる」ことがありますか？

17

現在、いくつかのVMおよび「ベアメタル」サーバーを実行しています。Javaは高稼働しています-時折400％以上。サーバーが「java-120秒以上ブロックされています」-kjournaldなどのコンソールのエラーでランダムにハングします。

何らかの理由でこのエラーはコンソールにのみ書き込まれるため、dmesgの出力を取得できません。これはリモートでホストされているためアクセスできません。したがって、完全なトレースをコピーすることはできません。

私はこれがオンになっている環境を変更しました-物理サーバーであっても、それはまだ起こっています。

これがhttp://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.htmlに従って誤検知である場合に備えて、hung_task_timeout_secsを0に変更しました。

また、irqbalanceはインストールされていません。おそらく役立つでしょうか。

これはUbuntu 10.04 64ビットです。最新の2.6.38-15-serverおよび2.6.36と同じ問題です。

CPUまたはメモリの問題/スワップなしがこの問題を引き起こす可能性がありますか？

コンソールメッセージは次のとおりです。

[58Z?Z1.5?Z840] INFUI task java:21547 blocked for more than 120 seconds.
[58Z?Z1.5?Z986] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?Z06Z] INFUI task kjournald:190 blocked for more than 120 seconds.
[58Z841.5?Z336] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?Z600] INFUI task flush-202:0:709 blocked for more than 120 seconds.
[58Z841.5?Z90?] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?3413] INFUI task java:21547 blocked for more than 120 seconds.
[58Z841.5?368Z] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z961.5?ZZ36] INFUI task kjournald:60 blocked for more than 120 seconds.
[58Z961.5?Z6Z5] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z961.5?31ZZ] INFUI task flush-202:0:709 blocked for more than 120 seconds.
[58Z961.5?3393] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.

linux kernel

— ティー
ソース

15

はい、できます。

これが意味することはかなり明白です。カーネルはタスクを120秒間スケジュールできませんでした。これは、多くの場合ディスクアクセスに関するリソース不足を示しています。

irqbalance役立つかもしれませんが、それは明らかではありません。でこのメッセージの周囲dmesg、特にそれに続くスタックトレースを教えていただけますか？

さらに、これは誤検知ではありません。これは、タスクが永遠にハングアップするということではなく、ステートメントは完全に正しいです。それはそれがあなたにとって問題だということを意味するものではなく、ユーザーへの影響に気付かなければ無視することもできます。

これは次の原因では発生しません。

CPUの問題（または、めったにありえないハードウェア障害）
メモリの問題（ハードウェア障害の可能性は非常に高いが、複数回発生することはない。プロセスのようにRAMが不足することはないoom-killed）、
スワップの欠如（oom-killer再び）。

拡張するには、RAMのデータキャッシュをシステムから奪うとI / Oが増加するという意味で、メモリ不足が原因だと考えられるかもしれません。しかし、「メモリ不足」ほど簡単ではありません。

— ピエールキャリア
ソース

/ var / log / dmesgには何も記録されていないため、コンソールに表示されたものを貼り付けました。これが表示されたら、システムは100％ハングしています。

— ティー

このメッセージはカーネルから送信され、dmesgこのコマンドがカーネルロギングリングバッファーを出力するときに表示されます（最近ログに記録された場合）。syslogセットアップがのどこかに記録されることを願っていますが/var/log、どこにあるのかわかりませんでした。

— ピエールキャリア

メッセージはには表示されませんが、コマンドを実行すると表示される/var/log/dmesg場合がありますdmesg。このファイルは、ブートプロセス中に作成され、通常はブート時のカーネルメッセージのみをキャプチャします（そうしないと、最終的にカーネルリングバッファーからスクロールアウトsysstatされます。 I / O / iowait、おそらくスワッピングに関連しています（sysstatがこれを特定するのに役立ちます）

— Dr. Edward Morbius

@ Dr.EdwardMorbiusでは、これをどのように修正しますか？Zimbraサーバーでこれに関連する大きな問題が発生しています。これは最近まで実稼働環境で問題なく実行されていました。

— 14:45に偏っ

@Lopsided：遅れてすみません、私はここにいないことが多いです。簡単に言うと、Javaプロセスのプロファイルを作成し、ハングしている理由を見つける必要があります。ガベージコレクションは、チューニングで問題（および成功）があった1つの領域です。JVMガベージコレクションエルゴディミクスを調べて、oracle.com / technetwork / java / javase / gc-tuning-6-140523.htmlを参照してください。ヒープの増加が非常に役立つことがわかりました。

— エドワードモルビウス博士14

6

sudo sysctl -w vm.dirty_ratio=10
sudo sysctl -w vm.dirty_background_ratio=5

次に、変更をコミットします。

sudo sysctl -p

私のためにそれを解決しました....

— ニック
ソース

6

それぞれの設定が何をするのかを説明する必要があります。

— カスペルド

6

これにより、ドッカー環境で発生していた同様の問題が修正されました。私はここでの説明を見つけた：blackmoreops.com/2014/09/22/...を。「デフォルトでは、Linuxはファイルシステムキャッシングに使用可能なメモリの最大40％を使用します。このマークに達すると、ファイルシステムはすべての未処理データをディスクにフラッシュし、後続のすべてのIOを同期させます。このデータをディスクにフラッシュするには、デフォルトでは120秒の制限時間の場合には、ここでIOサブシステムは、「...データwithingをフラッシュする十分な速さではありません。

— ピーター・M

2

私は最近、実稼働クラスターの1つでこのエラーを経験しました。

11月11日14:56:41 xxxカーネル：情報：タスクxfsalloc / 3：2393が120秒以上ブロックされました。

11月11日14:56:41 Xxxxカーネル：汚染されていない2.6.32-504.8.1.el6.x86_64＃1

Nov 11 14:56:41 xxx： "echo 0> / proc / sys / kernel / hung_task_timeout_secs"はこのメッセージを無効にします。

..

sarログの結果をさらに確認すると、同じ時間にIO待機が増加しました。

また、ハードウェア（物理ディスク）を確認すると、中程度のエラーと他のSCSIエラーが物理ディスクに記録され、割り当てられるリソースが不足していたためにIOがブロックされていました。

11/11/15 19:52:40：終了pRdm 607b8000 flags = 0 TimeOutC = 0 RetryC = 0 Request c1173100 Reply 60e06040 iocStatus 0048 retryC 0 devId：3 devFlags = f1482005 iocLogInfo：31140000

11/11/15 19:52:40：DM_ProcessDevWaitQueue：プロセスdevId = xのタスクmgmt 11/11/15 19:52:40：DM_ProcessDevWaitQueue：プロセスdevId = xのタスクmgmt

これは、クラスター内のハードウェアエラーが原因でした。

コアファイルをチェックでき、ipmiユーティリティが存在する場合は、ipmiutil / ipmitool sel elistコマンドをチェックして問題をチェックしてください。

よろしく、VT

— バルン・トーマス
ソース

0

クラウドプロバイダーの監視インターフェイスに移動して、ストレージに指定された最大IOpsを超えていないかどうかを確認できます。これは、キャッシュデータのフラッシュに時間がかかった理由を説明します。
最大IOpsは、ストレージ属性ページで利用できます。

— エマニュエル
ソース