Spark遇到的一個內(nèi)存錯誤

問題

項目中遇到的一個問題，其實不是spark的鍋，但錯誤是它爆出來的，排錯過程可以借鑒：
錯誤是這樣的：

org.apache.spark.SparkException: Job aborted due to stage failure: Task 29 in stage 0.0 failed 4 times, most recent failure: Lost task 29.3 in stage 0.0 (TID 92, 10.252.252.125, executor 23): ExecutorLostFailure (executor 23 exited caused by one of the running tasks) Reason: Remote RPC client disassociated. Likely due to containers exceeding thresholds, or network issues. Check driver logs for WARN messages.
Driver stacktrace:
at org.apache.spark.scheduler.DAGScheduler.orgsparkDAGScheduleranonfun1.apply(DAGScheduler.scala:1879)
at org.apache.spark.scheduler.DAGScheduler$$anonfun1.apply(DAGScheduler.scala:1878)
……

這個錯誤是spark任務進行了一段時間之后出來的，在啟動集群和提交任務之初不會有（有的話原因也不一樣）。
關(guān)鍵信息是“Likely due to containers exceeding thresholds”，看上去和資源有關(guān)，但又不是常見的GC。進入spark的logs目錄，沒有從master和worker的LOG中看到有用的信息。進入spark的work目錄，查看各個任務的日志，發(fā)現(xiàn)很多executor產(chǎn)生了hs_err_pidxxxx.log文件，報內(nèi)存不足:

There is insufficient memory for the Java Runtime Environment to continue.
Native memory allocation (mmap) failed to map 291504128 bytes for committing reserved memory.
Possible reasons:
The system is out of physical RAM or swap space
In 32 bit mode, the process size limit was hit
Possible solutions:
Reduce memory load on the system
Increase physical memory or swap space
Check if swap backing store is full
Use 64 bit Java on a 64 bit OS
Decrease Java heap size (-Xmx/-Xms)
Decrease number of Java threads
Decrease Java thread stack sizes (-Xss)
Set larger code cache with -XX:ReservedCodeCacheSize=
This output file may be truncated or incomplete.
……

但實際上機器的可用內(nèi)存資源很充足。256g內(nèi)存+30多g的swap空間。

嘗試1

配置Spark的內(nèi)存，降低worker、executor等的內(nèi)存申請量，問題得到了緩解。基本上只用到總內(nèi)存量的50%以下，問題就基本沒了（偶爾還會報錯）。
在這個過程中，學習了spark對on_heap和off_heap的一些關(guān)聯(lián)i機制（比如一般通過spark_env配的內(nèi)存都是on_heap）。
不過最后發(fā)現(xiàn)這些配置沒啥用，最終有用的就是降低spark內(nèi)存申請。但明明有很多內(nèi)存卻分配不了的感覺令人不爽，治標不治本。

嘗試2

和spark以及任務的各處都找不到有用的信息了，網(wǎng)上也沒有特別現(xiàn)成的解決方案。之后從Linux的角度出發(fā)：采用：
free -h
或
cat /proc/meminfo
命令查看發(fā)現(xiàn)，cache/buffer占用內(nèi)存特別大（主要是cache），一些解釋說諸如對文件特別多的目錄使用ls，其結(jié)果都會緩存下來（buffer），此外可能一些異常進程也留下了垃圾），再有就是讀寫緩存了（cache）。
于是執(zhí)行：
sync
echo 3 > /proc/sys/vm/drop_caches
等命令清理cache。果然可用的內(nèi)存增多了。參考：

Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free.
To free pagecache:
echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes: echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:
echo 3 > /proc/sys/vm/drop_caches
As this is a non-destructive operation, and dirty objects are notfreeable, the user should run "sync" first in order to make sure allcached objects are freed.

此外通過jps命令發(fā)現(xiàn)了一些進程為：process information unavailable
執(zhí)行：
rm -rf /tmp/hsperfdata_*
清楚了殘留的進程。
不過submit spark任務之后還是出現(xiàn)內(nèi)存不夠分的情況，換句話說剛才的設置不起作用。

嘗試3

后來看是研究下面兩個文件：

1. /etc/security/limits.conf ：主要配置并發(fā)進程數(shù)量和同時打開文件數(shù)量。但是項目設備的配置是合理的，并不需要修改。
2. /etc/sysctl.conf：這里面又大量內(nèi)存參數(shù)可以改，當然是不是起到優(yōu)化效果就不一定了。這些配置還可以通過sysctl命令查詢或設置：
   sysctl -a (查看所有參數(shù))
   sysctl -w vm.overcommit_memory=2 （ -w 臨時改變參數(shù)的值）

網(wǎng)上一些參考：

vm.dirty_ratio = 1
vm.dirty_background_ratio=1
vm.dirty_writeback_centisecs=2
vm.dirty_expire_centisecs=3
vm.drop_caches=3
vm.swappiness =100
vm.vfs_cache_pressure=163
vm.overcommit_memory=2
vm.lowmem_reserve_ratio=32 32 8
kern.maxvnodes=3

進行了一些修改并確認生效之后，確認大部分參數(shù)解決不了問題。最后發(fā)現(xiàn)問題落在

vm.overcommit_memory=2

這個參數(shù)及其配套參數(shù)的默認值應該是：

vm.overcommit_memory = 0
vm.overcommit_ratio = 50

顯然是有人改過這個數(shù)值。網(wǎng)上對者overcommit_memory有截然不同的解釋，比如有的說：

• 0是根據(jù)可用內(nèi)存分配內(nèi)存給進程。1是根據(jù)所有物理內(nèi)存分配內(nèi)存給進程，不管當前內(nèi)存狀態(tài)。2是允許內(nèi)存分配超出物理內(nèi)存和交換空間的總內(nèi)存。

我采信了這個觀點，所以看到設備上配置了vm.overcommit_memory=2，覺得是一個減少內(nèi)存限制的配置。但后來覺得不對勁，因為詳查hs_err_pidxxxx.log文件的時候發(fā)現(xiàn)了：

CommitLimit: 165156708 kB
Committed_AS: 164839264 kB

設備的實際內(nèi)存是256g+30多g的swap空間。但是這個limit范圍大概是150G左右，也可以通過Committed_AS（實際分配內(nèi)存）看出基本分完了。于是通過CommitLimit和Committed_AS為關(guān)鍵字查詢，發(fā)現(xiàn)了對overcommit_memory不同的解釋：

• 當設置vm.overcommit_memory=2時，可申請內(nèi)存為： SWAP + 物理內(nèi)存 * overcommit_ratio/100

overcommit_ratio的默認值是50。換句話說，我有256g內(nèi)存，可用范圍就是 128+30g左右，這和在hs_err_pidxxxx.log看到的信息一致。通過：
sysctl -w overcommit_ratio = 80
等方式臨時或永久（通過修改sysctl.conf文件）修改 overcommit_ratio值，可分配的內(nèi)存值確實就增多了（配置vm.overcommit_memory=0或1可能也能解決問題，但由于是共用設備，不知道別人為什么改，能少動就少動）