Limited Memory

今天在虚拟机里面用Word处理文档的时候,突然硬盘灯一阵狂闪,然后虚拟机就一起消失了。

这种事情屡见不鲜,很明显是Linux内核把占用最多内存的程序(这次是VirtualBox)终止掉了,而硬盘灯为什么会狂闪呢?这是因为在内存用光之前,Linux的pdflush会把dirty pages写回磁盘上腾出内存给其他程序用。这段时间系统几乎处于不可用状态,Annoying! :evil:

oom_killer

默认配置下,当没有内存可以用而又要用到内存时,Linux内核的oom_killer(out of memory killer)会扫描一遍占用内存最多的程序(可能有多个,比如VirtualBox和Firefox一起悲剧),并把它们结束掉。

这种扫描其实代价还是挺大的,可以选择让oom_killer不要扫描出用内存最多的进程,只是解决掉申请内存的那些进程:

sysctl -w vm.oom_kill_allocating_task = 1

使用这样的设置,oom_killer不会去花时间寻找占内存最多的进程杀掉,VirtualBox和Firefox就有一定机会幸免。但是在内存用完的那一瞬间,谁去申请或者使用一片空白的内存,谁就会悲剧,而且可能是几个进程一起被杀掉,充满了不可预测性(比如,Xorg被杀掉,于是许多程序连带就挂掉了,再比如后台的mysqld被杀掉也会带来许多不方便),而且也没有避免pdflush在最后关头让硬盘灯狂闪的情况。

总之,oom_killer很不和谐,最好不要让它出场。在这一点上,openSolaris似乎做的就比较好,从外表上看,在内存不够的时候,系统不会去主动杀掉正在运行的程序,而是拒绝运行新的程序,并且运行中的程序如果申请内存的话就会被暂停,直至有内存可以给它的时候才继续运行。

overcommit

那么系统为什么不能提前检测到内存用完呢,malloc是有可能返回NULL的啊?现在的操作系统中,允许过分地申请内存,如果只是申请内存而没有实际使用的话,可以申请到比实际内存大许多的空间(比如用malloc申请内存,while(1) malloc(x);这样的程序都可以运行好长时间),只有一旦开始用(比如用memset去填),才会计入真正的内存使用,这时候如果内存真的不够了,那么oom_killer就上场了。

目前的Linux提供了一些选项用来调整这种内存策略 :-)

默认情况下,vm.overcommit_memory = 0,这时候可以申请到比较多的内存,但是仍然会在一定的时候申请失败。

还有更宽松一些的,如果 vm.overcommit_memory = 1,所有的malloc都会无条件成功 8-O 相当可怕的世界。

最后一种选择就是这个了:

sysctl -w vm.overcommit_memory = 2

这时候,对申请内存总数有严格的限制,malloc会在超过限制的时候返回NULL,应用程序可以适当处理这种情况,而oom_killer再也不会蹦出来了,pdflush也不会让硬盘转得系统没响应,如果一个程序不能适当处理这种情况,就立即挂掉,干净利落。

但是这也有坏处,这时候参数vm.overcommit_ratio也会起作用,默认是50,意思是只能分配到实际物理内存的50%。如果没有交换区的话,overcommit_ratio设置得小就会很悲剧,几乎什么都做不了。

那把它设置成100,事情就非常和谐了?没有这样简单,这里的限制是申请内存总数的限制,如果申请了却没有实际用到的话,也是计入总数的。这样的话,实际内存没有用完,程序也很有可能申请不到内存,有一些内存就被浪费了。

虽然overcommit_ratio可以被设置成大于100的数,但是到底设置成多少确是个棘手的问题,设置大了,就和没有限制一样,内存用完时硬盘会狂转,系统会失去响应一段时间,oom_killer有可能会上场,设置小了,有可能几百兆的内存被白白浪费了 :-|


检查内存信息可以看到:

% cat /proc/meminfo
MemTotal:        2064616 kB
MemFree:         1556672 kB
....
CommitLimit:     2064616 kB
Committed_AS:     769068 kB
....

其中Committed_AS是程序申请的内存总和,不能超过CommitLimit。很明显地看到Committed_AS+MemFree比MemTotal大,看起来把CommitLimit设置成Committed_AS+MemFree比较合适。

不过这个时候,CommitLimit是只受overcommit_ratio影响的,内存使用状态在动态变化,只好写一个程序来动态修改overcommit_ratio了。

最后我写了这样的一段C的小程序,每一秒设置一次overcommit_ratio。在目前版本的Linux内核(2.6.31)上i686平台可用:

#define _GNU_SOURCE 1
 
#include <unistd .h>
#include <stdio .h>
#include <stdlib .h>
#include <err .h>
#include <errno .h>
#include <string .h>
 
#define errexit(status, info) fprintf(stderr, "%s: %s\n", program_invocation_name, info), exit(status);
 
FILE *fp_meminfo;
 
void set_overcommitted_limit(int value)
{
	char new_value[32];
	int old_len = 0;
	FILE *fp_overcommit_ratio;
 
	if (!(fp_overcommit_ratio = fopen("/proc/sys/vm/overcommit_ratio", "w")))
		err(-4, "can't write /proc/sys/vm/overcommit_ratio");
	fprintf(fp_overcommit_ratio, "%d", value);
 
	fclose(fp_overcommit_ratio);
}
 
int main(int argc, char const* argv[])
{
	char item_name[32];
	int item_value;
 
	int mem_free, mem_total, committed_as, buffers, cached, item_count, i;
 
	char essential_names[][32] = {"MemTotal", "MemFree", "Committed_AS", "Cached"};
	int essential_values[sizeof(essential_names) / sizeof(essential_names[0])];
 
	for(;;sleep(1)) {
		if (!(fp_meminfo = fopen("/proc/meminfo", "r")))
			err(-2, "can't read /proc/meminfo");
 
		for (memset(essential_values, -1, sizeof(essential_values)),
				item_count = sizeof(essential_values) / sizeof(essential_values[0]);
				item_count; ) {
 
			if (feof(fp_meminfo)) errexit(-3, "can't read all essential information");
 
			fscanf(fp_meminfo, " %31[^:]%*[^ ]%d%*[^\n]", item_name, &item_value);
 
			for(i = 0; i < sizeof(essential_values) / sizeof(essential_values[0]); i++) {
				if (essential_values[i] == -1 && 
					strcmp(essential_names[i], item_name) == 0) {
					essential_values[i] = item_value;
					--item_count;
					break;
				}
			}
		}
 
		set_overcommitted_limit(
			(essential_values[1] + essential_values[2] + essential_values[3] / 3)
			* 100 / essential_values[0] + 1);
 
		fclose(fp_meminfo);
	}
 
	return 0;
}

这段程序需要管理员权限运行,把它设置成开机必执行工具之一,同时在/etc/sysctl.conf上加上相关设置,就十分和谐啦 :-P

就这一方面,可能还是openSolaris的做法最和谐,不过仅仅这一点并不能让我投奔openSolaris,把它作为日常使用的系统。默默地期待openSolaris和Linux都越来越好吧~

6 thoughts on “Limited Memory

Leave a Reply to hzqtc Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>