有关ulimit,精华区的帖子不能解决我的疑惑

babizhu

我写了一个应用程序，维持着客户端可能千于个客户端，最近发现日志文件里面出现这样的错误，首先文件不能被open了，然后accept返回“Too many open files”

我用ulimit -a，看到open files是1024

那么事情就有两个可能，第一我打开了超过1024个文件没有close，但是我想我打开的文件数量应该没有那么多。

另外还有一种可能就是每个保持连接的客户端都算一个open 的file.这样，我就只能调整open files的数量对不对？

可是我用非root身份调用ulimit -n 2048，系统告诉我这个操作是不被允许的。用root调整呢又只能调整root自己的。

那么请大家指教一下，我得问题出在哪儿，又应该怎么办呢？

另外还有个疑问open files是1024指的是某个用户一个进程可以打开的文件数呢，还是某个用户所有的进程总共可以打开的文件数

另外有人告诉我，缺省情况下linux一个进程最多只允许打开1024个socket，不知道对否？

kj501

如果你用的是linux，1024是一个进程能够打开的最大文件数量，这是由内核限制的，不可能靠ulimit来修改它。由于unix/linux的文件范围很广，不仅仅是指一般的文件，而且包括目录，管道，socket，特殊设备文件等等，所有打开的这些文件的总和超过1024，就会出现错误。你可以到/proc目录下看看这些打开的文件到底是什么。

babizhu

楼上能说得详细一点吗？？比如到proc下面怎么察看打开的文件是什么

kj501

先用ps找出进程的pid，然后到/proc下对应的目录中有一个fd子目录，进去后用ls -l 就可以看到第个文件描述符连接到具体那个文件。

babizhu

非常感谢楼上，我已经看到了，问题是，这样一来，某个进程允许同时在线的最高客户端不是就限定在1024（其实还不到1024）上了嘛？
不能够修改？

superhoo

可以修改的
通过修改/proc/sys/fs/file-max文件可以实现

babizhu

多谢楼上回复，我查看了一下我得/proc/sys/fs/file-max，里面只有一行，内容为104587，这个数字意味着什么？这就是用户可以打开的最大文件数嘛？好像和ulimit -a看到的差距很大啊？

kj501

这个/proc/sys/fs/file-max应该是整个内核能够打开的文件总数。不是单个进程的。打开文件也是要消耗掉一定的内核资源的。即使单个文件没有达到1024的上限，所有进程打开的文件总数加起来超过file-max也会导致无法再打开新文件。

babizhu

如果，这是整个内核能打开的文件总数，那么当进程a不能打开新的句柄的同时，进程b也应该不能吧。
但是，当时的情况仅仅是a出现了这个问题。所以，我想这应该不是问题的关键。可能还是某个进程本身打开的文件数超过了所能允许的最大值，那么应该如何修改呢？

lllll

set rlim_fd_max=4096   
一个进程可以打开文件描述符的“硬”限制,该数目由当前运行的SHELL决定：ulimit –Sn，还可以通过setrlimit()函数来修改这个参数；不需要超级用户权限；  
The predicate rlim_fd_cur <= rlim_fd_max must be fulfilled

set rlim_fd_cur=1024       
一个进程可以打开文件描述符的“软”限制如果想改变该限制，必须有超级用户的权限
对于大多数SERVER，不管使用TCP还是UDP进行通讯，最大描述符数是每个用户进程的最重要的参数；文件描述符决定了同时可以连接的数目；   
ulimit -Hn   
You should consider a value of at least 2 * tcp_conn_req_max and you should provide at least 2 * rlim_fd_cur. The predicate rlim_fd_cur <=  rlim_fd_max must be fulfilled