前言

当我们自建大数据集群（如OLAP集群、实时计算集群、分布式存储集群、全文搜索集群等）的时候，除了硬件资源要合理配备外，在操作系统层面也要进行一些事前配置，让大数据组件能够充分利用硬件资源，避免潜在性能问题和成本浪费。本文综合业内惯例和笔者在之前工作中运维大型集群的经验，对需要注意的部分Linux系统参数做一些解释，读者可参考实际情况设置。有操作系统理论和计算机组成原理基础的话，阅读本文会十分容易。

内存相关参数

交换积极性：vm.swappiness

Linux系统中可以配置交换空间（Swap Space），即当物理内存不足时，将磁盘上的swap分区当做内存使用。但是，由于磁盘的读写速率与内存相比差距过大，一旦频繁发生交换，系统延迟就会增加，造成服务抖动或不可用，这对于大数据集群而言是非常严重的问题。

Linux内核参数vm.swappiness用于控制系统对交换空间的使用积极性，当物理内存占用率高于(100 - vm.swappiness)%时，就会尝试使用交换空间。对于大多数Linux发行版而言，该参数默认值是60，即物理内存占用率高于40%时就有可能开始交换。

显然，大数据集群要将这个参数设置得尽量低，推荐值为0或1。0表示只有当可用物理内存小于阈值vm.min_free_kbytes（下面会讲）时，才会使用交换空间；1则表示最低限度地使用交换空间。

设置方法：

# 临时生效，重启服务器后失效
echo 0 > /proc/sys/vm/swappiness
# 永久生效，写入/etc/sysctl.conf文件并执行sysctl -p
vm.swappiness=0
# 如果内存非常充裕，也可以直接停用swap分区
swapoff -a

内存最低水位：vm.min_free_kbytes

Linux将系统剩余内存的量划分为3道水位线，如下图所示。

其中：

min = vm.min_free_kbytes
low = min * 5 / 4
high = min * 3 / 2

也就是说，vm.min_free_kbytes是内核保留内存的大小，一般不会分配给其他进程使用。该值既不应设置过小，也不应过大。如果过小（比如只有几十MB），三个阈值之间的差值就会非常接近，极易触发直接回收，造成抖动，而如果过大，又会浪费内存资源。一般来讲我们将该值设为机器物理内存大小的1%左右，例如一台128GB内存的机器，我们可以将最低水位设为2GB（注意实际单位为KB）。

设置方法：

# 临时生效，重启服务器后失效
echo 2097152 > /proc/sys/vm/min_free_kbytes
# 永久生效，写入/etc/sysctl.conf文件并执行sysctl -p
vm.min_free_kbytes=2097152

内存超分配：vm.overcommit_memory

我们知道，由于虚拟内存管理机制的存在，进程可以请求分配给自己比当前物理内存容量更大的内存，这种行为叫做Overcommit，即超分配。进程一般不会将申请到的内存立即消耗掉，所以适当的超分配风险是可控的，并且能够提升内存密集型应用的效率，特别是OLAP引擎和内存数据库等。

Linux内核参数vm.overcommit_memory用于设定系统的超分配策略，取值及含义列举如下：

• 0（默认）：启发式（Heuristic）超分配，内核根据当前Page Cache的总量、SLAB中可释放的内存总量、交换空间的大小之和动态计算允许超分配的阈值；
• 1：永远允许，即所有超分配请求都成功，当然所有OOM风险都由用户进程承担；
• 2：不允许，内核以物理内存总量的(vm.overcommit_ratio)%加上交换空间的大小作为固定的分配阈值，超过此阈值的分配请求均失败，其中vm.overcommit_ratio默认值为50。

对于内存密集型应用，此参数应该设为1，一般在部署文档中会有特别说明。设置方法：

# 临时生效，重启服务器后失效
echo 1 > /proc/sys/vm/overcommit_memory
# 永久生效，写入/etc/sysctl.conf文件并执行sysctl -p
vm.overcommit_memory=1

内存映射区域阈值：vm.max_map_count

内存映射是直接将文件地址映射到进程虚拟地址空间的手段，对应mmap()系统调用。操作内存映射文件本质上与操作内存相同，可以减少从内核空间到用户空间的拷贝次数，从而提高性能，如下图所示。

大数据应用往往要创建非常大量的内存映射区域，其阈值由参数vm.max_map_count控制，默认值一般为65530，我们要将其调大几倍。设置方法：

# 临时生效，重启服务器后失效
echo 262144 > /proc/sys/vm/max_map_count
# 永久生效，写入/etc/sysctl.conf文件并执行sysctl -p
vm.max_map_count=262144

透明大页（THP）：/sys/kernel/mm/transparent_hugepage/enabled

我们知道，计算机通过表映射（页表）的方式进行内存寻址，一般系统内存以4KB为一个页，作为内存寻址的最小单元。随着内存不断增大，页表的大小也会随之增大。一台256GB内存的服务器如果使用4KB小页，分级页表大小就要4GB左右。页表本身也是必须放在内存里的，太大就会频繁访存及发生TLB Miss，寻址性能就会下降。

大页（Huge Page）的出现就是为了解决这个问题，它使用2MB的页代替传统小页来管理内存，这样页表大小就可以控制在合理范围内。而透明大页（Transparent Huge Pages / THP）则更进一步，在运行期做大页的转换和管理，因此会引入一定程度的延迟及碎片问题，对于内存密集型的应用（特别是对4KB小页做过特殊优化的应用）副作用较大。

透明大页策略由/sys/kernel/mm/transparent_hugepage/enabled参数控制，取值及含义列举如下：

• always（默认）：在所有内存区域开启并管理THP；
• madvise（推荐）：仅在单个进程范围内使用madvise()系统调用指定的内存区域使用THP，其他区域不使用；
• never：禁用THP。

设置方法：

# 临时生效，重启服务器后失效
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo madvise > /sys/kernel/mm/transparent_hugepage/defrag
# 永久生效，写入启动环境文件如/etc/rc.local中
if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
   echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
   echo madvise > /sys/kernel/mm/transparent_hugepage/defrag
fi

资源限制相关参数

文件描述符数阈值：ulimit -n

Too many open files这样的报错我们应该已经很熟悉了，不过需要注意的是，这里的"open files"并不是指操作系统级别的打开文件数，而是当前用户、当前终端、单个进程的打开文件描述符数。文件描述符表、文件句柄表和inode表的对应关系如下图所示。

可以通过ulimit -a命令列出资源限制值，其中open files一行就是文件描述符数阈值，默认一般是1024，对于大数据集群来说远远不够用，应当通过ulimit -n命令重新设置，或者写入配置文件。

设置方法：

# 执行命令，并将其写入启动环境文件如/etc/rc.local中
ulimit -n 262144
# 也可以写入/etc/security/limits.conf，注意软硬限制值要分别设置
* soft nofile 262144
* hard nofile 262144
# 同时可能需要修改系统文件句柄的最大值fs.file-max
echo 6553600 > /proc/sys/fs/file-max

用户进程数阈值：ulimit -u

高并发或者MPP风格的大数据应用经常会开启很多进程/线程进行并行处理，因此我们有必要提高用户进程数阈值，方法与上一节基本相同，如下：

# 执行命令，并将其写入启动环境文件如/etc/rc.local中
ulimit -u 10240
# 也可以写入/etc/security/limits.conf，注意软硬限制值要分别设置
* soft nproc 10240
* hard nproc 10240
# 同时可能需要修改系统PID的上限值kernel.pid_max
echo 204800 > /proc/sys/kernel/pid_max

其他可选ulimit设置

# 线程栈大小
ulimit -s unlimited
# 最大可加锁内存
ulimit -l unlimited
# 或者写入/etc/security/limits.conf
* soft stack unlimited
* hard stack unlimited
* hard memlock unlimited
* soft memlock unlimited

网络相关参数

监听队列长度：net.core.somaxconn

在Linux系统中，当一个客户端尝试连接到服务器时，服务器将会把该连接放入监听队列中等待处理。而net.core.somaxconn参数定义了这个队列的长度，即可以同时排队等待处理的连接数的最大值，默认值为128。

显然，如果服务的并发连接数很高，队列长度有可能不够，导致连接被拒绝（报错Connection refused或者Connection reset by peer），建议适当调大，如1024。设置方法：

# 临时生效，重启服务器后失效
echo 1024 > /proc/sys/net/core/somaxconn
# 永久生效，写入/etc/sysctl.conf文件并执行sysctl -p
net.core.somaxconn=1024

TCP连接溢出行为：net.ipv4.tcp_abort_on_overflow

如果客户端和服务端之间完成了三次握手，但没有调用accept()实际建立连接，那么此连接会被放入全连接队列中。如果全连接队列被打满，那么服务器会丢弃溢出的连接，并在客户端请求发送数据时，选择以下两种方式之一进行处理：

• 设置一个定时任务，重传服务端SYN/ACK报文给客户端（默认）；
• 直接向客户端返回RST报文，要求重置连接。

这个行为由参数net.ipv4.tcp_abort_on_overflow控制，0对应上述第一种行为，1对应第二种行为。如果希望连接溢出时客户端能够快速感知并fail-fast，应将其设置为1：

# 临时生效，重启服务器后失效
echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow
# 永久生效，写入/etc/sysctl.conf文件并执行sysctl -p
net.ipv4.tcp_abort_on_overflow=1

半连接队列长度：net.ipv4.tcp_max_syn_backlog

与上一节所说的全连接队列相对，Linux还维护有半连接队列，存放没有完成三次握手的连接，net.ipv4.tcp_max_syn_backlog对应该队列的长度。对于数据库类型的大数据应用，连接数有可能在短时间内迅速增加，一般建议适当调大此值。设置方法：

# 临时生效，重启服务器后失效
echo 4096 > /proc/sys/net/ipv4/tcp_max_syn_backlog
# 永久生效，写入/etc/sysctl.conf文件并执行sysctl -p
net.ipv4.tcp_max_syn_backlog=4096

The End

民那晚安晚安。