Javaデバッグ-実際の戦闘

CPU使用率が高すぎる

その他のURL

オンラインサーバーのCPU使用率が高い場合に、場所の問題をトラブルシューティングする方法は?_u011277123のブログ-CSDNブログの
パフォーマンスの最適化と高いCPU使用率(1)_Tomcatのブログ-CSDNブログ
オンラインJavaプログラムCPU使用率が高すぎる問題のトラブルシューティング_Vioaoのブログ-CSDN博客

CPU使用率のトラブルシューティングにはどのようなシナリオが必要ですか?

  1. アクセスインターフェイスの応答速度は非常に遅いです。
  2. システムが応答せずにクラッシュする
  3. 圧力テスト中にCPU、メモリ、負荷、rt、qpsおよびその他のインジケータを確認します

トラブルシューティング方法

  1. CPUが最も高いプロセスを見つけます。
    一番上のコマンドは、プロセス番号(PID)を書き留めます。最高と仮定すると:1893
  2. プロセスを通じて対応するスレッドを見つけます。
    トップ-Hp1893。最高値が4519であると仮定し
    ます(Javaはシングルプロセスマルチスレッドであるため)
  3. スレッドを介してコードのおおよその位置情報を見つけます。
    printf%x4519。結果は次のとおりです
    。11a7jstack1893| grep 11a7

CPU使用率の急上昇を引き起こす可能性のある操作

  1. whileの無限ループにより、CPU使用率が急上昇します
  2. Young GCを頻繁に使用すると、CPU使用率が急上昇します
  3. 頻繁なGC。
    トラフィックが非常に多い場合は、GCが頻繁に発生するか、フルGCが発生する可能性があります。呼び出し量が多い場合、メモリ割り当てが非常に高速になるため、GCスレッドが継続的に実行され、CPUが急上昇します。
  4. シリアル化と逆シリアル化。後で例を示します。プログラムがxml解析を実行すると、呼び出しの量が増え、CPUがいっぱいになります。
  5. 正規表現。正規表現がCPUをいっぱいにする状況に遭遇しました。その理由は、Java正規表現で使用されるエンジン実装がNFAオートマトンであり、文字の照合中にバックトラックを実行するためである可能性があります。その理由を詳しく説明するために、「正規表現の隠れた落とし穴」という記事を書きました。
  6. スレッドコンテキストスイッチ。
    開始されたスレッドは多数あり、これらのスレッドのステータスは、ブロック(ロック待機、IO待機など)と実行の間で変化します。この状況は、ロックの競合が激しい場合に簡単に発生する可能性があります。

メモリ使用量が多すぎます

その他のURL

Javaアプリケーションの問題の場所シリーズ-
メモリ使用量が多すぎる-SegmentFaultは、Javaサービスのメモリ使用量が高すぎるかどうかをトラブルシューティングプロセスで判断します_ 1974年について話します-CSDN blog_javaサービスのメモリ使用量が高すぎます
Javaメモリ使用量が高すぎるか、cpu使用量が高すぎて_Detoxを解決できませんブログ-CSDNブログ

前書き

Javaプログラムで高いメモリ使用量やメモリリークを見つける問題は、CPUの問題と似ています。一般に、次の3つのステップに分けることができます。

  1. ポジショニングプロセス
  2. スレッドの検索
  3. ロケーションコード

1.ポジショニングプロセス

Mを押します(メモリ使用量の大きいものから小さいものへと並べ替えます)

//見つかったプロセスIDが14279であると想定します。

2.スレッドの配置

トップ-Hp14279;

Mを押します(メモリ使用量の大きいものから小さいものへと並べ替えます)

top - 18:33:07 up 25 days,  7:48,  1 user,  load average: 0.17, 0.27, 0.23
Threads:  54 total,   1 running,  53 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.5 us,  0.7 sy,  0.0 ni, 98.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  8168236 total,   231696 free,  3660496 used,  4276044 buff/cache
KiB Swap:   969964 total,   969964 free,        0 used.  4197860 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
14293 weiping   20   0 4508772  97036  18112 S  10    12 152:35.42 java
14279 weiping   20   0 4508772  97036  18112 S  5.0  1.2   0:00.00 java
14282 weiping   20   0 4508772  97036  18112 S  0.0  1.2   0:00.37 java

2つの点に注意してください:

  1. スレッド数
    1. ご覧のとおり、スレッド数は54(左上隅のスレッド項目)であり、これは正常です。
    2. 比較的大きい場合(たとえば、1000より大きい場合)、コードに問題があるかどうかを検討してください。
      1. コードに手動で複数のスレッドがあるためですか?例:OkHttpClientを使用する場合、接続プール(ConnectionPool)は毎回作成されます。1つの接続プールのみを作成する必要があります。
      2. 自分で作成したスレッドプールの最大数が多すぎませんか?
  2. 大量のメモリを占有しているスレッドのPID
    1. スレッド数が正常な場合は、メモリのスナップショット情報をダンプして表示する必要があります。

3.コードの場所を見つけます

オンライン環境の場合は、ダンプする前にトラフィックを遮断する必要があることに注意してください。そうしないと、大容量のメモリダンプによってサービスが直接ブロックされます。

現在のスナップショットをダンプします:jmap -dump:format = b、file = dump.hprof 14279

多数のインスタンスを持つビジネス関連のインスタンスを探してから、表示する対応するコードを見つけます。(ツールを使用してdump.hprofを表示します。例:MAT、hhat)

デッドロック

頻繁なフルGC

おすすめ

転載: blog.csdn.net/feiying0canglang/article/details/115105155