zoukankan      html  css  js  c++  java
  • too many open files linux服务器 golang java

    1. 现象

    服务的cpu跑满(golang实现), 并大量报too many open files错误.服务使用systemd来运行,部署在阿里ecs.

     

    2.分析

    从日志来看,cpu的上升主要为到达文件数限制引起的,但之前已经更改过系统的文件数及所有用户的文件数,按道理是不应该出现这个问题的,后来查阅资料发现,文件数可以从三个维度限制分别为操作系统限制,用户态限制,以及进程限制,对于这三个维度选取最小值生效.于是对系统进行分析.

     

    首先查看当前打开文件数, 进程占用的文件数并不多.

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



    然后获取系统级文件数限制

    输入命令

    cat /etc/sysctl.conf

    得到

    fs.file-max = 1000000

    查询用户级文件数限制

    cat /etc/security/limits.conf

    得到

    * soft nofile 655350

    * hard nofile 655350

    单独获取程序文件数限制(9928为进程id)

    cat /proc/9928/limits

    得到

    Max open files            1024                 4096                 files    

    如上可以发现, 虽然系统及用户的文件数调大了,但是程序的仍然是一个很低的值, 这里进程的文件数一般情况下是默认继承用户级的值的,而这里却没有继承,一开始怀疑是systemd启动的问题,但是手写了另外一个测试服务,发现该服务又继承了用户文件数.

    百思不得其解的情况下在systemd的启动脚本里加了文件数的初始化值.

     如下:

    [Service]

    Type=simple

    LimitNOFILE=40960

    LimitNPROC=40960

      

    单独获取程序(9928为进程id)

    cat /proc/9928/limits

    得到

    Max open files            40960                 40960                 files    



    发现文件数被设置成了启动时的初始化值.至于为什么没有继承用户级的值,怀疑是程序里做了参数设置,这里如果有人知道golang里具体情况的话,还望不吝赐教.

     

    3. 总结

    归结来说出现文件描述符的错误的排查步骤如下:

    首先,判断配置参数是否正确,这里涉及到对上面提到的三个维度的检查,特别时进程维度的,如果只是ulimit -n 一下就完事了,那估计旧要像我一样进坑了.

    如果参数都正确,那么查看一下当前系统被使用了多少文件数,如果使用的确实多,那要看一下使用在什么地方,这里一般有两种情况,大量连接未关闭,或者大量读文件的句柄未关闭.具体原因相信到这里就可以排查出来了.

     

  • 相关阅读:
    【Windows socket+IP+UDP+TCP】网络基础
    【我所认知的BIOS】—> uEFI AHCI Driver(8) — Pci.Read()
    Unity3D十款最火的的插件推荐
    静态路由解决双外卡,PC做路由器的实现
    00096_Properties类
    TensorFlow2_200729系列---4、手写数字识别理论
    损失函数基础知识总结
    为什么选择onehot编码(总结)
    TensorFlow2_200729系列---3、梯度下降求简单线性回归实例
    numpy生成随机数据实例
  • 原文地址:https://www.cnblogs.com/zhangboyu/p/7452738.html
Copyright © 2011-2022 走看看