譯者注：上個(gè)月寫(xiě)了一遍博文，介紹一種高效的Java緩存實(shí)現http://maoyidao.iteye.com/blog/1559420。其本質(zhì)是模仿Memcached的Slab，通過(guò)分配連續定長(cháng)的byte[]減少大規模使用Java Heap作為緩存時(shí)不可避免的GC問(wèn)題。雖然當時(shí)構思和實(shí)現這一思路時(shí)并沒(méi)有參照其他開(kāi)源產(chǎn)品，但這一思路在很多著(zhù)名的開(kāi)源產(chǎn)品上也有類(lèi)似的實(shí)現。隨著(zhù)內存使用成本越來(lái)越低，高并發(fā)海量數據應用開(kāi)發(fā)者逐漸傾向于這樣一種思路：“內存就是新的硬盤(pán)，硬盤(pán)就是新的磁帶”。即通過(guò)盡量多的使用內存，和盡量多的順序讀寫(xiě)磁盤(pán)實(shí)現高吞吐。因此大規模使用內存引起的Java GC問(wèn)題就成為了一個(gè)普遍問(wèn)題。翻譯這篇文章的初衷是：

（1）該系列文章以Hadoop為例介紹了GC停頓帶來(lái)的問(wèn)題，比較生動(dòng)。

（2）比較詳細的介紹了GC原理，特別是CMS錯誤產(chǎn)生的原因，并且有實(shí)驗例子。

（3）介紹了一系列GC參數及GC profile思路，比較有借鑒價(jià)值。

（4）HBase實(shí)現方式和我的實(shí)現思路類(lèi)似，可以作為對照。

原文地址：http://www.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-1/

作者：Todd Lipcon, software engineer for Cloudera. Todd在2012年Hadoop峰會(huì )上介紹了：Optimizing MapReduce Job Performance，對性能調優(yōu)有豐富經(jīng)驗。

在HBase中應用MemStore-Local Allocation Buffers解決Full GC問(wèn)題：第一部分

今天我想分享一些Cloudera Hadoop中的工程細節。在這篇文章中，我將解釋一個(gè)新的Apache HBase組件：MemStore-Local Allocation Buffer，它顯著(zhù)的降低了Java GC導致的線(xiàn)程暫停頻率。本篇文章將是這個(gè)三部分系列文章的第一部分。

背景

堆和堆內存！

廉價(jià)商用服務(wù)器上的內存數量在過(guò)去的幾年中不斷的增長(cháng)。當Apache的HBase的項目于2007年開(kāi)始時(shí)，運行Hadoop的典型配置有4到8GB內存。今天，大多數Hadoop客戶(hù)以至少24G內存運行Hadoop，使用48G甚至72G內存的客戶(hù)也變得越來(lái)越普遍，而內存使用成本則繼續回落。表面上，這對像HBase的數據庫這樣對延遲敏感的軟件來(lái)說(shuō)，這似乎是一個(gè)偉大的勝利，大量的內存可以容納更多的數據緩存，在刷新到磁盤(pán)前作為寫(xiě)入緩，避免昂貴的磁盤(pán)尋址和讀。然而在實(shí)踐中，HBase使用的內存不斷增長(cháng)，但JDK可用的垃圾收集算法仍然相同。這導致了HBase的許多用戶(hù)的一個(gè)主要問(wèn)題：隨著(zhù)Java使用堆大小繼續增長(cháng)，垃圾回收導致的“stop-the-world”時(shí)間變得越來(lái)越長(cháng)。這在實(shí)踐中意味著(zhù)什么？

在垃圾回收導致的“stop-the-world”期間，任何到HBase客戶(hù)端請求都不會(huì )被處理，造成用戶(hù)可見(jiàn)的延遲，甚至超時(shí)。如果因為暫停導致請求超過(guò)一分鐘響應，HBase本身也可能會(huì )停止 - 僅僅因為垃圾回收導致這樣的延遲顯得很不值。

HBase依賴(lài)Apache Zookeeper的管理群集成員和生命周期。如果服務(wù)器暫停的時(shí)間過(guò)長(cháng)，它將無(wú)法發(fā)送心跳ping消息到Zookeeper quorum（譯者注：Zookeeper的分布式算法），其余的服務(wù)器將假定該服務(wù)器已經(jīng)死亡。這將導致主服務(wù)器啟動(dòng)特定的恢復程序，替換被認為死亡的服務(wù)器。當這個(gè)服務(wù)器從暫停中恢復時(shí)，會(huì )發(fā)現所有它擁有的租約都被撤銷(xiāo)，進(jìn)而只好自殺。HBase的開(kāi)發(fā)團隊已經(jīng)親切地稱(chēng)這種情況為朱麗葉暫停，此情況下 - 主服務(wù)器（羅密歐）假定邊緣服務(wù)器（朱麗葉）死亡的（其實(shí)它真沒(méi)死，只是睡覺(jué)），因此需要一些激烈的行動(dòng)（恢復）。當邊緣服務(wù)器從GC暫停中醒過(guò)來(lái)，它發(fā)現了一個(gè)巨大的錯誤已經(jīng)鑄成，只好結束自己的生命。這是一個(gè)非?？膳碌墓收?！

（譯者注：由于Java GC導致的心跳包沒(méi)有及時(shí)響應問(wèn)題，在對延時(shí)要求敏感的場(chǎng)景非常普遍。曾經(jīng)有一個(gè)業(yè)務(wù)場(chǎng)景，集群中的服務(wù)器每500ms發(fā)送一次心跳包到mater服務(wù)器，而master服務(wù)器由于GC導致沒(méi)有及時(shí)響應心跳包，進(jìn)而認為服務(wù)器死亡，導致故障）

做過(guò)大負載HBase集群負載測試的人應該對上述問(wèn)題很熟悉，在典型的硬件環(huán)境上，每GB的堆可以導致Hadoop暫停8-10秒。則分配8G堆的Hadoop會(huì )因GC暫停一分鐘以上。

（譯者注：Hadoop這個(gè)回收時(shí)間比較恐怖，我在線(xiàn)上服務(wù)分配36G Heap，平均FullGC暫停時(shí)間是6-8秒，因此萬(wàn)惡不是“大堆”為首，而是“內存使用方式不當”為首。這也是后文中調優(yōu)的原因所在）

不管人們如何調整，事實(shí)證明這個(gè)問(wèn)題是完全不可避免的。由于這是一個(gè)共同的問(wèn)題，而且每況愈下。因此在今年年初，它成為一個(gè)Cloudera的優(yōu)先項目。在這篇文的其余部分，我將介紹我們開(kāi)發(fā)的方法，該解決方案在很大程度上消除了這個(gè)問(wèn)題。

Java的GC背景

為了徹底了解GC暫停的問(wèn)題，有必要了解有一些在Java GC的技術(shù)背景。這里只作出一些簡(jiǎn)單描述，所以我非常鼓勵你做進(jìn)一步的研究。如果你已經(jīng)在GC的專(zhuān)家，隨時(shí)跳過(guò)這一節。

Generational GC（譯者注：即分“代”回收算法）

Java的垃圾回收器通常工作在Generational GC模式，該模式基于一個(gè)假設：假設大多數對象英年早逝，還是堅持相當長(cháng)的時(shí)間？（譯者注：事實(shí)上兩種情況同時(shí)存在）例如，在RPC請求緩沖區中對象將只存活幾毫秒，而在HBase的MemStore數據的數據可能會(huì )存活許多分鐘。很顯然用兩種不同的垃圾收集算法處理兩種不同的生命周期的對象更好些。因此，JVM把對象分成兩代：年輕代(New)和老年代(Old)。分配對象時(shí)，JVM在年輕代里分配對象。如果一個(gè)對象經(jīng)過(guò)幾次GC在還存活在年輕代，垃圾回收程序就把這個(gè)對象搬遷到老年代，在這里我們假設數據是會(huì )存活很長(cháng)時(shí)間。

在大多數對延遲敏感的場(chǎng)景，比如HBase，我們建議使用JVM參數：-XX:+ UseParNewGC和-XX:+ UseConcMarkSweepGC。

Parallel New Collector

Parallel New Collector是“stop-the-world”復制收集。每當它運行時(shí)，它首先暫停所有的Java線(xiàn)程。然后，它追蹤的對象引用來(lái)確定些對象是活的（仍然有程序引用這些對象）。最后它移動(dòng)活動(dòng)對象到堆里的空閑空間，并更新到這些對象的指針指向新的地址。

重點(diǎn)是：

• 它stop-the-world，但不是很長(cháng)。因為年輕代通常是相當小的，它可以非常迅速地完成其工作。在生產(chǎn)環(huán)境中，我們通常建議不超過(guò)512MB，這導致即使在最壞的情況下，年輕代GC暫停的時(shí)間也不到幾百毫秒。

（譯者注：似乎很少見(jiàn)到有配置這么小得Yong區，一般是New：Old=1:8，比如：-Xms8g -Xmx8g -Xmn1g；不過(guò)作者的說(shuō)法也可以試一試。原則是，不管你把JVM Heap設置多大，Yong區都不要設置的過(guò)大）

• 它復制活動(dòng)對象到一個(gè)自由的堆區，同時(shí)在每次回收后壓縮（compating）自由空間。因此每次GC后，free space在年輕代都是一個(gè)連續的塊，這意味著(zhù)再次分配可以是非常有效的。

每次Parallel New collector復制一個(gè)對象，該對象的計數器遞增。當對象在年輕代多次復制后仍存活，決定了它屬于長(cháng)壽命的對象，將移動(dòng)到老年代。在對象被移入老年代之前，在年輕代內被拷貝的最大次數被稱(chēng)為tenuring threshold。

Concurrent-Mark-Sweep collector

每一次新的并行收集器運行時(shí)，它將移動(dòng)一些對象到老年代，老年代最終將被填滿(mǎn)。因此我們需要一個(gè)回收老年代的策略。Concurrent-Mark-Sweep collector（CMS）是負責清除老年代里的死對象。

CMS的收集工作包括一系列階段。某些階段stop-the-world，某些階段則和其他Java應用程序同時(shí)運行。主要階段是：

• 初始標志（停止世界）。在這個(gè)階段CMS對根對象打標記。根對象是線(xiàn)程直接引用的對象 - 例如，該線(xiàn)程使用的局部變量。這個(gè)階段是的暫停是短暫的，因為根對象數量很少。
• 并發(fā)標記（并行）?，F在CMS從根對象開(kāi)始標記被根對象引用的所有對象，直到它標記完系統中的所有活動(dòng)對象。
• 重標記（停止世界）。由于對象可能有引用改變，新的對象可能已經(jīng)在并發(fā)標記創(chuàng )建的，我們需要回去考慮那些在這個(gè)階段被創(chuàng )建的對象。這也是個(gè)短期的停頓，因為有一個(gè)特殊的數據結構，讓我們只需要檢查那些在上一個(gè)階段被修改的對象。
• 并發(fā)掃描（并行）?，F在，我們繼續梳理在堆中的所有對象。任何沒(méi)有被標記的對象將會(huì )被回收并視為空閑空間。在此期間分配的新對象也會(huì )被打標記，以免被回收。

這里要注意的重要事情是：

• stop-the-world的階段很短。而掃描整個(gè)堆和清除死對象這種長(cháng)期工作可以和Java線(xiàn)程并行發(fā)生。
• CMS不搬遷的活動(dòng)對象，所以自由空間可以分布在整個(gè)堆的不同區塊。我們將稍后回來(lái)?。ㄗg者注：這個(gè)是優(yōu)化的重點(diǎn)，稍后的系列文章會(huì )繼續介紹）

CMS的失效模式（CMS Failure）

正如我所描述的，CMS看起來(lái)真的很棒 - 只停留很短的時(shí)間，而繁重的工作都可以和Java線(xiàn)程同時(shí)進(jìn)行。那么當我們在重負載下運行分配了大Heap HBase時(shí)，GC是如何造成我們看到的多分鐘暫停的呢？事實(shí)證明，CMS有兩種故障模式。

并發(fā)模式失敗

第一種失敗的模式，是簡(jiǎn)單的并發(fā)模式失敗。最好的一個(gè)例子：假設有一個(gè)8GB堆，已經(jīng)使用了7GB。當CMS的收集開(kāi)始第一階段，它歡快的隆隆的做著(zhù)并發(fā)標記。與此同時(shí)，有更多的數據被分配到老年代。如果老年代增長(cháng)的速度太快，在CMS完成第一階段標記工作之前就填滿(mǎn)了全部老年代。這時(shí)候因為沒(méi)有自由空間，CMS就無(wú)法工作！CMS必須放棄并行工作，并回落到停止世界（stop-the-world）單線(xiàn)程復制收集算法。此算法開(kāi)始搬遷堆，檢查所有活動(dòng)對象，并釋放了所有死角。長(cháng)時(shí)間的停頓后，該程序可能會(huì )繼續。

但我們可以很容易的通過(guò)調整JVM參數避免并發(fā)模式失?。何覀冎恍枰膭頒MS提前開(kāi)始工作！設置-XX：CMSInitiatingOccupancyFraction = N，其中N是堆在開(kāi)始收集過(guò)程中的百分比。HBase仔細的計算了內存使用，以保持其只使用60％的堆空間，所以我們通常將此值設置為大約70。（譯者注：同時(shí)也可以考慮Old區的30%要比Young區大，這樣即使Young區在CMS之前全部搬遷到Old區也不會(huì )把Old區填滿(mǎn)）

碎片導致的CMS失敗

這種故障模式是多一點(diǎn)復雜?；叵胍幌?，CMS收集不搬遷對象，而是簡(jiǎn)單地跟蹤所有堆的自由空間，而且自有空間是分開(kāi)的。作為一個(gè)思想實(shí)驗，想象我撥出1億個(gè)對象，每個(gè)1KB，這正是1GB堆的總用量為1GB。然后，我釋放所有奇數對象，所以我有500MB的自有空間，然而自由空間都是1KB的塊。如果我需要分配一個(gè)2KB的對象，盡管我表面上有500MB免費空間，依然會(huì )無(wú)處可放。這就是所謂的內存碎片。因為CMS不搬遷對象，不管如何讓CMS提前啟動(dòng)，都不可以解決這個(gè)問(wèn)題！發(fā)生此問(wèn)題時(shí)，CM再次回落到復制收集器，該方法能夠壓縮所有的對象并釋放空間。

GC知識已經(jīng)足夠了！回到HBase來(lái)！

讓我們回來(lái)并使用我們關(guān)于Java GC的知識思考HBase：

通過(guò)設置的CMSInitiatingOccupancyFraction，一些用戶(hù)能夠避免GC的問(wèn)題。但對于其他的場(chǎng)景，GC會(huì )經(jīng)常發(fā)生，無(wú)論CMSInitiatingOccupancyFraction設置的多么低。我們則經(jīng)?？吹皆谶@些GC停頓時(shí)，堆還有幾個(gè)GB的自由空間！鑒于這些情況，我們推測，我們的問(wèn)題應該是由碎片引起的，而不是一些內存泄漏或不當調整。

一個(gè)實(shí)驗：測量碎片

我們將運行一個(gè)實(shí)驗證實(shí)這一假設。第一步是收集一些有關(guān)堆的碎片信息。在探查OpenJDK源代碼后，我發(fā)現鮮為人知的參數的-XX：PrintFLSStatistics = 1（譯者注：JDK1.6也支持該選項），結合其他詳細GC日志記錄選項時(shí)，會(huì )導致CMS之前和之后每打印有關(guān)其自由空間的統計信息。特別是，我們關(guān)心的指標是：

• free space - 老年代的空閑內存的總數
• NUM塊 - 非連續的內存空閑塊總數
• 最大塊大小 - 空閑塊的最大大小

我啟用了這個(gè)選項，啟動(dòng)了一個(gè)集群，然后運行了Yahoo Cloud Serving Benchmark（YCSB）的三個(gè)獨立的壓力測試：

只寫(xiě)：每行10列，每列100個(gè)字節，1億個(gè)row key。

只讀（有緩存替換）：隨機讀取1億不同的行鍵的數據，使數據不能完全存儲在適LRU緩存。

只讀（無(wú)緩存替換）：隨機讀取1萬(wàn)不同的行鍵的數據，使數據完全符合LRU緩存。

每個(gè)壓力測試將運行至少一個(gè)小時(shí)，這樣我們可以收集GC行為數據。這個(gè)實(shí)驗的目標是首先要驗證我們的假說(shuō)，暫停是由碎片引起的，第二，以確定造成這些問(wèn)題的主要原因是讀取路徑（包括LRU緩存）還是寫(xiě)路徑（包

括每個(gè)地區的MemStores ）。

將要繼續...

在本系列的下一篇文章將顯示HBase的這個(gè)實(shí)驗和挖掘內部結果，了解不同的工作負載如何影響內存布局。

同時(shí)，如果您想了解更多有關(guān)Java的垃圾收集器，我推薦以下幾個(gè)環(huán)節：

Jon “the collector” Masamitsu has a good post describing the various collectors in Java 6.

To learn more about CMS, you can read the original paper: A Generational Mostly-concurrent Garbage Collector [Printezis/Detlefs, ISMM2000]