理解怎樣管理實例內存是很重要的，這樣可以避免Java堆空間錯誤。當運行 map/reduce 作業（Job）時，你可能會看到實例出現這樣的錯誤：

13/09/20 08:50:56 INFO mapred.JobClient: Task Id : attempt_201309200652_0003_m_000000_0, Status : FAILED on node node1 
Error: Java heap space 

當試圖申請一個超過Java虛擬機（JVM）設置的最大內存限制時就會發生這個錯誤。

避免Java堆空間錯誤的第一步是了解你的map和reduce任務的內存需求，以便于你啟動一個JVM時設置了適當內存限制。

例如，hadoop-0.20.2-dev-examples.jar中的wordcount 功能。 不管處理什么數據，map 任務都不需要很多內存。唯一需要很多內存的就是在加載運行所需的函數庫的時候。當使用默認附帶MapR包的wordcount功能時，512MB的內存對于實例JVM是綽綽有余了。如果你打算運行我們提供的Hadoop示例，可以嘗試將map實例JVM的內存限制設為512MB。

如果你知道自己的map實例需要多少內存（在本例中是512MB）， 那么下一步啟動設置好JVM內存。該實例在JVM中的內存是由TaskTracker為Map/Reduce作業處理數據而設定的。 TaskTracker設定的限制可能有兩個來源：要么是用戶提交作業時指定了內存大小作為該作業配置對象的一部分，或者是TaskTracker產生了 默認內存大小的JVM。

mapred.map.child.java.opts屬性被用來為TaskTracker 啟動JVM和執行map任務的參數（在reduce任務中也有個類似的屬性）。如果mapred.map.child.java.opts屬性被設置成“-Xmx512m”，那么map實例JVMs會有512MB的內存限制。相反的，如果-Xmx沒有通過配置屬性去指定一個數值的話，那么 每個TaskTracker將會為啟動JVM計算一個默認的內存限制。該限制是基于TaskTracker為map/reduce task slot分配的數量所決定的，并且TaskTracker分配給Map/Reduce總內存不能超過系統限制。

TaskTracker為map/reduce實例分配的slot數量在TaskTracker啟動時就設定好了。通過每個節點上mapred-site.xml文件中兩個參數進行控制的：

mapred.tasktracker.map.tasks.maximum 
mapred.tasktracker.reduce.tasks.maximum 

設置這些默認值的規則是基于節點上CPU核心的數量。不過你可以下面兩個方法來重載參數：

1. 修改mapred-site.xml文件設定一個固定的slots數值。
2. 使用自定義規則。

在系統中，TaskTracker  map/reduce實例內存限制是在TaskTracker進程啟動時設定的。有兩個地方可以設置內存限制。首先在Hadoop conf目錄下的hadoop-env.sh腳本中可以顯式的設置，你可以添加下面這行來指定內存限制：

export HADOOP_HEAPSIZE=2000 

這行命令限制了節點上的所有實例JVM總共可以使用2000MB的內存。如果沒有在hadoop-env.sh文件中指定 HADOOP_HEAPSIZE這個參數，那么當MapR warden service啟動TaskTracker時會對內存進行限制。 warden service會基于節點上物理內存的數量減去服務運行中已經占用的內存數量得出限制的大小。如果你去看看warden.conf你會看到像這樣的一些屬性：

service.command.mfs.heapsize.percent=20 
service.command.mfs.heapsize.min=512 

這個例子表示，warden占用分配給MFS服務節點的20%物理內存或最低512MB（512MB<20%的物理內存的情況下）。如果你考慮所有服務都配置在一個節點上運行的話，你要考慮下在 warden.conf中指定下內存分配。你應該能明確多少內存用于服務配置（還要為系統正常運行預留內存）。剩下的內存就是TaskTracker為并發運行實例設置的內存限制了。

例如，假設你在一個節點上安裝運行ZooKeeper、CLDB、MFS、JobTracker、TaskTracker、NFS、the GUI、HBase Master 和HBase RegionServer。這么多的服務運行在一個節點上，而且每個服務都需要內存，所以warden會將內存按照百分比分配給每個服務，剩下的將會分配 給節點上的map/reduce 實例。如果你分配給這些服務總共60%還有5%為系統預留，那么就還有35%分給節點上的map/reduce實例。如果這個節點有10G的內存，將會有3.5G分給 map/reduce 任務。如果你有 6個map slot和4個reduce slot。如果內存是平均分配的，最終每個JVM的內存限制為350MB。如果你需要512MB內存來運行你的map任務，那么默認設置的情況下是不會運行的，你會遇到Java堆空間錯誤。

當管理實例內存的時候會意識到還有其它問題。不要強制節點去使用大量的交換空間（swap space）或者觸發頻繁內存分頁讀寫磁盤。如果你通過顯式的在mapred.map.child.java.opts設置“-Xmx500m”來改變提交的作業，將會重寫安全的內存限制。但實際上你并沒有額外的物理內存。雖然 map/reduce 實例仍能啟動，但是會強制使用大量的交換空間，而且無法依賴內核的OOM killer或者其他的方法來防止這種情況發生。如果真的發生這種情況，無法指望節點啟動大量分頁來迅速恢復。如果只是增加了實例的JVM內存，同時繼續在節點上啟動相同數量的實例。你會申請更多的內存，需要注意不要超額申請。如果超額申請太多的話，會導致大量的分頁，這樣節點可能會被掛 起再也無法恢復。除非重啟電源。

所以如果你給每個實例JVM增加內存的話，需要通過TaskTrackers來減少分配給map/reduce task slot數量。

這是一個很復雜的情況，因為如果你在集群上并發執行不同的作業，可能來自一個作業（JobA）的實例需要大量的內存，來自另外一個作業（JobB）的實例只需要很少的內存。因此，如果你減少map/reduce slot的數量，會發現會有足夠的內存來運行來自JobB任務（task）。但是卻沒有足夠的內存提供給JobA。所以關鍵就是找到一個平衡點，一個可以允許進行一些超額申請卻不會導致節點被掛起的平衡點。

為了協助這個任務，TaskTracker 將會著眼于當前所有在運行的 map/reduce tasks 所使用的內存數量。不是只看這些任務的最大內存限制，而是所有運行中的實例實際利用的內存總數。當消耗的內存達到一定級別，TaskTracker 會殺死一些運行的實例來釋放內存，以便其他的實例能正常執行完并且不會造成節點上的分頁過多。

舉個例子，如果你想在一個小型的集群或者單一節點上運行wordcount示例，碰到“Java堆空間”錯誤，最簡單最快的解決方法就是通過編輯/opt/mapr/hadoop/hadoop-0.20.2/conf/mapred-site.xml中的設置來減少 map/reduce 實例 slot的數量：

mapred.tasktracker.map.tasks.maximum  
mapred.tasktracker.reduce.tasks.maximum 

將實例的slot的數量設置為小于當前計算結果是非常重要的。當前計算的數量可以通過進入JobTracker web界面來確定。例如，如果你有一個TaskTracker ，顯示它有6個mpa slot和4個 reduce slot，那么你應該設置 3個map slot、2個 reduce slot。然后通過下面這行命令重啟節點上的TaskTracker進程：

maprcli node services -nodes -tasktracker restart 

減少slot的數量重新啟動后，重新提交wordcount作業。如果沒有額外內存申請，每個實例、JVM都會分配到更多的內存。這是一個安全的解決方法，節點不會產生大量分頁。這是一種簡單的解決方案，不需要大量計算內存。這也是快速的方法，只需要編輯下配置文件并重啟下服務就好了。

為了避免Java堆空間錯誤，記住下面這些步驟：

1. 估算你的實例需要消耗多少內存。
2. 確保TaskTracker 啟動你的實例時，JVM內存的限制要大于等于你預計的內存需求。
3. 記住，啟動這些JVM是有默認設置的，除非你顯式的重寫過這些設置。在CPU核心數和物理內存已經平衡并運行服務的節點上，默認設置并不適用。
4. 不要迫使節點大量的使用交換空間或者頻繁的將內存分頁讀寫到磁盤上。
5. 將實例slot數量設置為小于JobTracker web GUI計算值。

原文鏈接： mapr 翻譯： ImportNew.com - 光光頭去打醬油
譯文鏈接： http://www.importnew.com/14049.html