☰

仮想サーバーが応答を停止し、CPUを100％使用しています。診断方法は何ですか？

tag-icon • tag-icon centos hang
仮想サーバーが応答を停止し、CPUを100％使用しています。診断方法は何ですか？

CentOS 7.4仮想サーバー（VMware ESXi）では、サーバーの使用量が数秒以内に突然100％に達し、SSHが機能せず、実行中の特定のプログラムが応答しなくなる奇妙な問題が発生しています。唯一の解決策は、vSphereを介してサーバーを強制的に再起動することです。これらの高い使用量の原因を特定することはできません。したがって、私の質問は、このように突然の高い使用量をどのように診断しますか？再起動後に調査するためにいくつかのプロセス情報を記録する方法はありますか？

編集：sshまったく機能しません。実際に私がやりましたが、ssh -vvv詳細な出力が「ホストポート22に接続中」で停止し、シェルは決して返されません。接続が確立されるのを待っているようです。については、ping当社のITエンジニアがサーバーへのICMPトラフィックをブロックしているため、ping動作を確認できません。

答え1

同様の問題が発生したときに、次のような小さなスクリプトを作成しました（CPUとRAMの使用量とともに、毎秒実行されているプロセスの日付とリストを記録します）。

#!/bin/sh
while true
  do 
    date
    ps faux
    sleep 1
  done >> /a/log/file

バックグラウンドプログラムとして実行しています。これは、プロセスがいつどこで中断されるかを理解するのに役立ちます。

/var/log/messagesその後、問題を正確に識別するために、別のログ（おそらくクレイジープログラムのログ）を調べる必要があります。
インストールすることもできます。atsarIO、ネットワークアクティビティ、CPUなどの統計ログを含む素晴らしいバイナリログを提供します。

/!\ Warning:
このスクリプトを十分に長時間実行すると、ログが大幅に大きくなる可能性があります。十分なディスク容量がある場所にログファイルを保存します。それ以外の場合は大きな問題になる可能性があります。

/!\ Warning 2:
esxi設定が何であるかわかりません。ただし、何らかの理由でディスクが esxi 全体で遅延している場合、仮想マシンが IO に依存する場合、これにより重大な遅延が発生し、CPU 使用率が高くなる可能性があります。

編集2：

@sourcejediが述べたように、スクリプトに同期を追加することで、ハードリブート時にログが記録されるようにすることができます（必要なものはわかりませんが、最も安全な2つが1つより優れています）。

#!/bin/sh
    LOGFILE="a/log/file"
    echo "" > $LOGFILE
    while true
      do 
        date
        ps faux
        sync $LOGFILE
        sleep 1
      done >> $LOGFILE

答え2

N個のCPUを搭載したシステムでは、N個のユーザー空間スレッドを実行でき、各スレッドはCPUの100％を使用します。ただし、これを使用しようとすると、sshカーネルはCPU時間の「公正な」共有を提供し、sshログインを許可します。

VMwareでCPU使用率が100％で応答がsshない場合は、カーネル内に使用中のループがある可能性があります。

サーバーがローカルコンソールでグラフィカルインターフェイスを実行していないことを確認してください。カーネルが印刷したすべてのメッセージを表示できるようにテキストモードにしたいです。今読んでください：

文書によると硬いロック検出器（NMI監視機能とも呼ばれます）はデフォルトで有効になっています。カーネルが仮想マシンで実行されているときに無効になっていない限り。したがって、この場合のデフォルト値は巻き取ることです。柔らかいロック。

    /*
     * Hard lockup detection is enabled by default. Disable it, as guests
     * can get false positives too easily, for example if the host is
     * overcommitted.
     */
    hardlockup_detector_disable();

-アーチ/x86/kernel/kvm.c: kvm_guest_init()

私はこれの理論的根拠と歴史について混乱しています。ソフトロック検出器がハードロック検出器よりも「より安全」であると考える理由がわかりません。初期の変化も合理的です。他の理由。 「ゲストPMUはまだエラーをクリアしています。KVM PMUが十分に安定している場合は、デフォルトで有効になっているハードロックに切り替えるというアイデアです。」最後に、一部のハイパーバイザーバージョンでは、NMI監視機能をまったく有効にできない可能性があることが述べられています。

ハイパーバイザーがCPUをあまり使用しないと仮定すると、NMI監視機能も有効にできることを確認できます。上記のリンクを使用するsysctlか、sysctlドキュメントでカーネルブートオプションを使用することもできますnmi_watchdog=1。

次に、カーネルで印刷されたメッセージを表示できるかどうかをテストします。

カーネルパニックが印刷されるかどうかを知るために、「ローカルコンソール」が記録されるか、少なくとも持続しますか？実際はそうですが、シミュレートされたvSphereなどを使用すると、どのように機能するのかわかりません。TVシリーズ快適。アナログビデオディスプレイのみを使用している場合は、すでに持続する状態です。

このVMWare記事同じ仮定に頼っているようです。

コンソールロギングを無効にしていないことを確認してください。 次のコマンドを実行します。

sudo sh -c "echo '<3>test' >/dev/kmsg"

コンソールに「テスト」と表示する必要があります。

シミュレートされたビデオディスプレイの場合、一部の競合メッセージが画面上部でスクロールして消えることがあります。カーネルがクラッシュした場合、Shift+PageUp を使用して上にスクロールできません。原則として、ロールバックを実装するエミュレートされたシリアルコンソールを持つ方が便利です。

カーネルパニックの場合、上記のVMWareリンクにいくつかの異なるクラッシュダンプ提案があります。

-Debian Stretch VMは数日ごとに準応答がなくなります。

リンクされた回答の他のガイドラインの多くは、保留中のジョブメッセージに関するものです。ロックが設定されている場合、必ずしもこれらの内容が表示されるわけではありません。

つまり、とも呼ばれますsysrq。 sysrq+L可能これは有用な情報を得るもう一つの方法です。柔らかいロックしてください。これにより、各CPUのカーネルトレースが生成されます。ただし、根本的な原因はCPUの1つにしか見えないため、そこから多くのメッセージをキャプチャできるはずです。シリアルコンソールがあれば最適です。ビデオコンソールがある場合は、Shift + PageUpを押します。可能CPUが多くないと仮定すると、これが機能します。

関連情報