tcpip 経由でネットワーク データを受信するプロセス (c++ /managed で記述) があります。ネットワークの負荷を追跡しながらしばらくプロセスを実行した後、ネットワークがフリーズ状態になり、プロセスがデータを取得していないように見えます。システムには、正常に動作するネットワーク (同じ NIC) を使用する他のプロセスがあります。プロセスは、数分後にこの凍結状態から抜け出します。
何が起こっているのですか？プロセスが制限に達しているかどうかを確認するために追跡できるカウンターはありますか?
あなたのプロセス/アプリケーションが正確に何であるかを知らずに、具体的に答えるのは非常に難しいでしょう.
-- ネットワーク チャット アプリケーションか、ファイル サーバー/クライアントか、または ......
-- 問題に関連する場合、プロセスの実装方法、使用するライブラリに関するその他の詳細なし。
また、このプロセスを実行しているOSと環境についても言及していないため、誰も助けることができません. コード内のビジーな待機ループ、マルチスレッドコードの場合のロックの問題など、何でもかまいません....それでも、チェックするオプションがいくつかあります。
Linux の場合は、以下のコマンドを試して、プロセスの動作をデバッグおよび監視し、問題の可能性を確認してください。
top top をチェックして、プロセスが使用しているリソース (CPU、メモリ) の量を確認し、その CPU 使用率に異常に高い値がないかどうかを確認します。
pstack これは、問題の発生時に実行されているプロセスのフレームをスタックする必要があります。
netstat 必要なオプション (tcp/udp) を指定してこれを実行し、プロセスによって開かれたネットワーク ソケットの状態を確認します
gcore -s -c これにより、上記の問題が発生したときにプロセスが強制的にコアになり、gdb gdb を使用してそのコア ファイルを分析し、gdb プロンプトでコマンド where を使用して、プロセスの完全なバック トレースを取得します (最後に実行された機能と、以前の関数呼び出し。