docker生產環境jvm性能優化

一、xmx與xms設置多大合適

docker得到的mem_usage的大小是從外部獲得的java進程的內存大小，不單單是 -Xmx設置的大小，若是 -Xmx和docker分配的內存一致的話，因爲java應用其餘的地方還要佔用很多的內存，致使尚未到達 -Xmx的時候就沒有能夠用的內存了，因此被docker容器給幹掉了，從而出現了oom的狀況。

那麼java程序啓動的時候須要哪些方面的內存呢？

• java程序的堆內存，最大就是 -Xmx設置的這個值
• Garbage collection在垃圾回收的時候使用的內存
• JIT optimization使用的內存
• java程序的Off-heap所使用的內存
• java程序的Metaspace所使用的內存
• JNI Code所佔用的內存
• jvm啓動的時候所佔用的內存。

如何大致估算java進程使用的內存呢?

Max memory = [-Xmx] + [-XX:MaxPermSize] + number_of_threads * [-Xss]

猜想在設置jvm啓動參數的時候 -Xmx的這個值通常要小於docker限制內存數，通過生產環境實驗 -Xmx:docker的比例爲 2/3 - 3/4，

通常生產環境都是用的sunjdk，因此建議xmx與xms設置同樣大

1. 避免JVM在運行過程當中向OS申請內存
2. 延後啓動後首次GC的發生時機
3. 減小啓動初期的GC次數
4. 避免動態調整jvm堆大小

二、xmn或者maxnewSize設置

xmn設置年輕代大小。若是隻是一些業務較簡單的基礎服務建議xmn設置爲xmx的一半。

三、當xmx設置大於4G時，設置垃圾回收器 -XX:+UseG1GC

當堆內存很大時若是仍是使用併發收集器，會形成gc收集比較長，這時能夠將並行收集改爲G1回收器

四、容器中最好增長-XX:ParallelGCThreads設置，該值能夠設置爲cpu核數

因爲ParallelGCThreads的值默認是等於cpu核數，可是有的生產環境獲取的是容器宿主機器的cpu核數，這就致使cpu核數太多，效率變差，gc時間會延長。