Spark遇到的一个内存错误
问题
项目中遇到的一个问题，其实不是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.orgspark
DAGScheduler
anonfun
1.apply(DAGScheduler.scala:1879)
at org.apache.spark.scheduler.DAGScheduler$$anonfun
……
这个错误是spark任务进行了一段时间之后出来的，在启动集群和提交任务之初不会有（有的话原因也不一样）。
关键信息是“Likely due to containers exceeding thresholds”，看上去和资源有关，但又不是常见的GC。进入spark的logs目录，没有从master和worker的LOG中看到有用的信息。进入spark的work目录，查看各个任务的日志，发现很多executor产生了hs_err_pidxxxx.log文件，报内存不足:
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.
……
但实际上机器的可用内存资源很充足。256g内存+30多g的swap空间。
尝试1
配置Spark的内存，降低worker、executor等的内存申请量，问题得到了缓解。基本上只用到总内存量的50%以下，问题就基本没了（偶尔还会报错）。
在这个过程中，学习了spark对on_heap和off_heap的一些关联i机制（比如一般通过spark_env配的内存都是on_heap）。
不过最后发现这些配置没啥用，最终有用的就是降低spark内存申请。但明明有很多内存却分配不了的感觉令人不爽，治标不治本。
尝试2
和spark以及任务的各处都找不到有用的信息了，网上也没有特别现成的解决方案。之后从Linux的角度出发：采用：
free -h
或
cat /proc/meminfo
命令查看发现，cache/buffer占用内存特别大（主要是cache），一些解释说诸如对文件特别多的目录使用ls，其结果都会缓存下来（buffer），此外可能一些异常进程也留下了垃圾），再有就是读写缓存了（cache）。
于是执行：
sync
echo 3 > /proc/sys/vm/drop_caches
等命令清理cache。果然可用的内存增多了。参考：
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命令发现了一些进程为：process information unavailable
执行：
rm -rf /tmp/hsperfdata_*
清楚了残留的进程。
不过submit spark任务之后还是出现内存不够分的情况，换句话说刚才的设置不起作用。
尝试3
后来看是研究下面两个文件：
- /etc/security/limits.conf ：主要配置并发进程数量和同时打开文件数量。但是项目设备的配置是合理的，并不需要修改。
- /etc/sysctl.conf：这里面又大量内存参数可以改，当然是不是起到优化效果就不一定了。这些配置还可以通过sysctl命令查询或设置：
sysctl -a(查看所有参数)
sysctl -w vm.overcommit_memory=2（ -w 临时改变参数的值）
网上一些参考：
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
进行了一些修改并确认生效之后，确认大部分参数解决不了问题。最后发现问题落在
vm.overcommit_memory=2
这个参数及其配套参数的默认值应该是：
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
显然是有人改过这个数值。网上对者overcommit_memory有截然不同的解释，比如有的说：
- 0是根据可用内存分配内存给进程。1是根据所有物理内存分配内存给进程，不管当前内存状态。2是允许内存分配超出物理内存和交换空间的总内存。
我采信了这个观点，所以看到设备上配置了vm.overcommit_memory=2，觉得是一个减少内存限制的配置。但后来觉得不对劲，因为详查hs_err_pidxxxx.log文件的时候发现了：
CommitLimit: 165156708 kB
Committed_AS: 164839264 kB
设备的实际内存是256g+30多g的swap空间。但是这个limit范围大概是150G左右，也可以通过Committed_AS（实际分配内存）看出基本分完了。于是通过CommitLimit和Committed_AS为关键字查询，发现了对overcommit_memory不同的解释：
- 当设置vm.overcommit_memory=2时，可申请内存为： SWAP + 物理内存 * overcommit_ratio/100
overcommit_ratio的默认值是50。换句话说，我有256g内存，可用范围就是 128+30g左右，这和在hs_err_pidxxxx.log看到的信息一致。通过：
sysctl -w overcommit_ratio = 80
等方式临时或永久（通过修改sysctl.conf文件）修改 overcommit_ratio值，可分配的内存值确实就增多了（配置vm.overcommit_memory=0或1可能也能解决问题，但由于是共用设备，不知道别人为什么改，能少动就少动）
