前言

這篇文章，給大家聊一個生產環境的實踐經驗：線上系統部署的時候，JVM堆內存大小是越大越好嗎？

先說明白一個前提，本文主要討論的是Kafka和Elasticsearch兩種分布式系統的線上部署情況，不是普通的Java應用系統。

1、是否依賴Java系統自身內存處理數據？

先說明一點，不管是我們自己開發的Java應用系統，還是一些中間件系統，在實現的時候都需要選擇是否基于自己Java進程的內存來處理數據。

大家應該都知道，Java、Scala等編程語言底層依賴的都是JVM，那么只要是使用JVM，就可以考慮在JVM進程的內存中來放置大量的數據。

還是給大家舉個例子，大家應該還記得之前聊過消息中間件系統。

比如說系統A可以給系統B發送一條消息，那么中間需要依賴一個消息中間件，系統A要先把消息發送到消息中間件，然后系統B從這個消息中間件消費到這條消息。

大家看下面的示意圖。

大家應該都知道，一條消息發送到消息中間件之后，有一種處理方式，就是把這條數據先緩沖在自己的JVM內存里。

然后過一段時間之后，再從自己的內存刷新到磁盤上去，這樣可以持久化保存這條消息，如下圖。

2、依賴Java系統自身內存有什么缺陷

如果用類似上述的方式，依賴Java系統自身內存處理數據，比如說設計一個內存緩沖區，來緩沖住高并發寫入的大量消息，那么是有其缺陷的。

最大的缺陷，其實就是JVM的GC問題，這個GC就是垃圾回收，這里簡單說一下他是怎么回事。

大家可以想一下，如果一個Java進程里老是塞入很多的數據，這些數據都是用來緩沖在內存里的，但是過一會兒這些數據都會寫入磁盤。

那么寫入磁盤之后，這些數據還需要繼續放在內存里嗎？

明顯是不需要的了，此時就會依托JVM垃圾回收機制，把內存里那些不需要的數據給回收掉，釋放掉那些內存空間騰出來。

但是JVM垃圾回收的時候，有一種情況叫做stop the world，就是他會停止你的工作線程，就專門讓他進行垃圾回收。

這個時候，他在垃圾回收的時候，有可能你的這個中間件系統就運行不了了。

比如你發送請求給他，他可能都沒法響應給你，因為他的接收請求的工作線程都停了，現在人家后臺的垃圾回收線程正在回收垃圾對象。

大家看下圖。

雖然說現在JVM的垃圾回收器一直在不斷的演進和發展，從CMS到G1，盡可能的在降低垃圾回收的時候的影響，減少工作線程的停頓。

但是你要是完全依賴JVM內存來管理大量的數據，那在垃圾回收的時候，或多或少總是有影響的。

所以特別是對于一些大數據系統，中間件系統，這個JVM的GC（Garbage Collector，垃圾回收）問題，真是最頭疼的一個問題。

3、優化為依賴OS Cache而不是JVM

所以類似Kafka、Elasticsearch等分布式中間件系統，雖然也是基于JVM運行的，但是他們都選擇了依賴OS Cache來管理大量的數據。

也就是說，是操作系統管理的內存緩沖，而不是依賴JVM自身內存來管理大量的數據。

具體來說，比如說Kafka吧，如果你寫一條數據到Kafka，他實際上會直接寫入磁盤文件。

但是磁盤文件在寫入之前其實會進入os cache，也就是操作系統管理的內存空間，然后過一段時間，操作系統自己會選擇把他的os cache的數據刷入磁盤。

然后后續在消費數據的時候，其實也會優先從os cache（內存緩沖）里來讀取數據。

相當于寫數據和讀數據都是依托于os cache來進行的，完全依托操作系統級別的內存區域來進行，讀寫性能都很高。

此外，還有另外一個好處，就是不要依托自身JVM來緩沖大量的數據，這樣可以避免復雜而且耗時的JVM垃圾回收操作。

大家看下面的圖，其實就是一個典型的Kafka的運行流程。

然后比如Elasticsearch，他作為一個現在最流行的分布式搜索系統，也是采用類類似的機制。

大量的依賴os cache來緩沖大量的數據，然后在進行搜索和查詢的時候，也可以優先從os cache（內存區域）中讀取數據，這樣就可以保證非常高的讀寫性能。

4、老司機經驗之談

依賴os cache的系統JVM內存越大越好？

所以現在就可以進入我們的主題了，那么比如就以上述說的kafka、elasticsearch等系統而言，在線上生產環境部署的時候，你知道他們是大量依賴于os cache來緩沖大量數據的。

那么，給他們分配JVM堆內存大小的時候是越大越好嗎？

明顯不是的，假如說你有一臺機器，有32GB的內存，現在你如果在搞不清楚狀況的情況下，要是傻傻的認為還是給JVM分配越大內存越好，此時比如給了16G的堆內存空間給JVM，那么os cache剩下的內存，可能就不到10GB了，因為本身其他的程序還要占用幾個GB的內存。

那如果是這樣的話，就會導致你在寫入磁盤的時候，os cache能容納的數據量很有限。

比如說一共有20G的數據要寫入磁盤，現在就只有10GB的數據可以放在os cache里，然后另外10GB的數據就只能放在磁盤上。

此時在讀取數據的時候，那么起碼有一半的讀取請求，必須從磁盤上去讀了，沒法從os cache里讀，誰讓你os cache里就只能放的下10G的一半大小的數據啊，另外一半都在磁盤里，這也是沒辦法的，如下圖。

那此時你有一半的請求都是從磁盤上在讀取數據，必然會導致性能很差。

所以很多人在用Elasticsearch的時候就是這樣的一個問題，老是覺得ES讀取速度慢，幾個億的數據寫入ES，讀取的時候要好幾秒。

那能不花費好幾秒嗎？你要是ES集群部署的時候，給JVM內存過大，給os cache留了幾個GB的內存，導致幾億條數據大部分都在磁盤上，不在os cache里，最后讀取的時候大量讀磁盤，耗費個幾秒鐘是很正常的。

5、正確的做法

針對場景合理給os cache更大內存。

所以說，針對類似Kafka、Elasticsearch這種生產系統部署的時候，應該要給JVM比如6GB或者幾個GB的內存就可以了。

因為他們可能不需要耗費過大的內存空間，不依賴JVM內存管理數據，當然具體是設置多少，需要你精準的壓測和優化。

但是對于這類系統，應該給os cache留出來足夠的內存空間，比如32GB內存的機器，完全可以給os cache留出來20多G的內存空間，那么此時假設你這臺機器總共就寫入了20GB的數據，就可以全部駐留在os cache里了。

然后后續在查詢數據的時候，不就可以全部從os cache里讀取數據了，完全依托內存來走，那你的性能必然是毫秒級的，不可能出現幾秒鐘才完成一個查詢的情況。

整個過程，如下圖所示：

所以說，建議大家在線上生產系統引入任何技術的時候，都應該先對這個技術的原理，甚至源碼進行深入的理解，知道他具體的工作流程是什么，然后針對性的合理設計生產環境的部署方案，保證最佳的生產性能。