JVMのチューニング
- 制御時間に対するGCおよびGCの数にJVM主に割り当てられたメモリサイズの設定、選択、およびガベージコレクタ構成パラメータ調整、応答時間とアプリケーションのスループットを向上させる目的。
JVMの監視
-
JVM監視ツールは、以下のとおりです。JPS、jstatは、Jinfoの、jmapは、jhat、jconsoleを、virtualVM、Linuxはbinディレクトリに移動し、./を実行する必要があるかもしれません。
-
JPS、プロモーターの解析のためのJinfoのパラメータ、jstatは、リアルタイムの状況のためjmapの分析、jconsoleを、視覚的な分析にvirtualVM。
JPS
- JPS -l -vすべてのJVMプロセスを表示するために、「PIDジャーパッケージJVMパラメータ」やその他の情報が表示されます、簡単にアプリケーションの起動を表示するために使用することができ、これは、アプリケーションの起動スクリプトを有効にするかどうかを確認することは非常に簡単にすることができます。
JSTAT
- JSTAT級PID PIDプロセスは、現在のクラスの負荷ケースを表示するために使用されます。
加载11975个类，占据21KB
Loaded Bytes Unloaded Bytes Time
11975 21647.2 0 0.0 8.99
- JSTAT -gcutil PID JVMメモリ使用率（パーセント）を表示します。
S0使用0%，S1使用34%，E使用32%，O使用31%，M使用95%，YGC 19次，总共0.21s，FGC3次，总共0.5s，gc总共0.75s
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
0.00 34.04 32.72 31.37 95.65 93.51 19 0.210 3 0.548 0.758
-
JSTAT -gc pidのJVMビューのメモリ使用量、実際の特定の値に使用。
-
します。https：//www.cnblogs.com/yjd_hycf_space/p/7755633.htmlを特に参照してさらに多くのパラメータ、
Jinfoの
- HTTPS：//www.jianshu.com/p/8d8aef212b25 JinfoのPIDは、実際の開始JVMパラメータを表示するために使用される、を特に参照して、力に起動スクリプトかどうかを検証するために使用することができます
jmapの
-
jmapの-heap PID、ヒープ使用状況を表示します。
-
jmapの-histo 29620> log.txtという、log.txtというにオブジェクトインスタンスをエクスポートするデータの数とサイズにPID 29620アプリケーション、ヒープメモリを参照してください。
-
jmapの-dump：フォーマット= B、ファイル= heapdump.hprof 19287、エクスポート・ダンプ・ファイルが現在のヒープメモリミラーリングで、ダンプファイルがvirtualvm、マットと、コマンドは注意してアプリケーション、本番環境を一時停止します分析するための他のツールを使用することができます。
VirtualVMとMAT
-
virtualVmダンプファイルを解析し、またはリアルタイムメモリは、リモートJMXアプリケーションを介して接続されている使用して分析することができます。
-
マット、だけでなく、ヒープ解析ツールダンプファイルは、インスタンスのサイズ、占有スペース（深いスタック、浅いヒープ）の数を表示することができます。
JSTACK
- jstack Thread.getAllStackTracesに相当する（-F）PIDこのプロセスを印刷するすべてのスレッドのスタック情報は、（）、デッドロックを検出して糸の消費量が高すぎるCPUを検出するために使用されます。
Jःで
- jhatまた、ダンプファイルを分析するHTMLページの解析を生成するために使用すること
JVM監視デモ
- 現在のLinuxマシン環境を見ます
top -c
Cpu(s): 6.9%us, 1.5%sy, 0.0%ni, 91.5%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 8062128k total, 7820904k used, 241224k free, 151844k buffers
// 通过top命令来查看机器的cpu和内存使用率，91.5id，表示CPU未使用率。内存241M的空闲，另外可以查看到进程的cpu和内存使用情况
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_root-lv_root 78G 74G 16M 100% /
tmpfs 3.9G 0 3.9G 0% /dev/shm
/dev/sda1 477M 40M 413M 9% /boot
/dev/mapper/vg_root-lv_home 13G 203M 12G 2% /home
- 現在のアプリケーションのメモリ割り当ての設定を見ます
jps -l -v
15143 cu-ibas-pay-provider.jar -Dlog4j.path=/app/applogs/ibasPre
ps -ef|grep cu-ibas-pay-provider.jar
qzd 15143 1 0 Jan20 ? 00:25:07 java -jar -Dlog4j.path=/app/applogs/ibasPre cu-ibas-pay-provider.jar -Xms768m -Xmx768m -Xss256K -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
// 通过jps发现启动只有一个参数设置，进一步通过ps发现，启动命令有问题，cu-ibas-pay-provider.jar 之后全部不生效，通过修改发现生效
jinfo 15143
Non-default VM flags: -XX:CICompilerCount=3 -XX:InitialHeapSize=130023424 -XX:MaxHeapSize=2065694720 -XX:MaxNewSize=688390144 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=42991616 -XX:OldSize=87031808 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseParallelGC
Command line: -Dlog4j.path=/app/applogs/ibasPre
// 通过jps，发现内存设置是初始堆124M，最大堆1.9G，新生代最大656M，初始新生代41M，老年代83M，使用的ParallelGC
jstat -class 15143
Loaded Bytes Unloaded Bytes Time
19617 36120.2 0 0.0 162.67
// 通过jstat，发现162ms，载入19617个类，共36M
- メモリのリアルタイム監視アプリケーション、GC状況
jstat -gc 15143
S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
11264.0 16384.0 10857.0 0.0 411648.0 133948.3 185856.0 75930.1 112920.0 108128.9 14104.0 13258.3 38 27.725 4 1.045 28.770
// 通过jstat，发现当前 S0分配11M，使用10M，S1分配16M，使用0，Eden分配411M，使用133M，Old分配185M，使用75M，Metaspace分配112M，使用108M，minorGC 38次，fullGC4次，
jmap -heap 15143
// 比jstat更直观，但没有gc信息
- メモリ監視アクチュエータspringbootアプリケーション
- ヒープダンプファイルの解析
jmap -dump:format=b,file=[filename][pid]，gceasy（在线https://gceasy.io/），GCViewer
GCログ解析
- GCログが指定したGCログ生成ディレクトリとして、GCログ生成フォーマットを指定し、アプリケーションの起動パラメータを指定する必要があり、現在のダンプ・ファイルが生成されたときに指定されたヒープオーバーフロー
// 设置在应用日志中输出gc详细信息
-verbose:gc
// 设置日志中打印GC详情，和-verbose:gc类似
-XX:+PrintGCDetails
// 设置日志中打印GC时间戳
-XX:+PrintGCTimeStamps
// 设置单独生成gc日志文件
-Xloggc:[file]
// 设置堆溢出时导出dump
--XX:+HeapDumpOnOutOfMemoryError
// 设置堆dump溢出文件路径
-XX:HeapDumpPath=/applogs/pre-yg-web_heapdump
// 设置jvm崩溃时的日志文件路径
-XX:ErrorFile=[file]
- フォーカスGCログ：休止時間やスループットなど、占め：
// 新生代无法分配内存空间，触发Minorgc，新生代从31744K回收到2647K，新生代总空间36844K，整个堆从31744K回收到2655K，堆的总大小121856K，耗
// 时；
0.448: [GC (Allocation Failure) [PSYoungGen: 31744K->2647K(36864K)] 31744K->2655K(121856K), 0.0086293 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
1.938: [GC (Metadata GC Threshold) [PSYoungGen: 210895K->3950K(259072K)] 214127K->8630K(344064K), 0.0073356 secs] [Times: user=0.02 sys=0.01, real=0.01 secs]
// Metadata元数据区达到阈值，触发FullGC，新生代从3959K回收到0K，总大小259072K，老年代从4679K会受到8046K，堆总大小从8630K回收到8046K，堆
// 总大小314880K，元数据区从20699K会受到20699K，元数据区总大小1067008K。
1.946: [Full GC (Metadata GC Threshold) [PSYoungGen: 3950K->0K(259072K)] [ParOldGen: 4679K->8046K(55808K)] 8630K->8046K(314880K), [Metaspace: 20699K->20699K(1067008K)], 0.0481115 secs] [Times: user=0.14 sys=0.00, real=0.05 secs]
よくある質問
-
JVMのメモリリークの一般的な原因：
大規模な静的オブジェクトのみFullGCクリーンアップ、およびクラスが占有していたメモリを引き起こし、まだ使用中であるときに復元されることはありませんでしょう静的オブジェクト;
、+演算子の頻繁な文字列を頻繁に新しいを作成しますStringオブジェクトは、あなたが場所でのStringBuilderやStringBufferのを使用することができますが、JDKの新しいバージョンが最適化された、
オブジェクト・サイクルを作成し、再帰の深さのレベルもメモリリーク原因、オブジェクト・多重化、オブジェクトプーリング、制御対象ループの外で作成しようとすることができますスコープは、あまりにも多くの方法を持っていません。 -
Javaアプリケーションの起動スクリプト
java -jar -Dlog4j.path=/applogs pre-web.jar & -Xloggc:/applogs/pre-web_gc.log
// 上面这样写是绝对错误的，会导致后面的设置不生效，需要改为
java -jar -Dlog4j.path=/applogs -Xloggc:/applogs/pre-web_gc.log pre-web.jar &
// 可以通过jps -l -v，jinfo pid来验证
- CPUスレッドの高い割合を特定します
// 找到cpu占比高的进程的pid
top -c
// 得到进程中的线程tid
ps -mp <pid> -o THREAD,tid,time | sort -k2r
// 将tid转16进制，并得到线程的堆栈信息
jstack -l <pid> | grep <thread-hex-id> -A 10
- デッドロックの検出
jstack -F pid来检测
- FullGCの数を減らすために、最も重要なことは、リサイクルされる代わりに、古い時代に移動するタイムリーなオブジェクトを確保するために、スコープや他の老後の手段を用いて、安定性を確保することです。（理由は、古いS内にセキュリティ・メカニズムの）大きなオブジェクトを使用して回避するために同じ時間の試みで、適切なデータ構造を使用：long型：8バイトをしながらロングタイプ：24byte。
