不明覺厲司恳!線上部署Kafka和ES,為啥JVM堆內(nèi)存分配越大绍傲,性能反而越低扔傅?

來源: 石杉的架構(gòu)筆記

1、是否依賴Java系統(tǒng)自身內(nèi)存處理數(shù)據(jù)烫饼?

先說明一點猎塞,不管是我們自己開發(fā)的Java應(yīng)用系統(tǒng),還是一些中間件系統(tǒng)杠纵,在實現(xiàn)的時候都需要選擇是否基于自己Java進程的內(nèi)存來處理數(shù)據(jù)荠耽。

大家應(yīng)該都知道,Java比藻、Scala等編程語言底層依賴的都是JVM铝量,那么只要是使用JVM,就可以考慮在JVM進程的內(nèi)存中來放置大量的數(shù)據(jù)银亲。

還是給大家舉個例子慢叨,大家應(yīng)該還記得之前聊過消息中間件系統(tǒng)。

比如說系統(tǒng)A可以給系統(tǒng)B發(fā)送一條消息务蝠,那么中間需要依賴一個消息中間件拍谐,系統(tǒng)A要先把消息發(fā)送到消息中間件,然后系統(tǒng)B從這個消息中間件消費到這條消息馏段。

大家看下面的示意圖

image

大家應(yīng)該都知道轩拨,一條消息發(fā)送到消息中間件之后,有一種處理方式院喜,就是把這條數(shù)據(jù)先緩沖在自己的JVM內(nèi)存里亡蓉。

然后過一段時間之后,再從自己的內(nèi)存刷新到磁盤上去够坐,這樣可以持久化保存這條消息寸宵,如下圖。

image.gif

2元咙、依賴Java系統(tǒng)自身內(nèi)存的缺陷

如果用類似上述的方式梯影,依賴Java系統(tǒng)自身內(nèi)存處理數(shù)據(jù),比如說設(shè)計一個內(nèi)存緩沖區(qū)庶香,來緩沖住高并發(fā)寫入的大量消息甲棍,那么是有其缺陷的。

最大的缺陷赶掖,其實就是JVM的GC問題感猛,這個GC就是垃圾回收,這里簡單說一下他是怎么回事奢赂。

大家可以想一下陪白,如果一個Java進程里老是塞入很多的數(shù)據(jù),這些數(shù)據(jù)都是用來緩沖在內(nèi)存里的膳灶,但是過一會兒這些數(shù)據(jù)都會寫入磁盤咱士。

那么寫入磁盤之后,這些數(shù)據(jù)還需要繼續(xù)放在內(nèi)存里嗎轧钓?

明顯是不需要的了序厉,此時就會依托JVM垃圾回收機制,把內(nèi)存里那些不需要的數(shù)據(jù)給回收掉毕箍,釋放掉那些內(nèi)存空間騰出來弛房。

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

這個時候牺堰,他在垃圾回收的時候拄轻,有可能你的這個中間件系統(tǒng)就運行不了了。

比如你發(fā)送請求給他伟葫,他可能都沒法響應(yīng)給你恨搓,因為他的接收請求的工作線程都停了,現(xiàn)在人家后臺的垃圾回收線程正在回收垃圾對象筏养。

大家看下圖:

image

雖然說現(xiàn)在JVM的垃圾回收器一直在不斷的演進和發(fā)展斧抱,從CMS到G1,盡可能的在降低垃圾回收的時候的影響渐溶,減少工作線程的停頓辉浦。

但是你要是完全依賴JVM內(nèi)存來管理大量的數(shù)據(jù),那在垃圾回收的時候茎辐,或多或少總是有影響的宪郊。

所以特別是對于一些大數(shù)據(jù)系統(tǒng)掂恕,中間件系統(tǒng),這個JVM的GC(Garbage Collector弛槐,垃圾回收)問題懊亡,真是最頭疼的一個問題。

3乎串、優(yōu)化為依賴OS Cache而不是JVM

所以類似Kafka店枣、Elasticsearch等分布式中間件系統(tǒng),雖然也是基于JVM運行的叹誉,但是他們都選擇了依賴OS Cache來管理大量的數(shù)據(jù)鸯两。

也就是說,是操作系統(tǒng)管理的內(nèi)存緩沖长豁,而不是依賴JVM自身內(nèi)存來管理大量的數(shù)據(jù)钧唐。

具體來說,比如說Kafka吧匠襟,如果你寫一條數(shù)據(jù)到Kafka逾柿,他實際上會直接寫入磁盤文件。

但是磁盤文件在寫入之前其實會進入os cache宅此,也就是操作系統(tǒng)管理的內(nèi)存空間机错,然后過一段時間,操作系統(tǒng)自己會選擇把他的os cache的數(shù)據(jù)刷入磁盤父腕。

然后后續(xù)在消費數(shù)據(jù)的時候弱匪,其實也會優(yōu)先從os cache(內(nèi)存緩沖)里來讀取數(shù)據(jù)。

相當于寫數(shù)據(jù)和讀數(shù)據(jù)都是依托于os cache來進行的璧亮,完全依托操作系統(tǒng)級別的內(nèi)存區(qū)域來進行萧诫,讀寫性能都很高。

此外枝嘶,還有另外一個好處帘饶,就是不要依托自身JVM來緩沖大量的數(shù)據(jù),這樣可以避免復(fù)雜而且耗時的JVM垃圾回收操作群扶。

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

image

然后比如Elasticsearch竞阐,他作為一個現(xiàn)在最流行的分布式搜索系統(tǒng)缴饭,也是采用類類似的機制。

大量的依賴os cache來緩沖大量的數(shù)據(jù)骆莹,然后在進行搜索和查詢的時候颗搂,也可以優(yōu)先從os cache(內(nèi)存區(qū)域)中讀取數(shù)據(jù),這樣就可以保證非常高的讀寫性能幕垦。

4丢氢、經(jīng)驗之談

依賴os cache的系統(tǒng)JVM內(nèi)存越大越好傅联?

現(xiàn)在就可以進入主題了,就以上述說的kafka疚察、elasticsearch等系統(tǒng)纺且,線上生產(chǎn)環(huán)境部署時,是依賴os cache來緩沖大量數(shù)據(jù)的稍浆。

那么,給他們分配JVM堆內(nèi)存大小的時候是越大越好嗎猜嘱?

明顯不是衅枫,假如你有一臺機器,32GB的內(nèi)存朗伶,你如果在搞不清狀況的情況下弦撩,傻傻的認為還是給JVM分配越大內(nèi)存越好,比如給了16G的堆內(nèi)存空間給JVM论皆。

那么這樣分配下來益楼,os cache剩下的內(nèi)存,可能就不到10GB了点晴,因為本身其他的程序還要占用幾個GB的內(nèi)存感凤。

那如果是這樣的話,就會導(dǎo)致你在寫入磁盤的時候粒督,os cache能容納的數(shù)據(jù)量很有限陪竿。

比如說一共有20G的數(shù)據(jù)要寫入磁盤,現(xiàn)在就只有10GB的數(shù)據(jù)可以放在os cache里屠橄,然后另外10GB的數(shù)據(jù)就只能放在磁盤上族跛。

此時讀取數(shù)據(jù)時,起碼有一半的讀取請求锐墙,必須從磁盤上去讀礁哄,沒法從os cache里讀,如下圖所示:

image

那此時你有一半的請求都是從磁盤上在讀取數(shù)據(jù)溪北,必然會導(dǎo)致性能很差桐绒。

所以很多人在用Elasticsearch的時候就是這樣的一個問題,老是覺得ES讀取速度慢之拨,幾個億的數(shù)據(jù)寫入ES掏膏,讀取的時候要好幾秒。

那能不花費好幾秒嗎敦锌?你要是ES集群部署的時候馒疹,給JVM內(nèi)存過大,給os cache留了幾個GB的內(nèi)存乙墙,導(dǎo)致幾億條數(shù)據(jù)大部分都在磁盤上颖变,不在os cache里生均,最后讀取的時候大量讀磁盤,耗費個幾秒鐘是很正常的腥刹。

5马胧、正確的做法

針對場景合理給os cache更大內(nèi)存

所以說,針對類似Kafka衔峰、Elasticsearch這種生產(chǎn)系統(tǒng)部署的時候佩脊,應(yīng)該要給JVM比如6GB或者幾個GB的內(nèi)存就可以了。

因為他們可能不需要耗費過大的內(nèi)存空間垫卤,不依賴JVM內(nèi)存管理數(shù)據(jù)威彰,當然具體是設(shè)置多少,需要你精準的壓測和優(yōu)化穴肘。

但是對于這類系統(tǒng)歇盼,應(yīng)該給os cache留出來足夠的內(nèi)存空間

比如32GB內(nèi)存的機器,完全可以給os cache留出來20多G的內(nèi)存空間评抚,那么此時假設(shè)你這臺機器總共就寫入了20GB的數(shù)據(jù)豹缀,就可以全部駐留在os cache里了。

然后后續(xù)在查詢數(shù)據(jù)的時候慨代,不就可以全部從os cache里讀取數(shù)據(jù)了邢笙,完全依托內(nèi)存來走,那你的性能必然是毫秒級的侍匙,不可能出現(xiàn)幾秒鐘才完成一個查詢的情況鸣剪。

整個過程,如下圖所示:

image

所以說丈积,建議大家在線上生產(chǎn)系統(tǒng)引入任何技術(shù)的時候筐骇,都應(yīng)該先對這個技術(shù)的原理,甚至源碼進行深入的理解江滨,知道他具體的工作流程是什么铛纬,然后針對性的合理設(shè)計生產(chǎn)環(huán)境的部署方案,保證最佳的生產(chǎn)性能唬滑。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末告唆,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子晶密,更是在濱河造成了極大的恐慌擒悬,老刑警劉巖,帶你破解...
    沈念sama閱讀 222,464評論 6 517
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件稻艰,死亡現(xiàn)場離奇詭異懂牧,居然都是意外死亡,警方通過查閱死者的電腦和手機尊勿,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,033評論 3 399
  • 文/潘曉璐 我一進店門僧凤,熙熙樓的掌柜王于貴愁眉苦臉地迎上來畜侦,“玉大人,你說我怎么就攤上這事躯保⌒牛” “怎么了?”我有些...
    開封第一講書人閱讀 169,078評論 0 362
  • 文/不壞的土叔 我叫張陵途事,是天一觀的道長验懊。 經(jīng)常有香客問我,道長尸变,這世上最難降的妖魔是什么义图? 我笑而不...
    開封第一講書人閱讀 59,979評論 1 299
  • 正文 為了忘掉前任,我火速辦了婚禮振惰,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘垄懂。我一直安慰自己骑晶,他們只是感情好,可當我...
    茶點故事閱讀 69,001評論 6 398
  • 文/花漫 我一把揭開白布草慧。 她就那樣靜靜地躺著桶蛔,像睡著了一般。 火紅的嫁衣襯著肌膚如雪漫谷。 梳的紋絲不亂的頭發(fā)上仔雷,一...
    開封第一講書人閱讀 52,584評論 1 312
  • 那天,我揣著相機與錄音舔示,去河邊找鬼碟婆。 笑死,一個胖子當著我的面吹牛惕稻,可吹牛的內(nèi)容都是我干的竖共。 我是一名探鬼主播,決...
    沈念sama閱讀 41,085評論 3 422
  • 文/蒼蘭香墨 我猛地睜開眼俺祠,長吁一口氣:“原來是場噩夢啊……” “哼公给!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起蜘渣,我...
    開封第一講書人閱讀 40,023評論 0 277
  • 序言:老撾萬榮一對情侶失蹤淌铐,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后蔫缸,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體腿准,經(jīng)...
    沈念sama閱讀 46,555評論 1 319
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,626評論 3 342
  • 正文 我和宋清朗相戀三年拾碌,在試婚紗的時候發(fā)現(xiàn)自己被綠了释涛。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片加叁。...
    茶點故事閱讀 40,769評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖唇撬,靈堂內(nèi)的尸體忽然破棺而出它匕,到底是詐尸還是另有隱情,我是刑警寧澤窖认,帶...
    沈念sama閱讀 36,439評論 5 351
  • 正文 年R本政府宣布豫柬,位于F島的核電站,受9級特大地震影響扑浸,放射性物質(zhì)發(fā)生泄漏烧给。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 42,115評論 3 335
  • 文/蒙蒙 一喝噪、第九天 我趴在偏房一處隱蔽的房頂上張望础嫡。 院中可真熱鬧,春花似錦酝惧、人聲如沸榴鼎。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,601評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽巫财。三九已至,卻和暖如春哩陕,著一層夾襖步出監(jiān)牢的瞬間平项,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,702評論 1 274
  • 我被黑心中介騙來泰國打工悍及, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留闽瓢,地道東北人。 一個月前我還...
    沈念sama閱讀 49,191評論 3 378
  • 正文 我出身青樓心赶,卻偏偏與公主長得像鸳粉,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子园担,可洞房花燭夜當晚...
    茶點故事閱讀 45,781評論 2 361

推薦閱讀更多精彩內(nèi)容