文章目录
前言
今天发现有台服务swap分区数据显示异常,使用free -g
命令查看内存使用情况,swap 的 used 远远超过 swap total 的值, free 的值也大于 total, 如下所示:
[root@dx-selk00 ~]# free -g
total used free shared buffers cached
Mem: 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 %10Lu\n", "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 the
swap_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 MB\n", mb);
}
return 0;
}
4. 编译
编译c程序
gcc munch.c -o munch
5. 执行
./munch
或者
./munch 60000
这块根据自己的服务器配置来写,我这里让程序去占用60G内存,这样可能用到swap 分区。
6. 查看内存
这里建议开启两个终端窗口,一个用来执行代码,一个用来查看内存情况。
free -g
可以看到swap分区已经显示正常了。
7. 修改交换分区使用频率
echo 1 > /proc/sys/vm/swappiness
这里有个注意点,当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