ulimit最初设计是用来限制进程对资源的使用情况的，因为早期的系统系统资源包括内存,CPU都是非常有限的，系统要保持公平，就要限制大家的使用，以达到一个相对公平的环境。以下是典型的机器默认的限制情况:
| core file size (blocks, -c) 0 |
| data seg size (kbytes, -d) unlimited |
| scheduling priority (-e) 0 |
| file size (blocks, -f) unlimited |
| pending signals (-i) 204800 |
| max locked memory (kbytes, -l) 32 |
| max memory size (kbytes, -m) unlimited |
| pipe size (512 bytes, -p) 8 |
| POSIX message queues (bytes, -q) 819200 |
| real-time priority (-r) 0 |
| stack size (kbytes, -s) 10240 |
| cpu time (seconds, -t) unlimited |
| max user processes (-u) 204800 |
| virtual memory (kbytes, -v) unlimited |
| file locks (-x) unlimited |
但是很多年过去了，情况发生变化了，硬件在过去的时间里面发展的非常迅猛，一个拥有几十个核心的，上百G内存的机器差不多也是白菜价格了。但是软件的限制还是没怎么发生变化，导致一系列使用的问题。其中很重要的文件句柄使用限制尤为明显。
特别是类似web服务器，数据库程序等需要大量的文件句柄，一旦开太小，比如默认(1024),在句柄使用完毕的时候，系统就频繁出现emfile错误
，这时候系统很容易陷入不可用。但是如果设定太大了，又会有这样的副作用。很多服务器程序是事件派遣的，比如说用epoll，程序在启动的时候通常会根据最大的文件句柄数来预留内部的slot，比如说Erlang一个slot貌似要占用几K的资源，如果你设定文件句柄数目太大，就可能无端的浪费了几百M内存。所以要正视这个问题，设定一个合适的值。
通常我们是在shell下用来ulimit -n NNNN来设定新开的进程的文件句柄的限制，但是在一个生产环境下会有如下麻烦：
| -bash: ulimit: open files: cannot modify limit: Operation not permitted |
| $ sudo ulimit -n 22222222 |
| sudo: ulimit: command not found |
JulyClyde(julyclyde@gmail.com)同学介绍解释了这个问题：
shell里不能直接更改，是因为登录的时候pam已经从limits.conf中设置了上限，ulimit命令只能在低于上限的范围内发挥了。
这时候我们通常需要修改/etc/security/limits.conf
修改后，重现登录shell, 用ulimit -Hn和ulimit -Sn确认修改已生效.
另外说：
在linux kernel 2.6.25之前通过ulimit -n(setrlimit(RLIMIT_NOFILE))设置每个进程的最大打开文件句柄数不能超过NR_OPEN (1024*1024),也就是100多w(除非重新编译内核)，而在25之后，内核导出了一个sys接口可以修改这个最大值(/proc/sys/fs /nr_open).具体的changelog在
直接在你自己的程序里面绕开文件句柄的限制。
祝大家玩得开心！
Related posts:
- Linux文件预读分析以及评估对系统的影响
- 突破systemtap脚本对资源使用的限制
- 如何查看节点的可用句柄数目和已用句柄数
- Linux下新系统调用sync_file_range
- leveldb性能分析和表现
阅读(546) | 评论(0) | 转发(0) |
