sudo sysctl -p
这样就修改完毕了，用户级句柄数的修改需要重启一下才能生效，最好执行一下reboot，再次输入ulimit -n查看已经修改好了。
linux系统中对进程可以调用的文件句柄数进行了限制，超过限制进程将无法获取新的句柄，不能打开新的文件或者网络套接字，就会报错。
通过命令：
lsof -p 进程id|wc -l ：查询当前进程打开文件的数量
发现这个数量是在不断增加的，通过
lsof -p 进程id：查询当前进程打开的具体文件
TYPE类型为FIFO的文件在不断增
文章目录一、背景二、第一波排查1、 问题持续时间2、 错误日志3、tcp连接数4、 分析5、结论三、第二波排查1、分析2、结论3、解决四、参考文献
2020-03-23 08:10:07生产突然系统异常。
在系统重新之后恢复暂时恢复使用。一个比较诡异的错误，经过一番排查，最终才定位到问题代码，错误如下：
2020-03-20 08:10:07.039 [http-nio-80...
出现问题的原因：
1.可能是程序打开文件没有使用close()方法关闭打开的流，导致程序一直占用
2.可能是服务器允许每个用户打开文件的最大数量有限制（这种在文件使用关闭后，打开数量会降低）
针对第二种的处理方法：
ps -ef|grep java 查看端口
lsof -p 端口 | wc -l 查看此端口打开的文件数量
ulimit -a 查看允许每个用户打开文件的最大数量
ulimit -n 4096 修改最大数量
ps:open files (-n) 1024这个参数就是系统默认允许用户打开文件最
记录一下通知平台mnp在客户环境的报错：
问题背景：客户端发送9007通知，mnp微服务处理通知状态正常的流程是：未报-->待报-->发送失败/发送成功,而本次实际上的结果是走到待报就结束了流程。
经排查发现日志有下图报错：
报错分析：
java.io.IOException：Too many open files,IO异常，打开的文件数过多。原因是因为 操作系统的中打开文件的最大句柄数受限所致，常常发生在很多个并发用户访问服务器的时候.因为为了执行每个用户的应用服务器都要加载很多文
