アプリケーション一時停止アニメーションのトラブルシューティング プロセスと OutOfMemory 問題の場所と処理
関連キーワード: java8、jmap、jstack、jstat、netstat、less、grep、jvm
シーン
以前に発生した OOM 問題のトラブルシューティング プロセスを確認してください。ビジネスの詳細は今のところ示されていません。外観: アプリケーションがフリーズし、インターフェイスのリクエストが応答できなくなりました。主な問題は、ビジネス量が増加し、1 つのコア ビジネスに byte[] があり、ヒープ設定が比較的小さいことです。byte[] プロセスを処理して最適化し、ヒープ サイズを増やします。
トラブルシューティング プロセス:
1.jmap はヒープ使用量を出力します。
2.jstat は GC 情報を出力します。
3.jstack はスレッド スタックのスナップショットを出力します。
4.netstat はリスニング ポートの TCP 接続ステータスを確認します
。 5. ログに OutOfMemory エラーがあるかどうかを確認します。
jmap
jmap: Java メモリ マップは DUMP ファイル (ヒープ ダンプ スナップショット、バイナリ ファイル) を取得できます。また、Java ヒープの各領域の使用状況、統計情報など、指定した Java プロセスのメモリ関連情報も取得できます。ヒープ内のオブジェクト、およびクラスロード情報
現在のヒープの各領域の使用状況を出力します。
現在の PID アプリケーションの JVM 構成と新世代と旧世代の使用状況を出力することで、アプリケーションのメモリ使用量を把握し、必要に応じて Java アプリケーションを最適化できます。
構文: jmap -heap pid
Attaching to process ID 29296, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.232-b09
using thread-local object allocation.
Parallel GC with 8 thread(s)
Heap Configuration:
MinHeapFreeRatio = x
MaxHeapFreeRatio = x
MaxHeapSize = x
NewSize = x
MaxNewSize = x
OldSize = x
NewRatio = x
SurvivorRatio = x
MetaspaceSize = x
CompressedClassSpaceSize = x
MaxMetaspaceSize = x
G1HeapRegionSize = x
Heap Usage:
PS Young Generation
Eden Space:
capacity = x
used = x
free = x
x% used
From Space:
capacity = x
used = x
free = x
x% used
To Space:
capacity = x
used = x
free = x
x% used
PS Old Generation
capacity = x
used = x
free = x
x% used
x interned Strings occupying x bytes.
ヒープ構成の各パラメータの意味:
MinHeapFreeRatio:堆可以被允许的最小空闲大小(以百分比表示)。
MaxHeapFreeRatio:堆中可以被允许的最大空闲空间大小(以百分比表示)。
MaxHeapSize:堆的最大尺寸。
NewSize:JVM 在创建新对象时将分配的内存区大小。
MaxNewSize:新生代的最大尺寸。
OldSize:老年代的初始大小。
NewRatio:新生代和老年代之间的比率。
SurvivorRatio:两个幸存者区域与 Eden 区域的大小比率。
MetaspaceSize:Metaspace 的初始大小(即非堆大小),用于存储加载类、方法等元数据。
CompressedClassSpaceSize:压缩类空间的大小。
MaxMetaspaceSize:Metaspace 的最大大小。
G1HeapRegionSize:G1 中的 Region 大小。每个 Region 的大小由 JVM 计算得出。
在 Heap Usage 部分,我们可以看到当前堆的使用情况,包括:
capacity:Java 堆的总容量。
used:Java 堆当前使用的总量。
free:Java 堆当前可用的数量。
42.22304174399364% used:Java 堆的当前使用率。
PS Young Generation: 年轻代
Eden Space: eden区
From Space: 幸存区1
To Space: 幸存区2
PS Old Generation: 老年代
生き残ってメモリを最も多く占有する 10 個のオブジェクトを降順に並べて出力します。
jmap -histo:live 29296 |head -n 10
このコマンドを使用して、異常なオブジェクトがメモリを過剰に占有し、メモリ リークを引き起こしていないかどうかを確認します。
ダンプバイナリファイルを出力する
構文: jmap -dump:format=b,file=heap.bin
上記のコマンドでヒープのダンプバイナリファイルを出力し、Eclipse の jconsole で Java プログラムのメモリを分析します。
JVM構成パラメータ
-Xmx4048m 最大堆大小
-Xms4048m 初始堆大小
-Xmn2600m 设置年轻代的大小 建议设置为堆的3/8
-XX:+UseParallelGC 使用并行垃圾收集器,在多 CPU 系统上可以提高垃圾收集的效率。
-XX:-UseAdaptiveSizePolicy 并行收集器会自动选择年轻代区分大小和相应的Survivor区比例
-XX:SurvivorRatio=x 幸存区大小比率。
-XX:+HeapDumpOnOutOfMemoryError 在 OutOfMemoryError 异常发生时生成堆转储文件(heap dump)。
JVM 設定パラメータは次のカテゴリに分類できます。
标准参数(- 开头):这些参数主要控制 JVM 的基本行为,并且在所有的 JVM 实现中都支持。
非标准参数(-X 开头):这些参数是实现特定的,不保证所有 JVM 实现都支持,且在未来的版本中可能会有所改变。
高级参数(-XX 开头):这些参数被称为高级参数,它们提供了对 JVM 内部行为的细粒度调整,并允许用户绕过某些标准限制。这些参数也是实现特定的,并且在不同的 JVM 实现中可能有所不同。
下面是一些常用的 JVM 参数及其说明:
-Xms:初始堆大小,指定 JVM 启动时堆内存的初始大小。默认情况下,Java 虚拟机自适应地调整堆大小。
-Xmx:最大堆大小,指定 JVM 最大堆内存大小。如果堆超出该阈值,则 Java 虚拟机将抛出 OutOfMemoryError 异常。
-XX:PermSize:永久代初始值,默认值为 64 MB。
-XX:MaxPermSize:永久代最大值,默认值为 64 MB。
-XX:NewSize:新生代初始值,指定了启动时新生代的初始大小。
-XX:MaxNewSize:新生代最大值,指定了新生代的最大可用空间。
-XX:SurvivorRatio:幸存区大小比率。
-XX:+UseConcMarkSweepGC:启用 CMS 垃圾收集器,用于收集老年代内存空间的垃圾。
-XX:+UseParNewGC:启用 ParNew 垃圾收集器,用于收集新生代内存空间的垃圾。
-XX:+UseSerialGC:使用串行垃圾收集器,适用于小型应用程序和单 CPU 系统。
-XX:+UseParallelGC:使用并行垃圾收集器,在多 CPU 系统上可以提高垃圾收集的效率。
-XX:+HeapDumpOnOutOfMemoryError:在 OutOfMemoryError 异常发生时生成堆转储文件(heap dump)。
这些参数只是 JVM 参数中的一小部分,有些参数可能因版本、厂商或系统而异,使用前需要仔细查看文档或手册。
立つ
jstat: Java 仮想マシン統計監視ツール
jstat -gccause pid
jstat -gccapacity pid
jstat -gc pid
オプション | 説明する |
---|---|
-クラス | クラスのロードステータスに関する情報を表示する |
-コンパイラ | JIT コンパイラ統計の表示 |
-gc | ガベージ コレクションのステータスに関する情報を表示する |
-gccapacity | 新世代、旧世代、永続世代のストレージ容量を表示するために使用されます。 |
-gccause | -gc に基づいて、最後の GC の原因を表示します |
-gcutil | 全体的なガベージ コレクション情報を表示する |
YGC: 从应用程序启动到采样的年轻代中GC的次数
FGC: 从应用程序启动到采样是old代GC的次数
FGCT: 从应用程序启动到采样是Old代GC所用的时间(s)
GCT: 从应用程序启动到采样时GC用的总时间(s)
GCC: 当前GC原因(No GC为当前没有执行GC)
LGCC: 最后一次GC原因
jスタック
jstack は現在の Java アプリケーションのスレッド スナップショットを生成します
出力スレッド スナップショット jstack pid > theadInfo.log
プロセスが応答しない場合、スレッドのスナップショットが強制的に出力され、デッドロックの有無が表示されます。 jstack -F pid > theadInfo.log が表示されます。
RUNNABLE: 线程运行中和IO等待
BLOCKED: 线程在等待Monitor锁
TIMED_WAITING: 线程在等待唤醒,设置了超时时间
WAITING: 线程在无限等待唤醒
IN_NATIVE: 反应的是线程正在运行系统“本机”代码而不是java代码
jstackが出力するログでは、
1. デッドロックが発生していないかに注目
2. 自身のコード内で大量のブロックが発生していないかを確認し、シングルスレッドを解析
ネット統計
netstat -anp |grep ':port'
サービスがリッスンするポート、確立された接続ステータスを確認し、異常な CLOSE_WAIT が発生していないかどうかを確認します。
TCP には、TCP 3 方向ハンドシェイク、情報送信、および TCP 4 方向ウェーブの各プロセスに対応する次の状態があります: listen、syn_sent、syn_revd、確立、fin_wait_1、close_wait、fin_wait_2、last_ack、time_wait、closed
CLOSE_WAIT: 接続を受動的に閉じることによって形成され、ネットワーク接続を占有します。
1. クライアントは close 関数を呼び出して 2 つのウェーブを開始します。サーバーがそれを受け入れると、CLOSE_WAIT 状態に入ります。クライアントがサーバーの ACK を受信した後、FIN_WAIT_2 状態に入ります。ただし、サーバーはまだ 2 つのウェーブを開始していません。接続が実際に切断されるのは、数回手を振った後でのみであり、その後、両者が対応する接続リソースを解放します。
2. サーバーが 2 つのウェーブを受信した後に close を呼び出さない場合、サーバーには CLOSE_WAIT 状態の多数の接続が存在し、各接続がサーバーのリソースを占有することになり、最終的にサーバー上で使用可能なリソースがますます少なくなります。サーバ。
TIME_WAIT: クライアントがアクティブに接続を閉じると、最後の ACK を送信した後、TIME_WAIT 状態になり、その後 2 つの最大メッセージ生存時間 (2MLS) が経過して CLOSE 状態になります。
参考
https://blog.csdn.net/sulijin/article/details/124412379
https://www.nowcoder.com/discuss/388301958082293760