文章目录 前言问题原因：为什么出现这么大的值？为什么会发生 swap free 大于 swap total 的现象? 解决方案：实践：1. 启用交换分区2. 增加交换分区使用频率3. 编写一个内存代码 `munch.c`4. 编译5. 执行6. 查看内存7. 修改交换分区使用频率 总结：错误：参考：
前言
今天发现有台服务swap分区数据显示异常，使用free -g 命令查看内存使用情况，swap 的 used 远远超过 swap total 的值, free 的值也大于 total, 如下所示:
[root@dx-selk00 ~]# free -g total used free shared buffers cachedMem: 125 125 0 0 0 40-/+ buffers/cache: 83 42 Swap: 0 1717986918 3可以看到交换分区使用明显是不正常的，并且使用swapon/swapoff 命令也并不能解决问题！
使用swapon -a
使用swapoff -a
可以看到使用swapon/swapoff 命令也并不能解决问题！
通过查看 free 命令的源代码说明: https://github.com/mmalecki/procps/
free.c 文件关于 swap 信息的代码:
22 #define S(X) ( ((unsigned long long)(X) << 10) >> shift)......38 int shift = 10;......100 printf(101 "%-7s %10Lu %10Lu %10Lun", "Swap:",102 S(kb_swap_total),103 S(kb_swap_used),104 S(kb_swap_free)105 );追踪 kb_swap_used 到 proc/sysinfo.c 文件的代码:
41 #define MEMINFO_FILE "/proc/meminfo"...589 FILE_TO_BUF(MEMINFO_FILE,meminfo_fd);...621 kb_swap_used = kb_swap_total - kb_swap_free;622 kb_main_used = kb_main_total - kb_main_free;从代码来看 free 命令是通过读取 /proc/meminfo 的信息来显示内存及 swap 的使用, 通过 free -m 函数可以看到 free 大于 total 的总量, 在这里的话 X 即为负数 -2752, 在宏定义函数 S 中, 将 X 强制转换为64位的无符号整形, 表达式 (unsigned long long) (X) 等效于 2^64 - 2752 , 计算出结果后左移 10 位再右移 10(shift 值) 位, 得出结果 18014398509479232.
为什么会发生 swap free 大于 swap total 的现象?在 kernel-2.6.32-573.7.1 版本之前, 函数 get_swap_page 在加锁的过程中去掉了自旋锁 swap_lock, 这可能会引起 nr_swap_pages 检测异常使得 /proc/meminfo 记录失效的 swapfree 数值, 由此可能引起 swapfree 大于 swaptotal 的现象. 详见: RHBA-2015-1827.html bug 说明
A previous change in the get_swap_page() locking removed the use of theswap_lock spinlock. This could cause nr_swap_pages corruption and invalid
SwapFree information in the /proc/meminfo file, where the size of SwapFree could
exceed the size of SwapTotal. This update uses an atomic variable for
nr_swap_pages, and the size of SwapFree in /proc/meminfo is now correct.
(BZ#1259362) 解决方案：
上述问题的原因在于 kernel 方面的 bug 而引起, 所以要永久杜绝该现象可以升级内核到 2.6.32-573.7.1 版本, 重启后即可生效; 如果不升级 kernel 的话, 只是简单的 swapoff/swapon 是不能让结果正常显示的, 因为 swap 的使用未见变化。
临时解决方案： 重启永久解决方案：升级内核占用部分 swap 空间就可以使 free 显示正常由于这台服务器上部署的服务比较多，切服务比较重要，索引重启机器和升级内核的方案不能使用。于是选择使用第三种方案：
实践： 1. 启用交换分区因为我们需要占用部分 swap 空间，所以第一步打开交换分区。
swapon -a 2. 增加交换分区使用频率增加交换分区的使用频繁，这样使我们的内存程序能够更好的使用交换分区的空间。
echo 60 > /proc/sys/vm/swappiness 3. 编写一个内存代码 munch.c代码的功能是会尽可能多地占用内存，或者达到指定的限制
vim /tmp/munch.c代码内容如下：
#include <stdlib.h>#include <stdio.h>#include <string.h>int main(int argc, char** argv) { int max = -1; int mb = 0; char* buffer; if(argc > 1) max = atoi(argv[1]); while((buffer=malloc(1024*1024)) != NULL && mb != max) { memset(buffer, 0, 1024*1024); mb++; printf("Allocated %d MBn", mb); } return 0;} 4. 编译编译c程序
gcc munch.c -o munch 5. 执行 ./munch 或者./munch 60000这块根据自己的服务器配置来写，我这里让程序去占用60G内存，这样可能用到swap 分区。
6. 查看内存这里建议开启两个终端窗口，一个用来执行代码，一个用来查看内存情况。
free -g可以看到swap分区已经显示正常了。
这里有个注意点，当swap分区显示正常后，如果我们再次关闭交换分区，那个这个异常问题还是会复现，所以在这里就不关闭交换分区了，只是调小交换分区的使用频繁。
总结：在内存急速被占尽的情况下, 由于旧版本 kernel 的函数处理可能会引起该问题的发生, 进而造成 /proc/meminfo 数据信息的异常, 最后导致 free 命令的错误. 如果要杜绝该现象, 需要将 kernel 升级到 kernel-2.6.32-573.7.1 版本. 另外也应该尽量避免运行急速消耗内存的进程.
错误：问题一：
在编译c程序时，报gcc commands not found。
出现以上问题的原因是系统没有安装gcc编译器所以需要安装，可以使用yum源进行安装；
yum -y install gcc+ gcc-c++ 参考： https://blog.arstercz.com/free-%E5%91%BD%E4%BB%A4%E6%98%BE%E7%A4%BA-swap-%E4%BF%A1%E6%81%AF%E5%BC%82%E5%B8%B8%E5%A4%84%E7%90%86/https://www.linuxatemyram.com/play.html