1、说在前面
过完今天就放假回家了(挺高兴),于是提前检查了下个服务集群的状况,一切良好。正在我想着回家的时候突然发现手机上一连串的告警,spark任务执行失败,spark空间不足。我的心突然颤抖了一下,于是赶紧去看服务器的磁盘容量:
#df -h
确实,还剩下6.8G,赶紧排查是什么占用了空间。发现hadoop、spark站的空间比较大,一个50多G(data)、一个30多G(spark-events)。不对啊,这也没占多少啊,于是登录到hadoop的webui去看资源的使用情况:
发现Non DFS Used的值很大,接下来就是名词解释时间:
Capacity:可用的总空间
Used:已用的空间
Non DFS Used:非hdfs文件占用dfs的空间(侵占)
Remaining:剩余可用空间
发现Non DFS Used的值都很大,证明有很多的非hdfs文件侵占了大量的dfs空间。可以看到其中有一个加点只剩6.03G了。这个总空间的大小默认就是磁盘的大小,不过hadoop有个磁盘的配置项dfs.datanode.du.reserved,这个配置是设置hadoop保留一部分不用于hdfs存储的空间默认是0。
2、好了,明白这个后,开始去排查到底是什么文件侵占了dfs的空间。看了一下服务器上面部署的服务,有spark、hadoop(hdfs)、presto,如果是对大数据相对熟悉的人第一判断应该是spark,首先想到的是spark work和spark-events,检查是否运行了history。简单科普一下,spark work存放的是一个spark work任务运行的依赖环境和日志输出,集群其他的节点都来这个地方拉取,spark-events存放的是运行日志,history web就是去的这里的数据。经检查发现是work,已经201G了。
使用spark standalone模式执行任务,每提交一次任务,在每个节点work目录下都会生成一个文件夹,命名规则app-20180212191730-0249。该文件夹下是任务提交时,各节点从主节点下载的程序所需要的资源文件。 这些目录每次执行都会生成,且不会自动清理,执行任务过多会将内存撑爆。将历史没用的work目录下面的app目录删除:
3、解决方案
需要添加定时清理策略,只针对于standalong模式:
在spark-env.sh里面添加如下配置
export SPARK_WORKER_OPTS="
-Dspark.worker.cleanup.enabled=true
-Dspark.worker.cleanup.interval=1800
-Dspark.worker.cleanup.appDataTtl=3600"
注:
-Dspark.worker.cleanup.enabled=true:是否开启自动清理
-Dspark.worker.cleanup.interval=1800:清理周期,每隔多长时间清理一次,单位秒
-Dspark.worker.cleanup.appDataTtl=3600:保留最近多长时间的数据
参考:
https://spark.apache.org/docs/latest/spark-standalone.html
原文地址:https://www.cnblogs.com/cuishuai/p/8444386.html