记录一次生产环境hadoop集群优化以及pid文件缺失处理

一、优化准备

优化需要根据实际情况综合分析

1、关闭系统swap分区（如果未关闭的话）

在Hadoop中，如果使用系统默认设置，会导致swap分区被频繁使用，集群会不断发出警告。

对于每个作业处理的数据量和每个Task中用到的各种缓冲，用户都是完全可控的。

echo "vm.swappiness = 0" >> /etc/sysctl.conf

说明：尽量不使用交换分区，注意不是禁用

2、资源和配置信息

2台namenode，5台datanode资源和配置信息

服务分布表如下所示：

软件版本：

hadoop(hdfs+yarn) 2.7.3

hbase 1.2.4

查看CPU信息的命令：

查看CPU型号

# cat /proc/cpuinfo | grep name | cut -d: -f2 | uniq 

查看物理CPU个数

# cat /proc/cpuinfo |grep "physical id" | sort | uniq -c | wc -l

查看没有物理CPU中的core的个数，也就是核数

# cat /proc/cpuinfo | grep "cpu cores" | uniq

查看逻辑CPU的个数

# cat /proc/cpuinfo | grep "processor" | wc -l

CPU总核数= 物理CPU个数 * 每颗物理CPU的核数

总逻辑CPU数 = 物理CPU个数 * 每颗物理CPU的核数 * 超线程数

资源情况：

内存 16G

CPU8（8个物理CPU，单核，单线程）

3、dfs.datanode.max.xcievers （dfs.datanode.max.transfer.threads）

这两个是一个参数，只不过前边一个是hadoop1.0之前的参数，表示datanode上负责进行文件操作的线程数。如果需要处理的文件过多，而这个参数设置得过低就会有一部分文件处理不过来，就会报下面这个异常：

ERROR org.apache.hadoop.dfs.DataNode: DatanodeRegistration(10.10.10.53:50010,storageID=DS-1570581820-10.10.10.53-50010-1224117842339,infoPort=50075, ipcPort=50020):DataXceiver: java.io.IOException: xceiverCount 258 exceeds the limit of concurrent xcievers 256 

linux系统中所有的文件操作都被绑定到一个socket上，进一步具体可以把他看做是一个线程。而这个参数就是指定这种线程的个数。在datanode里面有一个专门的线程组来维护这些线程，同时有一个守护线程来监视这个线程组的体量，它负责监测线程数量是否到达上线，超过就抛出异常。因为如果这样的线程过多，系统内存就会暴掉。

对于参数dfs.datanode.max.transfer.threads还依照现有配置 8192

  <property>

                <name>dfs.datanode.max.transfer.threads</name>

                <value>8192</value>

        </property>

默认值：4096

4、dfs.namenode.handler.count

NameNode用来处理来自DataNode的RPC请求的线程数量

NameNode有一个工作线程池用来处理客户端的远程过程调用及集群守护进程的调用。处理程序数量越多意味着要更大的池来处理来自不同DataNode的并发心跳以及客户端并发的元数据操作。对于大集群或者有大量客户端的集群来说，通常需要增大参数dfs.namenode.handler.count的默认值10。设置该值的一般原则是将其设置为集群大小的自然对数乘以20，即20logN，N为集群大小。如果该值设的太小，明显的状况就是DataNode在连接NameNode的时候总是超时或者连接被拒绝，但NameNode的远程过程调用队列很大时，远程过程调用延时就会加大。

集群大小是7,7的自然对数约等于2，所以这里的配置就是 20*log7 = 40

<property>  

<name>dfs.namenode.handler.count</name>  

<value>40</value>  

</property> 

默认值：10