Linux下,我们使用ulimit -n 命令可以看到单个进程能够打开的最大文件句柄数量(socket连接也算在里面)。系统默认值1024

    对于一般的应用来说(Apache、系统进程)1024完全足够使用。但是如何象squidmysqljava等单进程处理大量请求的应用来说就有点捉襟见肘了。如果单个进程打开的文件句柄数量超过了系统定义的值,就会提到“too many files open”的错误提示。如何知道当前进程打开了多少个文件句柄呢?下面一段小脚本可以帮你查看:

  1. lsof -n |awk '{print $2}'|sort|uniq -c |sort -nr|more   

在系统访问高峰时间以root用户执行上面的脚本,可能出现的结果如下:

  1. # lsof -n|awk '{print $2}'|sort|uniq -c |sort -nr|more   

  2.     131 24204  

  3.      57 24244  

  4.      57 24231  

  5.      56 24264  

其中第一行是打开的文件句柄数量,第二行是进程号。得到进程号后,我们可以通过ps命令得到进程的详细内容。

  1. ps -aef|grep 24204  

  2. mysql    24204 24162 99 16:15 ?        00:24:25 /usr/sbin/mysqld  

哦,原来是mysql进程打开最多文件句柄数量。但是他目前只打开了131个文件句柄数量,远远底于系统默认值1024

但是如果系统并发特别大,尤其是squid服务器,很有可能会超过1024。这时候就必须要调整系统参数,以适应应用变化。Linux有硬性限制和软性限制。可以通过ulimit来设定这两个参数。方法如下,以root用户运行以下命令:

  1. ulimit -HSn 4096  

以上命令中,H指定了硬性大小,S指定了软性大小,n表示设定单个进程最大的打开文件句柄数量。个人觉得最好不要超过4096,毕竟打开的文件句柄数越多响应时间肯定会越慢。设定句柄数量后,系统重启后,又会恢复默认值。如果想永久保存下来,可以修改.bash_profile文件,可以修改 /etc/profile 把上面命令加到最后。(findsun提出的办法比较合理)

=================================================================================

Too many open files经常在使用linux的时候出现,大多数情况是您的程序没有正常关闭一些资源引起的,所以出现这种情况,请检查io读写,socket通讯等是否正常关闭。

如果检查程序没有问题,那就有可能是linux默认的open files值太小,不能满足当前程序默认值的要求,比如数据库连接池的个数,tomcat请求连接的个数等。。。

查看当前系统open files的默认值,可执行:


  1. [root@pororo script]# ulimit -a   

  2. core file size           (blocks, -c) 0  

  3. data seg size            (kbytes, -d) unlimited   

  4. scheduling priority              (-e) 0  

  5. file size                (blocks, -f) unlimited   

  6. pending signals                  (-i) 128161  

  7. max locked memory        (kbytes, -l) 32  

  8. max memory size          (kbytes, -m) unlimited   

  9. open files                       (-n) 800000  

  10. pipe size             (512 bytes, -p) 8  

  11. POSIX message queues      (bytes, -q) 819200  

  12. real-time priority               (-r) 0  

  13. stack size               (kbytes, -s) 10240  

  14. cpu time                (seconds, -t) unlimited   

  15. max user processes               (-u) 128161  

  16. virtual memory           (kbytes, -v) unlimited   

  17. file locks                       (-x) unlimited  



如果发现open files项比较小,可以按如下方式更改:

1.
检查/proc/sys/fs/file-max文件来确认最大打开文件数已经被正确设置。


  1. # cat /proc/sys/fs/file-max  



如果设置值太小,修改文件/etc/sysctl.conf的变量到合适的值。这样会在每次重启之后生效。 如果设置值够大,跳过这一步。


  1. # echo 2048 > /proc/sys/fs/file-max  



编辑文件/etc/sysctl.conf,插入下行:


  1. fs.file-max = 8192  



2.
/etc/security/limits.conf文件中设置最大打开文件数, 下面是一行提示:


  1. #<domain>   <type>   <item>   <value>  



添加如下这行:


  1. * - nofile 8192  



这行设置了每个用户的默认打开文件数为2048。 注意"nofile"项有两个可能的限制措施。就是<type>项下的hardsoft。 要使修改过得最大打开文件数生效,必须对这两种限制进行设定。 如果使用"-"字符设定<type>, hardsoft设定会同时被设定。

硬限制表明soft限制中所能设定的最大值。 soft限制指的是当前系统生效的设置值。 hard限制值可以被普通用户降低。但是不能增加。 soft限制不能设置的比hard限制更高。 只有root用户才能够增加hard限制值。

当增加文件限制描述,可以简单的把当前值双倍。 例子如下, 如果你要提高默认值1024, 最好提高到2048, 如果还要继续增加, 就需要设置成4096

最后用ulimit -a再次查看,open files的值,没什么问题的话,就已经改过来了。

 

 

 

 

 

 

关于can't identify protocol问题定位

 

问题定位步骤: 
1、 用root帐户 遍历 /proc/进程ID/fd目录,如果该目录下文件数比较大(如果大于10,一般就属于socket泄漏),根据该进程ID,可以确认该进程ID所对应的名称。 
2、 重启程序恢复服务,以便后续查找问题。 
3、 strace 该程序并记录strace信息。strace –p 进程ID >>/tmp/stracelog.log 2>&1 
4、 查看 /proc/进程ID/fd 下的文件数目是否有增加,如果发现有增加,记录上一个socket编号,停止strace 
5、 确认问题代码的位置。打开/tmp/stracelog.log,从尾部向上查找close(socket编号)所在行,可以确认在该次close后再次创建的socket没有关闭,根据socket连接的server ip可以确认问题代码的位置。 

另一种方法:判断是否有socket泄漏: 
lsof | grep "can't identify protocol" 
如果存在很多,则代表socket泄漏,同时会显示哪个进程使用的sock未关闭。