私はnode.jsアプリケーションを開発しています。 --- Debian Linuxカーネルがクラッシュし続けます。コンピュータが応答せず、「ping」にも応答しません。
現段階では、衝突の原因を分析または解決することを要求するわけではありません。具体的に言及する情報はありません。コンピュータは応答を停止し、メッセージ/var/log/messagesも表示しません。dmesg
だから私の質問は次のようになります競合に関する情報を収集するには、どのツールを使用できますか？
以下はいくつかの背景の詳細です。
私のnode.jsアプリケーションはネットワークスタックを使用しません。 2つのサブプロセスを作成し、child_process.spawnファイルの書き込み、ファイルの変更の監視、およびfs.watch変更されたファイルの読み取りを介してこれらのプロセスと通信します。残りは単なるデータ処理です。
私はこの問題を3台のコンピュータでテストしました。
- 最初（私の主要な開発コンピュータ）では、アプリケーションを数回起動した後、システムは安定して停止します。
- 他のコンピュータ（メイン開発コンピュータのPCやdigitalocean VPSに似ています）では、アプリは一般的にうまく動作しましたが、数百回実行した後に他のコンピュータがフリーズしました。
私の主な開発コンピュータはこの問題に対してより脆弱なようです。しかし、関係のない2台のコンピュータでも停止が発生するため、これが1台のPCに限られた純粋にハードウェアの問題だとは思えません。
アプリケーションを実行した直後にコンピュータがハングするので、アプリケーションが問題の原因であると確信しています。すべてが停止したため（pingへの応答を含む）、Linuxカーネルがクラッシュしたと思いました。
答え1
通常、Linuxカーネルパニックはシステムコンソールに表示されます。しかし、これが実際にカーネルパニックである場合に備えて、あなたの場合には何らかの理由で実際にカーネルパニックであることを確認したくても表示されません。これを行うには、カーネルパニック後に次のように自動的に再起動するようにシステムを設定できます。パニック時に再起動するようにLinuxカーネルを構成する。システムが最終的に再起動すると、これは実際にはカーネルパニックであるため、その調査パスに集中することができます（Stack Exchangeサイトには多数の関連する回答があります）。
しかし、あなたの説明によれば、これはカーネルの中断または「多すぎる」状況である可能性が高いと考えられます。ここから始めることができます。全体の停止原因をどのように調べますか？。
最後に、根本的な原因はアプリケーションである可能性が高いことがわかったので、これがシステムに負荷がかかりすぎてシステムが応答しなくなる原因であると仮定します。コードに長さ/無限ループがあることを確認し、その影響を制限しようとすることができます。特定の実行時間（一部のタイムアウト例外を使用）以降、または特定の回数の繰り返し以降の中断などが可能です。しばらくすると、システムが再応答すると、コードのどの領域に問題があるのか、システムにどのような影響があるのかをよりよく知ることができます。