この記事では主にTomcatプロセスを記録し、TCP接続が多すぎることによるCPU使用率の過剰のトラブルシューティング記録を示します。 問題の説明 Linux では、Tomcat Web サービスの CPU 使用率が非常に高く、トップには 200% を超える値が表示されます。リクエストに応答できませんでした。再起動を繰り返しても同じ現象が起こります。 トラブルシューティング 1. プロセス情報を取得する jvm プロセスは、jdk が提供する jps コマンドを通じて簡単に確認できます。 jps-pid 2. jstack情報を表示する jstack pid 待機ロック状態のlog4jスレッドブロックが多数あることが判明
関連情報を検索したところ、log4j 1.x バージョンにデッドロックの問題があることがわかりました。 問題が見つかったので、log4j の設定を調整し、エラー レベルのログのみをオンにして、Tomcat を再起動しました。このとき、スタック内のブロック スレッドは消えますが、プロセスの CPU 使用率は依然として高いままです。 3. さらなる調査 各スレッドの CPU 使用率を分析するには、Java プロセス内の各スレッドの CPU 使用率を計算する、偉大な神様が寄稿したスクリプトを導入する必要があります。 #!/bin/bash タイプセット top=${1:-10} タイプセット pid=${2:-$(pgrep -u $USER java)} タイプセット tmp_file=/tmp/java_${pid}_$$.trace $JAVA_HOME/bin/jstack $pid > $tmp_file ps H -eo ユーザー、pid、ppid、tid、時間、%cpu --sort=%cpu --no-headers\ | 末尾 -$top\ | awk -v "pid=$pid" '$2==pid{print $4"\t"$6}'\ | 行を読み取り中; する タイプセット nid=$(echo "$line"|awk '{printf("0x%x",$1)}') タイプセット cpu=$(echo "$line"|awk '{print $2}') awk -v "cpu=$cpu" '/nid='"$nid"'/,/^$/{print $0"\t"(isF++?"":"cpu="cpu"%");}' $tmp_file 終わり rm -f $tmp_file スクリプトの適用範囲 ps の %CPU 統計は /proc/stat から取得されるため、このデータはリアルタイムではなく、OS 更新の頻度 (通常は 1 秒) に依存します。このため、表示される統計情報は jstack の情報と一致しません。ただし、この情報は、少数のスレッドからの継続的な負荷によって発生する問題のトラブルシューティングに非常に役立ちます。なぜなら、これらの固定された少数のスレッドは CPU リソースを消費し続けるからです。時間差があったとしても、いずれにせよこれらのスレッドによって発生します。 このスクリプトに加えて、より簡単な方法は、プロセスIDを見つけて、次のコマンドを使用してプロセス内の各スレッドのリソース使用量を表示することです。 トップ -H -p pid ここから pid (スレッド ID) を取得し、16 進数に変換して、スタック情報内のオブジェクトのスレッド情報を見つけます。 上記の方法により、tomcat プロセスに対応するスレッドの累積 CPU 使用率は約 80% であることがわかります。これは、top によって示される 200% 以上よりもはるかに小さい値です。 これは、CPU を長時間占有するスレッドが存在せず、CPU を集中的に使用する短期的な計算が多数存在することを意味します。そこで、JVM メモリ不足と頻繁な GC が原因であると疑いました。 jstat -gc pid jvm のメモリ使用量は異常ではないものの、gc 回数が大幅に増加していることがわかりました。 メモリを確認した後、ネットワークプログラムなので、さらにネットワーク接続を確認します。 4. 問題の場所 tomcat の該当ポートの TCP 接続を照会すると、多数の EASTABLISH 接続とその他の状態の接続がいくつかあり、合計で 400 を超えることがわかります。 netstat -anp | grep ポート これらの接続のソースをさらに確認すると、Tomcat サービスのアプリケーション側に多数のバックグラウンド スレッドがあり、それがサービスを頻繁にポーリングしていたため、サービスの Tomcat 接続数がいっぱいになり、リクエストの受信を継続できなくなっていたことが判明しました。 Netstat ステータスの説明:
5. 根本原因分析 直接的なトリガー原因は、クライアント ポーリング、要求例外、および継続的なポーリングです。クライアント上の新しいバックグラウンド スレッドがポーリング チームに引き続き参加し、最終的にサーバーの Tomcat 接続がいっぱいになります。 Tomcat プロセスの CPU 使用率が高い問題の記録に関するこの記事はこれで終わりです。Tomcat プロセスの CPU 使用率が高い問題に関する関連コンテンツの詳細については、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。 以下もご興味があるかもしれません:
|
<<: JS におけるメモリと変数の保存についての詳細な説明
>>: Alibaba Cloud Server で MySQL デュアルマシン ホットスタンバイを手動で実装する 2 つの方法
導入Linux は、ファイル、ログ、電子メール、バックアップなどを自動的に生成できるシステムです。ハ...
目次1分でgithub+Jekyllブログにトラフィック機能を追加する1. ジェクルとは何か1. J...
感想:私はバックエンド開発者です。静的 (HTML) ページを取得すると、ページ構造と命名規則が極端...
目次FastDFSについて1. 画像を検索する2. イメージをインストールする3.1. 必要なディレ...
序文MySQL スロー クエリ ログは、日常業務でよく遭遇する機能です。MySQL スロー クエリ ...
ユニアプリアプレットはWeChatでも同様のドロップダウン問題を抱えることになる解決策は、app.v...
なぜ?最も簡単に言えば、ピクセルは均等ではないということです。携帯電話に表示される写真はとても繊細に...
Oracle、DB2、SQL Server などの他の大規模データベースと比較すると、MySQL に...
最近、プロジェクトで写真をアップロードする要件があるのですが、顧客がアップロードする写真のサイズがま...
目次1. LVS 負荷分散2. 負荷分散LVSの基本紹介3. LVSアーキテクチャ3.1 ロードバラ...
バグ図のように、削除文とパラメータをデータベースにコピーして実行し、2つのデータを削除しようとしたの...
目次数学オブジェクト共通プロパティ一般的な方法Math.random()文字列メソッド長さプロパティ...
導入圧縮トランスポート プロトコル、圧縮列ソリューション、圧縮テーブル ソリューションなど、MySQ...
この記事の主な内容は次のとおりです。 1. ブラウザのサポート2. 画像3. レスポンシブツール4....
ネイティブJavaScriptを使用してカウントダウンを簡単に実装します。参考までに、具体的な内容は...