CentOS 7 内存探究

在 Linux 系统中，为了提高文件系统性能，内核利用一部分物理内存分配出缓冲区，用于缓存系统操作和数据文件，当内核收到读写的请求时，内核先去缓存区找是否有请求的数据，有就直接返回，如果没有则通过驱动程序直接操作磁盘。

内存查看

当我们使用 free -h 命令时，会显示如下的信息：

              total        used        free      shared  buff/cache   available
Mem:           7.6G        166M        7.0G        8.5M        515M        7.2G
Swap:          7.9G          0B        7.9G

• total：内存总数
• used：已经使用的内存数
• free：空闲的内存数
• shared：共享内存数
• buff/cache：代表的是buff 和 cache 的内存
• available：活跃的内存

available 代表一个新的应用程序可以使用内存的估计值，它不等于 free + buff/cache

官方定义

Estimation of how much memory is available for starting new applications, without swapping. Unlike the data provided by the cache or free fields,  this  field takes  into  account  page  cache  and  also that not all reclaimable memory slabs will be reclaimed due to items being in use (MemAvailable in /proc/meminfo,available on kernels 3.14, emulated on kernels 2.6.27+, otherwise the same as free

大致意思就是立即可以使用的内存大小。

比如：一个新的程序要运行需要的最小内存，如果 available 大于这个最小内存就可以安装。

关系

total = used + available

手动释放Linux 内存 cache

当在 Linux 下频繁存取文件后，物理内存会很快被用光，当程序结束后，内存不会被正常释放，而是一直作为 caching。

[root@localhost ~]#dd if=/dev/zero of=bigfile bs=1M count=20480 &
[1] 19883
[root@localhost ~]#free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        133M        131M        8.5M        7.4G        7.2G
Swap:          7.9G          0B        7.9G

使用 dd 模拟系统读写，此时：

• used 为 133M
• buff/cache 为 7.4G

单从这两项来看，内存已经被 buff/cache 耗尽。当 dd 命令执行完毕，等待一段时间 buff/cache 是否会释放掉内存到 free 中呢？

等待一段时间，查看内存：

[root@localhost ~]#free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        129M        133M        8.5M        7.4G        7.2G
Swap:          7.9G          0B        7.9G

系统并没有自动释放 buff/cache 那么是否能够通过手工来进行释放呢？

PS：在 CentOS 7.X 版本中，真正可用内存应该看 available 项。

在 /proc 目录下除了只读文件，在 /proc/sys/ 子目录下有很多文件内容可以进行修改，修改了这些文件可以更改内核的运行特性。写入的格式一般为：echo N > /path/to/your/filename

如果要手动释放buff/cache 则需要对 /proc/sys/vm/drop_caches 进行操作。

对于 /proc/sys/vm/drop_caches 官方文档介绍：

操作如下：

[root@localhost ~]#free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        128M        133M        8.5M        7.4G        7.2G
Swap:          7.9G          0B        7.9G
[root@localhost ~]#sync
[root@localhost ~]#sync
[root@localhost ~]#sync
[root@localhost ~]#free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        128M        133M        8.5M        7.4G        7.2G
Swap:          7.9G          0B        7.9G
[root@localhost ~]#echo 3 > /proc/sys/vm/drop_caches 
[root@localhost ~]#free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        128M        7.5G        8.5M         43M        7.4G
Swap:          7.9G          0B        7.9G

通过执行: echo 3 > /proc/sys/vm/drop_caches 效果很明显，buff/cache 释放了内存到 free 中。

总结

手动释放 buff/cache 只需要执行 echo 3 > /proc/sys/vm/drop_caches 就能实现，但是前提需要执行 sync 确保缓存区都写入到磁盘，否则会造成文件的丢失等问题。

在释放前和释放后， available 并没有发生太大的变化，个人认为在 CentOS 7.X 版本中，真正空闲的内存更应该是 available 稍后通过实例来说明。

手动释放 Swap 分区内存

Swap 用途：Swap 意思是交换分区，通常我们说的虚拟内存，是从硬盘中划分出一个分区。当物理内存不够用的时候，内核就会释放缓存区（buffers/cache）里一些长时间不用的程序，然后将这些程序临时放到 Swap中，也就是说如果物理内存和缓存区内存不够用的时候，才会用到 Swap

查看了部分资料，清理 Swap 的方式比较野蛮：

swapoff -a && swapon -a

在执行该命令之前，建议多次执行 sync 避免文件的丢失。

注意：这样清理有个前提条件，空闲的内存必须比已经使用的Swap空间要大！

这里有个配置是关于 Swap 的 /proc/sys/vm/swappiness

swappiness 值的大小对如何使用 Swap 分区有着很大的联系。swappiness=0 的时候表示最大限度使用物理内存，然后才是 swap空间，swappiness=100 的时候表示积极的使用swap分区，并且把内存上的数据及时的搬到swap空间里面。Linux 的基本默认配置为60，具体如下：

[root@localhost ~]# sysctl -q vm.swappiness
vm.swappiness = 30

也就是说，内存在使用 100-70=30% 的时候，就开始出现有交换分区的使用。这样会加大系统的IO，同时造成大量页的换进换出，严重影响系统的性能，所以在操作系统层面，要尽可能使用内存。

临时调整方式：

[root@localhost ~]# sysctl vm.swappiness=10
vm.swappiness = 10
[root@localhost ~]# cat /proc/sys/vm/swappiness 
10

永久生效方式：

[root@localhost ~]# sysctl -q vm.swappiness
vm.swappiness = 30
[root@localhost ~]# cat /etc/sysctl.d/my-default.conf 
vm.swappiness=10
[root@localhost ~]# sysctl -p /etc/sysctl.d/my-default.conf

真实案例

线上有台虚拟机跑的 mongodb 服务，查看内存如下：

[root@node3 ~]# free -h 
              total        used        free      shared  buff/cache   available
Mem:            31G         19G        286M         10G         11G        253M
Swap:          4.0G        3.9G         54M

• used 为 19G
• buff/cache 缓存为 11G
• available 活跃可用的内存为 253M
• Swap 已用为 3.9G

对内存使用已经很夸张了， 比较庆幸的是没有触发 OOM killer

[root@node3 ~]# egrep -ri 'out of memory' /var/log/
[root@node3 ~]#

通过上面的理解，进行操作：

第一步：清理 buff/cache

[root@node3 ~]# free -h 
              total        used        free      shared  buff/cache   available
Mem:            31G         19G        286M         10G         11G        253M
Swap:          4.0G        3.9G         54M
[root@node3 ~]# sync 
[root@node3 ~]# sync 
[root@node3 ~]# sync 
[root@node3 ~]# echo 3 > /proc/sys/vm/drop_caches 
[root@node3 ~]# free -h 
              total        used        free      shared  buff/cache   available
Mem:            31G         19G        306M         10G         11G        263M
Swap:          4.0G        3.9G         54M

可以看到这样的操作在主机上没有产生任何效果。

Swap 已经使用了 3.9G 而物理内存活跃可用的空闲空间为： 263M 完全不够释放的前提条件。因此也无法对 Swap 进行释放。

通过 smem 查看使用 Swap的 进程：

[root@node3 ~]# smem -tp -s swap  -r
  PID User     Command                         Swap      USS      PSS      RSS 
10701 root     /usr/local/mongodb/bin/mong   29.18%   59.54%   59.54%   59.54% 
 2748 root     /usr/bin/python /usr/bin/sa    0.46%    0.07%    0.07%    0.07% 
 2752 root     /usr/bin/python /usr/bin/sa    0.45%    0.00%    0.00%    0.00% 
 2745 root     /usr/bin/python /usr/bin/sa    0.37%    0.00%    0.00%    0.00% 
  871 root     /usr/bin/python -Es /usr/sb    0.27%    0.00%    0.00%    0.00%
  ...

注意：smem 默认的单位为：KB

也可以通过 awk 统计：

for i in $( cd /proc;ls |grep "^[0-9]"|awk ' $0 >100') ;do awk '/Swap:/{a=a+$2}END{print '"$i"',a/1024"M"}' /proc/$i/smaps 2>/dev/null ; done | sort -k2nr |head

上面这台主机由于是直接将内存挂载到目录，mongodb 数据都跑在内存中使用，确定为内存严重不足，最后切换到内存更大的主机上了。 个人理解：当Swap被使用时，查看 available 项，如果 available 值大于 已使用的 Swap 可以进行手动释放内存，否则就是内存不足的表现，应当查看程序是否存在问题或者直接换更大内存的主机。

为了证明这个观点，找了几台虚拟节点进行实践：

示例

[root@node1 ~]# free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        177M        2.0G        315M        5.5G        6.9G
Swap:          4.0G         32M        4.0G

该主机运行了一个java程序，Swap used < available 满足条件，查看 Swap 都是被那些程序在用。

[root@node1 ~]# smem -s swap -r | head -5
  PID User     Command                         Swap      USS      PSS      RSS 
  873 root     /usr/bin/python -Es /usr/sb     7268     3892     4453     6800 
  669 polkitd  /usr/lib/polkit-1/polkitd -     5564     1904     2597     4628 
 1414 root     /usr/libexec/postfix/master      932      172      240     1208 
16744 nginx    nginx: worker proces             928      324      422     1360

[root@node1 ~]# for i in $( cd /proc;ls |grep "^[0-9]"|awk ' $0 >100') ;do awk '/Swap:/{a=a+$2}END{print '"$i"',a/1024"M"}' /proc/$i/smaps 2>/dev/null ; done | sort -k2nr |head -5
873 7.09766M
669 5.43359M
1414 0.910156M
16744 0.90625M
1438 0.898438M

查看结果都是一些系统默认进程占用的，Swap没有得到释放，接下来通过手动的方式进行释放：

[root@node1 ~]# sync && sync && sync
[root@node1 ~]# free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        112M        2.1G        315M        5.4G        6.9G
Swap:          4.0G         32M        4.0G
[root@node1 ~]# swapoff -a 
[root@node1 ~]# free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        128M        2.1G        328M        5.4G        6.9G
Swap:            0B          0B          0B
[root@node1 ~]# swapon -a
[root@node1 ~]# free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        131M        2.1G        328M        5.4G        6.9G
Swap:          4.0G          0B        4.0G
[root@node1 ~]# cat /etc/sysctl.d/my-default.conf 
vm.swappiness=10

通过操作发现，Swap 被释放了，内存中的 shared （共享内存）却增长了，接下来尝试释放buff/cache ：

[root@node1 ~]# sync && sync && sync
[root@node1 ~]# free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        131M        2.1G        328M        5.4G        6.9G
Swap:          4.0G          0B        4.0G
[root@node1 ~]# cat /proc/sys/vm/drop_caches 
0
[root@node1 ~]# echo 3 > /proc/sys/vm/drop_caches

执行完 echo 3 > /proc/sys/vm/drop_caches 打开另一个会话持续查看内存状态变化：

[root@node1 ~]# free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        133M        2.3G        328M        5.2G        6.9G
Swap:          4.0G          0B        4.0G
[root@node1 ~]# free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        133M        2.4G        328M        5.1G        6.9G
Swap:          4.0G          0B        4.0G
[root@node1 ~]# free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        133M        3.6G        328M        3.9G        6.9G
Swap:          4.0G          0B        4.0G
[root@node1 ~]# free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        133M        4.3G        328M        3.2G        6.9G
Swap:          4.0G          0B        4.0G
[root@node1 ~]# free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        117M        7.1G        328M        399M        7.1G
Swap:          4.0G          0B        4.0G
[root@node1 ~]# free -h 
              total        used        free      shared  buff/cache   available
Mem:           7.6G        117M        7.1G        328M        399M        7.1G
Swap:          4.0G          0B        4.0G

可以发现，buff/cache 是逐渐递减的，释放结果：

used 从 133M 减少到 117M

free 从 2.3G 增加到 7.1G

available 从 6.9G 增加到 7.1G

最后引用别人博客的一段话，我觉得很客观：

实际项目中告诉我们，如果因为是应用有像内存泄露、溢出的问题，从swap的使用情况是可以比较快速可以判断的，但free上面反而比较难查看。相反，如果在这个时候，我们告诉用户，修改系统的一个值，“可以”释放内存，free就大了。用户会怎么想？不会觉得操作系统“有问题”吗？所以说，我觉得既然核心是可以快速清空buffer或cache，也不难做到（这从上面的操作中可以明显看到），但核心并没有这样做（默认值是0），我们就不应该随便去改变它。一般情况下，应用在系统上稳定运行了，free值也会保持在一个稳定值的，虽然看上去可能比较小。

当发生内存不足、应用获取不到可用内存、OOM错误等问题时，还是更应该去分析应用方面的原因，如用户量太大导致内存不足、发生应用内存溢出等情况，否则，清空buffer，强制腾出free的大小，可能只是把问题给暂时屏蔽了。

排除内存不足的情况外，除非是在软件开发阶段，需要临时清掉buffer，以判断应用的内存使用情况；或应用已经不再提供支持，即使应用对内存的时候确实有问题，而且无法避免的情况下，才考虑定时清空buffer。（可惜，这样的应用通常都是运行在老的操作系统版本上，上面的操作也解决不了）。而生产环境下的服务器可以不考虑手工释放内存，这样会带来更多的问题。记住内存是拿来用的，不是拿来看的。

不像windows，无论你的真实物理内存有多少，他都要拿硬盘交换文件来读。这也就是windows为什么常常提示虚拟空间不足的原因，你们想想多无聊，在内存还有大部分的时候，拿出一部分硬盘空间来充当内存。硬盘怎么会快过内存，所以我们看linux，只要不用swap的交换空间，就不用担心自己的内存太少。如果常常swap用很多,可能你就要考虑加物理内存了，这也是linux看内存是否够用的标准哦。

引用链接地址

系统初始化对Swap的优化

通过上面的实践，总结针对 Swap 内核参数优化如下：

1. 设置 vm.swappiness=10 尽量减少对 Swap 的使用；
2. 通过对 /proc/sys/vm/drop_caches 值的修改实现手动释放 buff/cache 默认为0，设置为 3 则释放；
3. 如果 available > Swap[used] 则可以通过 swappoff -a && swapon -a 来强制释放Swap

注意：在执行手动释放内存时候，要多次执行sync！

接下来在介绍 一种对 Swap 的优化方案。

Numa

numa 是一种关于多个cpu如何访问内存的架构模型，现在的cpu 基本都是numa架构，linux内核2.5开始支持numa。

numa架构简单的来说，一个物理cpu（一般包含多个逻辑cpu或多个核心）构成一个node，这个node不仅包括cpu，还包括一组内存插槽，也就是说一个物理cpu以及一块内存构成了一个node。每个node可以访问自己node下的内存，也可以访问其他node的内存，但是访问速度是不一样的，自己node下的更快。numactl --hardware命令可以查看node状况。

安装 numactl ：

[root@localhost ~]# yum install numactl -y
# 列举系统上的NUMA节点及内存信息
[root@localhost ~]# numactl --hardware

Redhat 或者 Centos 系统中可以通过命令判断BIOS 层是否开启 NUMA

egrep -i numa /var/log/dmesg

如果输出的结果为：No NUMA configuration found 说明 numa 为 disable

如果不是上面内容说明numa为enable，例如显示：Enabling automatic NUMA balancing.

可以使用 lscpu 查看 NUMA 的分布：

当发现numa_miss 数值比较高时，说明需要对分配策略进行调整。例如将制定进程关联到指定个的cpu上，从而提高内存命中率。

numa_hit：成功再本地node命中的次数。
numa_miss：本因分配在其他NODE的内存，由于其他节点内存太少，导致内存分配在本node的页数量。
numa_foreign：初始分配在本地，最后分配在其他节点的叶数量。每个numa_foreign对应numa_miss事件。
interleave_hit：interleave策略页成功分配到这个节点。
local_node：本节点进程成功在本节点分配页数量。
other_node：其他节点运行的进程，在本节分配的页数量。

---

现在的机器上都是有多个CPU和多个内存块的。以前我们都是将内存块看成是一大块内存，所有CPU到这个共享内存的访问消息是一样的。这就是之前普遍使用的SMP模型。但是随着处理器的增加，共享内存可能会导致内存访问冲突越来越厉害，且如果内存访问达到瓶颈的时候，性能就不能随之增加。NUMA（Non-Uniform Memory Access）就是这样的环境下引入的一个模型。比如一台机器是有2个处理器，有4个内存块。我们将1个处理器和两个内存块合起来，称为一个NUMA node，这样这个机器就会有两个NUMA node。在物理分布上，NUMA node的处理器和内存块的物理距离更小，因此访问也更快。比如这台机器会分左右两个处理器（cpu1, cpu2），在每个处理器两边放两个内存块(memory1.1, memory1.2, memory2.1,memory2.2)，这样NUMA node1的cpu1访问memory1.1和memory1.2就比访问memory2.1和memory2.2更快。所以使用NUMA的模式如果能尽量保证本node内的CPU只访问本node内的内存块，那这样的效率就是最高的。

---

这里有一个 numa 的陷阱，现象就是当你的服务器还有内存的时候，发现它已经在开始使用 Swap 了， 甚至已经导致机器出现停滞的想象。这个就是这个就有可能是由于numa的限制，如果一个进程限制它只能使用自己的numa节点的内存，那么当自身numa node内存使用光之后，就不会去使用其他numa node的内存了，会开始使用swap，甚至更糟的情况，机器没有设置swap的时候，可能会直接死机！所以可以使用numactl --interleave=all来取消numa node的限制。

如果你的程序是会占用大规模内存的，你大多应该选择关闭numa node的限制（或从硬件关闭numa）。因为这个时候你的程序很有几率会碰到numa陷阱。另外，如果你的程序并不占用大内存，而是要求更快的程序运行时间。你大多应该选择限制只访问本numa node的方法来进行处理。

内核参数：

[root@localhost ~]#sysctl -a | egrep overcommit_memory
vm.overcommit_memory = 0

该参数为内存分配策略

可选值：0、1、2 默认为 0

0：表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。

1：表示内核允许分配所有的物理内存，而不管当前的内存状态如何。

2：表示内核允许分配超过所有物理内存和交换空间总和的内存

[root@localhost ~]#sysctl -a | egrep  zone_reclaim_mode
vm.zone_reclaim_mode = 0

可选值：0 ， 1

当某个节点可用内存不足时：

1：如果为0的话，那么系统会倾向于从其他节点分配内存

2：如果为1的话，那么系统会倾向于从本地节点回收Cache内存多数时候

Cache 对性能很重要，所以0是一个更好的选择，不需要修改。

Mongodb 的 NUMA 问题

mongodb日志显示如下：

WARNING: You are running on a NUMA machine.
We suggest launching mongod like this to avoid performance problems:
numactl –interleave=all mongod [other options]

解决方案：临时修改numa内存分配策略为 interleave=all （在所有node节点进行交织分配的策略）：

1. 在原启动命令前加 numactl --interleave=all

如：numactl --interleave=all ${MONGODB_HOME}/bin/mongod --config conf/mongodb.conf

2. 修改内核参数

echo 0 > /proc/sys/vm/zone_reclaim_mode ; echo "vm.zone_reclaim_mode = 0" >> /etc/sysctl.conf

深入NUMA

NUMA 和 SMP

NUMA和SMP是两种CPU相关的硬件架构。在SMP架构里面，所有的CPU争用一个总线来访问所有内存，优点是资源共享，而缺点是总线争用激烈。随着PC服务器上的CPU数量变多（不仅仅是CPU核数），总线争用的弊端慢慢越来越明显，于是Intel在Nehalem CPU上推出了NUMA架构，而AMD也推出了基于相同架构的Opteron CPU。NUMA最大的特点是引入了node和distance的概念。对于CPU和内存这两种最宝贵的硬件资源，NUMA用近乎严格的方式划分了所属的资源组（node），而每个资源组内的CPU和内存是几乎相等。资源组的数量取决于物理CPU的个数（现有的PC server大多数有两个物理CPU，每个CPU有4个核）；distance这个概念是用来定义各个node之间调用资源的开销，为资源调度优化算法提供数据支持。

NUMA 的相关策略

• 每个进程（或线程）都会从父进程继承NUMA策略，并分配有一个优先node。如果NUMA策略允许的话，进程可以调用其他node上的资源。
• NUMA的CPU分配策略有cpunodebind、physcpubind。cpunodebind规定进程运行在某几个node之上，而physcpubind可以更加精细地规定运行在哪些核上。
• NUMA的内存分配策略有localalloc、preferred、membind、interleave。

localalloc：规定进程从当前node上请求分配内存；
preferred：比较宽松地指定了一个推荐的node来获取内存，如果被推荐的node上没有足够内存，进程可以尝试别的node。
membind：可以指定若干个node，进程只能从这些指定的node上请求分配内存。 
interleave：规定进程从指定的若干个node上以RR（Round Robin 轮询调度）算法交织地请求分配内存。

修改NUMA 内存配置命令如下：

memory policy is --interleave | -i, --preferred | -p, --membind | -m, --localalloc | -l

NUMA 默认的内存分配策略是优先在进程所在CPU 的本地内存中分配，会导致CPU节点之间内存分配不均衡，当某个CPU节点的内存不足时，会导致Swap产生，而不是从远程节点分配内存。这就是所谓的 Swap Insanity 现象。

---

MySQL采用了线程模式，对于NUMA特性的支持并不好，如果单机只运行一个MySQL实例，我们可以选择关闭NUMA，关闭的方法有三种：

1. 硬件层，在BIOS 中设置关闭；
2. OS内核，启动时设置 numa=off;
3. 可以用 numactl 命令将内存分配策略修改为 interleave (交叉)

如果单机运行多个MySQL实例，我们可以将MySQL绑定在不同的CPU节点上，并且采用绑定的内存分配策略，强制在本节点内分配内存，这样既可以充分利用硬件的NUMA特性，又避免了单实例MySQL对多核CPU利用率不高的问题

---

NUMA 和 Swap 的关系

NUMA 的内存分配策略对于进程（或线程）之间来说，并不是公平的。在现在的 Redhat Linux中， localalloc 是默认的NUMA 内存分配策略，这个配置选项导致资源独占程序很容易将某个 node 的内存用尽。而当某个 node 的内存耗尽时，Linux 又刚好将这个 node 分配给了某个需要大量内存的进程（或线程），swap 就妥妥的产生了。尽管此时还有很多 page cache 可以释放，甚至还有很多的 free 内存。

对于 MySQL 来说，解决Swap的问题很简单：只要启动MySQL之前使用 numactl --interleave 来修改 NUMA 策略即可。

NUMA 之 CPU 优化

现在的服务器CPU 新增了一项新功能：CPU节能。

[root@mongodb ~]# lscpu | egrep "model name"
[root@mongodb ~]# lscpu | egrep -i "model name"
Model name:            Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
[root@mongodb ~]# cat /proc/cpuinfo | egrep -i mhz
cpu MHz		: 1200.000
cpu MHz		: 1200.000
cpu MHz		: 1200.000
cpu MHz		: 1200.000
cpu MHz		: 1200.000
cpu MHz		: 1440.000
cpu MHz		: 1200.000
...

CPU 实际运行的频率和标称的频率不符，这就是CPU启用了节能模式。操作系统和CPU 硬件配合，系统不繁忙的时候，为了节约电能和降低温度，它会将 CPU降频。这对于需要高性能的服务来说，简直是灾难，比如 MySQL。

为了保证服务能够充分利用cpu的资源，建议设置CPU 为最大性能模式。这个设置可以在 BIOS 和操作系统中设置。最好的方式是在 BIOS 中设置，更好更彻底。

在操作系统中，CPU 设置为高性能：

cpupower -c all frequency-set -g performance

再来看看内存方面， 有哪些可以优化。

可以设置的内存分配方式，目前支持的方式包括：

--interleave=nodes
--membind=nodes
--cpunodebind=nodes
--physcpubind=cpus
--localalloc
--preferred=node

简单来说，可以指定内存在本地分配，在某几个CPU 节点分配或轮询分配。除非设置为 --interleave=nodes 轮询分配方式，即内存可以在任意NUMA节点上分配这种方式以外其他的方式就算其他 NUMA 节点上还有内存剩余，Linux 也不会把剩余的内存分配给这个进程，而是采用 Swap 的方式获得内存。所以说：最简单的方式：关闭这个特性。

关闭特性的方法，分别为：BIOS 关闭 、 操作系统关闭

在操作系统中关闭，可以通过修改 /etc/grub.cfg 在 kernel 行最后添加 numa=off

另外可以设置 vm.zone_reclaim_mode 为 0 尽量回收内存。

还有一个参数 vm.swappiness 是操作系统控制物理内存交换出去的策略。它允许的值是一个百分比的值，最小为0，最大运行100，该值默认为60。vm.swappiness设置为0表示尽量少swap，100表示尽量将inactive的内存页交换出去。

具体的说：当内存基本用满的时候，系统会根据这个参数来判断是把内存中很少用到的inactive 内存交换出去，还是释放数据的cache。cache中缓存着从磁盘读出来的数据，根据程序的局部性原理，这些数据有可能在接下来又要被读 取;inactive 内存顾名思义，就是那些被应用程序映射着，但是 长时间 不用的内存。

Linux中，内存可能处于三种状态：free，active和inactive。系统内核会根据内存页的访问情况，不定时的将活跃active内存被移到inactive列表中，这些inactive的内存可以被 交换到swap中去。

为了尽可能少的交换到 Swap中，最好将 vm.swappiness 设置为 10 或者 1