再起動がソフトウェアによって発生したのか、ハードウェアによって発生したのかをデバッグする方法は？

Question 1

「ワット数の増加？」を使用して、システムの消費電力をより詳細に監視します。電力計は、これらの再起動が電源装置の過電流保護（OCP）の活性化によって引き起こされることを保証します。

起動後15分後に電力消費が増加した理由を尋ねる質問にserverfaultの答えは、起動後15分後に74ドライブすべてが自動オフラインSMART（ハードドライブセルフモニタリング、分析、レポート）を同時に実行し始めることができるということです。。時間技術）テスト。

次の試みは、自動オフラインテストの実行を無効にすることでしたsmartctl --offlineauto=off /dev/sdx。 20時間が経過したため、電源投入や再起動なしで、最初の結論は、定期的なオフラインSMARTテストを実行するようにドライブを設定したことが原因でした。

Answer

「ワット数の増加？」を使用して、システムの消費電力をより詳細に監視します。電力計は、これらの再起動が電源装置の過電流保護（OCP）の活性化によって引き起こされることを保証します。

起動後15分後に電力消費が増加した理由を尋ねる質問にserverfaultの答えは、起動後15分後に74ドライブすべてが自動オフラインSMART（ハードドライブセルフモニタリング、分析、レポート）を同時に実行し始めることができるということです。。時間技術）テスト。

次の試みは、自動オフラインテストの実行を無効にすることでしたsmartctl --offlineauto=off /dev/sdx。 20時間が経過したため、電源投入や再起動なしで、最初の結論は、定期的なオフラインSMARTテストを実行するようにドライブを設定したことが原因でした。

Question 2

まず、72台のハードドライブは大量です（私の最大のコンピュータには24台しかあり、電源装置は1200Wです）。すれ違った回転を使用してください。

ドライブがオフラインデータ収集を開始していることがわかります。これは電気使用量の増加を説明することができる。これは、実際にドライブを使用している場合、消費電力が少なくともそれだけ高くなる可能性があることを意味します。

ドライブ仕様シートには、12Vレールのピーク電流が2Aで示されています。あなたの電源は12Vレールで87.5Aを提供できると主張します。したがって、特に他のコンポーネントにもいくつかの値が必要であるため、この値を簡単に超えることができます。これが発生することを確認するために、そのレールに電圧計（可能であれば電流計）を取り付けることをお勧めします。

私は引き続き答えが「はい」と推測します。実行中の供給装置はドライブの数に比べて少なくなります。たとえば、私たちが使用するシステムビルダーは1400W電源を備えた45ドライバJBOD、より多くのドライブとコンピュータがあります。もちろん、このJBODは15K SASドライブ用に指定することもできます。しかし、さらに27台のドライブがあります。

ソフトウェア競合のデバッグ（そうでない可能性があります）

ソフトウェアの競合を見つけようとするときに最も重要なのは、カーネルログを最後の瞬間まで取得することです。シリアルポートがある場合、最良の方法は別のコンピュータに接続してシリアルコンソールを使用することです（カーネルコマンドラインにconsole = / dev / ttyS0,57600を追加する）。 2番目に良い方法は、netconsoleを使用することです。これは、システムの起動後（ただし16分前）に簡単に設定できます。

まず、別のコンピュータで実行しますnc -l -u -p 1234。その後、常にクラッシュするコンピュータでは、modprobe netconsole netconsole=@/eth0,1234@some-ip/netcatウィンドウにいくつかのコンソールメッセージがすぐに表示されます。

[508073.196581] console [netcon0] enabled
[508073.197026] netconsole: network logging started

もちろん、タイムスタンプははるかに低いでしょう。

Answer

まず、72台のハードドライブは大量です（私の最大のコンピュータには24台しかあり、電源装置は1200Wです）。すれ違った回転を使用してください。

ドライブがオフラインデータ収集を開始していることがわかります。これは電気使用量の増加を説明することができる。これは、実際にドライブを使用している場合、消費電力が少なくともそれだけ高くなる可能性があることを意味します。

ドライブ仕様シートには、12Vレールのピーク電流が2Aで示されています。あなたの電源は12Vレールで87.5Aを提供できると主張します。したがって、特に他のコンポーネントにもいくつかの値が必要であるため、この値を簡単に超えることができます。これが発生することを確認するために、そのレールに電圧計（可能であれば電流計）を取り付けることをお勧めします。

私は引き続き答えが「はい」と推測します。実行中の供給装置はドライブの数に比べて少なくなります。たとえば、私たちが使用するシステムビルダーは1400W電源を備えた45ドライバJBOD、より多くのドライブとコンピュータがあります。もちろん、このJBODは15K SASドライブ用に指定することもできます。しかし、さらに27台のドライブがあります。

ソフトウェア競合のデバッグ（そうでない可能性があります）

ソフトウェアの競合を見つけようとするときに最も重要なのは、カーネルログを最後の瞬間まで取得することです。シリアルポートがある場合、最良の方法は別のコンピュータに接続してシリアルコンソールを使用することです（カーネルコマンドラインにconsole = / dev / ttyS0,57600を追加する）。 2番目に良い方法は、netconsoleを使用することです。これは、システムの起動後（ただし16分前）に簡単に設定できます。

まず、別のコンピュータで実行しますnc -l -u -p 1234。その後、常にクラッシュするコンピュータでは、modprobe netconsole netconsole=@/eth0,1234@some-ip/netcatウィンドウにいくつかのコンソールメッセージがすぐに表示されます。

[508073.196581] console [netcon0] enabled
[508073.197026] netconsole: network logging started

もちろん、タイムスタンプははるかに低いでしょう。

Question 3

出力結果によると、last -x17〜18分ごとに再起動されるようですが、最初に再起動するように設定されたスクリプトまたはクローンがあるかどうかを確認する必要がありますか？そうでない場合は、以下をお読みください。

ハードウェア関連のエラーを確認したり、サーバー上で一般的に実行されている特定のアプリケーションまたは（Debianベースの）ログからソフトウェア関連のログを見つけるdmesg | tailことができます。tail -f /var/log/messagestail -f /var/log/syslog

ソフトウェアの問題かハードウェアの問題かをすばやく確認したい場合は、確認してくださいtop。

hi  --  Hardware IRQ
          The amount of time the CPU has been servicing hardware interrupts.

si  --  Software Interrupts
          The amount of time the CPU has been servicing software interrupts.

ここに画像の説明を入力してください。

また、上部の％wa値を確認する必要があります。ハードドライブに問題が発生した場合に備えて、この値が増加します。したがって、使用しているツールやhdparam -T /dev/sdxその他のツールを確認できます。しかし、まだ最終段階ではないので、確認できる方法はいくつかあります。

Answer

出力結果によると、last -x17〜18分ごとに再起動されるようですが、最初に再起動するように設定されたスクリプトまたはクローンがあるかどうかを確認する必要がありますか？そうでない場合は、以下をお読みください。

ハードウェア関連のエラーを確認したり、サーバー上で一般的に実行されている特定のアプリケーションまたは（Debianベースの）ログからソフトウェア関連のログを見つけるdmesg | tailことができます。tail -f /var/log/messagestail -f /var/log/syslog

ソフトウェアの問題かハードウェアの問題かをすばやく確認したい場合は、確認してくださいtop。

hi  --  Hardware IRQ
          The amount of time the CPU has been servicing hardware interrupts.

si  --  Software Interrupts
          The amount of time the CPU has been servicing software interrupts.

ここに画像の説明を入力してください。

また、上部の％wa値を確認する必要があります。ハードドライブに問題が発生した場合に備えて、この値が増加します。したがって、使用しているツールやhdparam -T /dev/sdxその他のツールを確認できます。しかし、まだ最終段階ではないので、確認できる方法はいくつかあります。

Question 4

CPU温度を確認する必要があります。次のコマンドを使用してシステムログを確認できます。 - grep 'temperature' /var/log/syslog 上記のコマンド出力が空の場合は、パッケージをインストールしてlm-sensors実行する必要があり、sudo sensors-detectすべてのはい/いいえ質問に「はい」を選択します。センサーの検出が完了すると、ロードする必要があるモジュールのリストが表示されます。センサーが/ etc / modulesに挿入されているこれらのモジュールを検出できるようにするには、「yes」と入力するか、/ etc / modulesを直接編集します。次に、sudo service module-init-tools restartこれを実行すると、手順3で/ etc / modulesへの変更を読み取り、新しいモジュールをカーネルに挿入します。次に、lmセンサーが正しく機能していることをテストする必要があります。sensorsコマンドを実行し、可能な後の出力を確認してください。毎回17:00～18:00に再起動するため、システム起動時間の15分後にこのコマンドを実行する必要があるようです。

Answer

CPU温度を確認する必要があります。次のコマンドを使用してシステムログを確認できます。 - grep 'temperature' /var/log/syslog 上記のコマンド出力が空の場合は、パッケージをインストールしてlm-sensors実行する必要があり、sudo sensors-detectすべてのはい/いいえ質問に「はい」を選択します。センサーの検出が完了すると、ロードする必要があるモジュールのリストが表示されます。センサーが/ etc / modulesに挿入されているこれらのモジュールを検出できるようにするには、「yes」と入力するか、/ etc / modulesを直接編集します。次に、sudo service module-init-tools restartこれを実行すると、手順3で/ etc / modulesへの変更を読み取り、新しいモジュールをカーネルに挿入します。次に、lmセンサーが正しく機能していることをテストする必要があります。sensorsコマンドを実行し、可能な後の出力を確認してください。毎回17:00～18:00に再起動するため、システム起動時間の15分後にこのコマンドを実行する必要があるようです。

再起動がソフトウェアによって発生したのか、ハードウェアによって発生したのかをデバッグする方法は？

答え1

答え2

ソフトウェア競合のデバッグ（そうでない可能性があります）

答え3

答え4

関連情報