明白生產環境中的jvm參數


明白生產環境中的jvm參數

寫代碼的時候,程序寫完了,發到線上去運行,跑一段時間后,程序變慢了,cpu負載高了……一堆問題出來了,所以了解一下生產環境的機器上的jvm配置是有必要的。比如說:

  • JDK版本是多少?采用何種垃圾回收器?
  • 程序啟動的時候默認分配堆內存空間是多少?隨着程序的運行,程序最多能使用多大的內存空間?
  • 程序中使用了多少個線程?這些線程又處於何種狀態?

了解了這些,會對程序的運行有一個更好的了解。本文結合生產實踐,記錄一下我常用的一些操作。

注意:如果沒有特殊說明,下面所有的參數討論都是基於JDK8 server class machine 而言的

根據官方調優文檔,server類型的機器滿足以下要求:

A class of machine referred to as a server-class machine has been defined as a machine with the following:

    • 2 or more physical processors
    • 2 or more GB of physical memory

我的理解:就是這台機器 有兩個以上的物理處理器,並且 具有2G或2G以上的內存,那么就是 server 類型的機器

可通過這個命令查看機器的物理處理器核數:

cat /proc/cpuinfo | grep "physical id" | sort | uniq | wc -l

可通過這個命令查看機器的總內存大小:

cat /proc/meminfo | grep MemTotal

當寫完一個Spring boot Maven 工程,使用 mvn clean package 打包成可運行的jar文件后,可使用如下命令開始執行:

nohup java -Xloggc:${logging_file_location}gc.log -XX:+PrintGCDetails -jar app.jar --spring.profiles.active=${environment} --logging.file.location=${logging_file_location} --domain=com.xx.xxx.xxxx > /dev/null 2>&1 &
  • -Xloggc: 指定程序運行過程中產生的 GC 日志輸出到 gc.log 文件中。
  • -XX:+PrintGCDetails 指定 輸出詳細的GC日志。
  • spring.profiles.active=${environment} 可根據 environment變量來選擇是生產環境還是測試環境。有時生產環境中使用的數據源(比如 Mysql)與測試環境不一樣,這樣就很方便。
  • --logging.file.location指定程序輸出的日志
  • --domain 這個參數主要用來對程序進行標識。比如,使用 ps aux | grep com.xx.xxx.xxxx 就能方便地找到程序的進程號了。

查看GC收集器

JDK版本號一般很容易知道,java --version就行了。那如何知道運行你的程序的JAVA虛擬機采用何種垃圾回收器呢?

其實可以從gc日志里面看出 jvm 使用的何種垃圾收集器。我安裝的JDK8,server 類型的機器,新生代默認使用的是:parallel scavenge,而老年代默認使用:ParOldgen 垃圾收集器。而看JVM調優官方文檔:Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide JDK9 默認是G1收集器

一條新生代GC日志:

0.791: [GC (Allocation Failure) [PSYoungGen: 64000K->3229K(74240K)] 64000K->3237K(243712K), 0.0040270 secs] [Times: user=
0.04 sys=0.00, real=0.00 secs]

一條老年代GC日志:

152561.075: [Full GC (Ergonomics) [PSYoungGen: 9303K->0K(68096K)] [ParOldGen: 424954K->389313K(439296K)] 434258K->389313K
(507392K), [Metaspace: 42513K->42513K(1087488K)], 0.0598682 secs] [Times: user=0.39 sys=0.01, real=0.06 secs]

查看JVM堆使用

知道了垃圾回收器,再來看看默認情況下,程序運行時初始堆大小,隨着程序的運行,堆內存最終可達到多大?

如果在啟動程序時使用-Xmx 指定了最大堆容量,那堆內存最終可達到的值,就是 Xmx設置的值(當然,Xmx不可能設置得比機器的物理內存還要大,同時也不要設置得和機器內存很接近,畢竟還有留一些內存給機器上的其他程序用)

下面以一台實際的物理機器,來分析下,程序是如何使用堆內存的。這台物理機器的內存大小為:16225356KB(約為16GB),物理處理器核數為2。因此符合 sever class machine。對於 server class 機器,默認使用如下參數:

On server-class machines, the following are selected by default:

  • Throughput garbage collector
  • Initial heap size of 1/64 of physical memory up to 1 GB
  • Maximum heap size of 1/4 of physical memory up to 1 GB
  • Server runtime compiler
  • 使用以吞吐量優先的GC 回收器。

  • Initial heap size of 1/64 of physical memory up to 1 GB 這句話,解讀很多。我的理解是:JAVA程序啟動時,默認分配的堆大小為:機器物理內存的64分之一,在我的示例中,機器的物理內存是16225356KB,因為初始時分配的堆大小為247MB:

    16225356/64/1024
    247

    而使用java -XX:+PrintCommandLineFlags命令:(單位是B)

    -XX:InitialHeapSize=259605696 -XX:MaxHeapSize=4153691136

    可看出初始堆大小為259605696B,259605696/1024/1024=247MB。由此可知:JVM啟動時分配的初始堆大小為物理機器內存的64分之一。

    然后我再在一台內存為128GB的機器上:

    cat /proc/meminfo | grep MemTotal
    MemTotal: 131829708 kB

    131829708 / 1024 /1024 =125 (也即:128GB內存)

    java -XX:+PrintCommandLineFlags
    -XX:InitialHeapSize=2109275328 -XX:MaxHeapSize=32037767584 -XX:+PrintCommandLineFlags -XX:+UseCompressedOops -XX:+UseParallelGC

    可以看出:-XX:InitialHeapSize=2109275328,也即:2109275328/1024/1024=2GB,也就是說:在物理內存為128GB的機器上,JAVA堆的初始分配大小為2GB,是超過1GB的。

  • Maximum heap size of 1/4 of physical memory up to 1 GB,隨着程序的運行,JVM堆內存會越來越大,但是一個JAVA進程最大能使用多大的堆內存空間呢?答案是 四分之一的物理機器內存。

    更具體地,對於一台物理內存為16GB的機器,如果在JAVA程序啟動時 不用 Xms、Xmx 參數指定jvm堆大小,即:這個程序就是使用默認的 java堆大小配置,一開始JAVA堆大小為:16GB/64 ,約為:247MB;然后隨着程序的運行,JAVA堆分配的內存會動態增大,動態增大的上限是:物理機器內存的四分之一,即約為4GB。

    比如,我查看 程序啟動后 第一次 GC日志如下:

    0.791: [GC (Allocation Failure) [PSYoungGen: 64000K->3229K(74240K)] 64000K->3237K(243712K), 0.0040270 secs] [Times: user=0.04 sys=0.00, real=0.00 secs]

    GC前該內存區域(新生代)大小:62MB,GC后該區域的大小:3MB,該區域的總內存大小:72MB。
    而GC前JAVA堆使用量62MB,gc后JAVA堆使用量3.1MB. JAVA堆的總大小:238MB(與247MB很接近)

我來做個猜想:根據第一條gc日志,JAVA堆總大小是238MB,新生代與老年代的比例是1:2,即:-XX:NewRatio=2,1/3的堆是新生代,2/3的堆是老生代,這樣的話,新生代的堆大小是:238/3=79MB,剛好與發生GC的區域總內存72MB接近。
而新生代再進一步細分:分為 Eden區、兩個Survivor區,其中Eden區占新生代堆大小的8/10,兩個Survivor區占新生代堆大小的2/10。即:Eden區的大小為:79*0.8=63MB ,與前面提到的 62MB非常接近。也就是說:在Eden區空間不足以容納新創建的對象的時候,發生了一次 PSYoungGen 垃圾回收操作。而Survivor區的大小為79*0.1=8MB,回收完成后,將剩余的3.1MB對象 存儲 在其中一個Survivor區了。

當隨着程序運行一段時間后:再看一條GC日志:

95191.984: [GC (Allocation Failure) [PSYoungGen: 48668K->2932K(73216K)] 507352K->461823K(648192K), 0.0032727 secs] [Times: user=0.04 sys=0.00, real=0.01 secs] 

GC前該內存區域(新生代)大小:48668/1024=47MB,GC后該區域大小約為2MB,該區域的總內存大小:71MB。GC前JAVA堆內存的使用量 507352/1024=495MB,GC后JAVA堆的內存使用量461823/1024=450MB,JAVA堆內存總大小:648192/1024=633MB

可見,運行一段時間后,JAVA堆內存大小從:238MB,動態增加到了:633MB

進程的各種狀態

一般我們會用 ps aux | grep java來查看java進程,知道進程ID號(比如13988)后,可通過:

cat /proc/13998/status | grep Threads
Threads: 78

查看一個JAVA進程下一共啟動了多少個線程。

另外,ps aux 中其中有一列是顯示進程狀態的,那進程狀態有哪些呢?

man ps 找到的進程狀態的解釋:

PROCESS STATE CODES
Here are the different values that the s, stat and state output specifiers (header "STAT" or "S") will display to describe the state of a process:
D uninterruptible sleep (usually IO)
R running or runnable (on run queue)
S interruptible sleep (waiting for an event to complete)
T stopped, either by a job control signal or because it is being traced.
W paging (not valid since the 2.6.xx kernel)
X dead (should never be seen)
Z defunct ("zombie") process, terminated but not reaped by its parent.

   For BSD formats and when the stat keyword is used, additional characters may be displayed:
   <    high-priority (not nice to other users)
   N    low-priority (nice to other users)
   L    has pages locked into memory (for real-time and custom IO)
   s    is a session leader
   l    is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
   +    is in the foreground process group.

D 代表不可中斷的阻塞,比如說I/O操作。不管是顯示IO,還是隱式IO,訪問本地磁盤的IO操作時,一般會處於D狀態。

In practice, processes typically go into D state ("uninterruptible sleep") when they're blocked on access to a local disk, whether that's explicit I/O (read/write) or implicit (paging).

S代表可中斷的睡眠狀態,比如線程執行下面的代碼:sleep(500),就處於可中斷的睡眠狀態吧。

    try {
        Thread.sleep(500);
    } catch (InterruptedException e) {
        logger.info("thread interrupted:{}", e.getCause());
    }

關於S狀態的解釋:(waiting for an event to complete),比如說,線程A在爭搶鎖時,由於這把鎖已經被線程B拿到了,那么 線程A 就會進入 S 狀態吧,線程A等待着線程B釋放鎖這一事件。

談到線程的狀態,其實有個參數與線程狀態息息相關,那就是CPU負載。處於哪個狀態的線程,才會計入CPU的負載呢?

There are two contributions to the load factor: number of processes/threads on the ready-to-run queue and the number blocked on I/O. The processes blocked on I/O show up in the "D" state in ps and top and also contribute to this number.

Not all processes blocked on I/O are in D state - for a common example, processes blocked on I/O to a network socket or terminal will simply be in the S state, and not count towards load.

可以這樣理解:准備運行的線程( ready-to-run queue)和阻塞在I/O操作上的線程都是計入負載的。

但是阻塞在I/O操作上的線程有兩種狀態,一種是D狀態,另一種是S狀態。其中S狀態的線程是不計入負載的。

總結

  • 在我的生產環境中,默認安裝JDK8,在未人為指定任何JVM參數的情況下,新生代采用Parallel Scavenge收集器,它是一個以吞吐量為目標的GC,采用多線程基於復制算法對新生代進行垃圾回收。老年代采用Parallel Old垃圾收集器,采用多線程基於 Mark-sweep 算法進行回收。
  • 每一款垃圾收集器都會有一個相應的調優目標,以最短停頓時間為目標、以最大吞吐量為目標、以最小使用堆內存空間為目標。這些目標是有優先級的,優先級最大的目標是停頓時間,其次是吞吐量。對於並行垃圾收集器(Parallel Collectors),默認情況下,並沒有設置“最大停頓時間”這一目標,這也就意味着最短停頓時間目標默認是實現了的。因此,Parallel Collectors 達到設置的吞吐量要求,而這個吞吐量由參數 -XX:GCTimeRatio指定,默認值為99,也即:為了保證吞吐量,GC時間只能占到整個程序運行時間的1% (參考JVM官方調優指南)
  • 最短停頓時間目標是關於GC時間的,而最大吞吐量也是講GC時間,在我看來:最短停頓時間是在一次GC過程中設置了一個“硬指標”,即:每次GC時間不能超過 設置的停頓時間這個值;而最大吞吐量則是講:所有的總的GC時間加起來不要超過某個值,以此來保證吞吐量。二者關注點是有區別的。

參考資料:

關於CPU負載可參考這兩篇文章:cpu load過高問題排查Understanding Linux CPU Load - when should you be worried?

Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide JDK9

JVAVA 8 GC tuning
Hotspot JVM的常用選項
原文:https://www.cnblogs.com/hapjin/p/9688289.html


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com