打开文件过多

 

问题现象：

日志出现大量“打开文件过多”异常信息

 

问题分析：

通过网上查询，发现是由于系统参数设置问题造成，因为应用并发量大，http连接多了，随之socket的消耗也多了，socket文件描述符也是Linux系统文件描述符的一种，Linux操作系统对此也有限制，所以需要调大参数fs.max-file和/etc/security /limits.conf的soft nofile和hard nofile值

 

解决方案：

通过设置以上参数，加大数值，重启应用。

 

问题再现：

设置了以上参数后，还以为问题可以解决，但是一段时间过后，问题继续出现。

 

问题分析：

通过对各服务器检测以上参数值发现有些服务器的设置不生效，回想当时设置后检查是发现生效的，但为什么忽然又一些服务器又不生效了。

 

问题思考：

现在的问题已经不是应用层上的问题，是操作系统级别的问题，测试发现，ssh登陆ulimit -n查询limit.conf不生效，但su登陆，limit.conf生效。

 

问题发现：

通过对Linux的一些学习，原来limit.conf配置文件是Linux PAM(插入式认证模块,Pluggable Authentication Modules)中 pam_limits.so 的配置文件。具体如何生效，还得看PAM如何配置。

 

继续研究：

应用进程的最大文件打开数是否跟当前会话的limit.conf参数值有关？如果通过ssh登陆启动应用是否跟ssh登陆会话时候额最大文件打开数有关，而su登陆启动应用，此时的应用进程是否就会跟当前的最大文件打开数关联，文件得到答复，写了一小段C代码测试：

#include<stdio.h>
#include <unistd.h>
#include<stdlib.h>
#include<sys/resource.h>
 
main()
{
        struct rlimit limit;
        while(1){
               getrlimit(RLIMIT_NOFILE,&limit);
                printf("the process canopen %d files\n",limit.rlim_cur);
                sleep(2);
        }
}

这块代码是通过打印当前进程最大的文件打开书。经过测试，su进去的用户打开进程，打印的确实是limit.conf设置的值，而通过ssh进去执行这代码打印的却是修改limit.conf参数前的值（就是limit.conf没有生效）。这可能跟linux系统的进程、用户会话方面有关系，因为知识面窄，所以在论坛上提问了一下，网友就给了我我这样一个连接：http://linux.die.net/man/8/pam_limits。原文有这样一句话：“The pam_limitsPAM module sets limits on the system resources that can be obtained in auser-session. Users of uid=0 are affected by this limits, too.”这个pam_limits PAM在用户会话上有效，对0号进程（内核进程）也有是有效的。

 

关联疑问：

我们平时的操作时都是通过终端去操作的，开启进程的父进程都是当前终端进程，例如ssh，但有一些进程是在后台运行的。当开启了后，关闭终端，那他们归属谁呢？通过观察发现。这些孤独的进程都是被1号进程接收了。这里可能就涉及到linux进程管理的问题了。暂不再深入研究。

 

我想到了一种情况，如果我用ssh进去开启进程，这父进程的ID是我这ssh进程。当我退出ssh后，那个子进程没有关闭就归1号进程管了（例如我们常见的java进程）。那这个子进程的最大文件打开数会不会就变回limit.conf文件设置的值呢？因为ssh进程进去的值是limit.conf修改前的值。ssh进去开启我那测试进程打印的确实是跟当前的limit.conf值不一样，就是没有生效。我又在网上找到了一个方法，直接把那测试代码的子进程直接赋予给1号进程：setsid。经过测试，打印出来的最大文件打开数没变。就像上面说的这个PAM设置跟用户会话有关系。

 

测试over。以后发现有问题，继续跟进。