gydtep
发表于 2020-7-27 11:14:00
以在zabbix上面设置了自动化，当检测到ECS1获取不到数据的时候马上操作ECS3标记后端为ECS1的apache为down。保留异常现场。
gydtep
发表于 2020-7-27 14:23:00
关于用lsof打开文件数找到的线索，用lsof -p PID查看进程打开的句柄。直接查看打开的文件。
gydtep
发表于 2020-7-27 15:53:57
可以理解为CPU使用100%，程序无响应外面的tcp请求超时。这是结果，还是没有找到根本原因。
gydtep
发表于 2020-7-27 17:17:43
查看一下ECS2的句柄数，才4000多，排除了业务相关应用对服务器的影响。
gydtep
发表于 2020-7-27 21:52:53
那就只剩下病毒入侵也不是，没有异常进程。考虑到ECS的稳定性问题了。这方面就协助阿里云工程师去排查。
gydtep
发表于 2020-7-28 07:59:25
启动容器的时候又总是“open too many files"。那就是打开文件数的问题，因为CPU的使用率是CPU的使用时间和空闲时间比，有可能因为打开文件数阻塞而导致CPU都在等待。
gydtep
发表于 2020-7-28 10:15:22
接着往下看系统内核日志，发现了和“open too many files”呼应的错误，“file-max limit 65535 reached”意思是，已到达了文件限制瓶颈。这里保持怀疑，继续收集其他信息。
gydtep
发表于 2020-7-28 11:09:17
我就先排除一下业务的影响，把ECS3的nginx直接指向视频ECS2的apache，就等同于在ECS2上实现了ECS1的场景。
gydtep
发表于 2020-7-28 13:14:56
考虑到ECS的稳定性问题了。这方面就协助阿里云工程师去排查。
gydtep
发表于 2020-7-28 14:23:20
因为ECS2的调用ECS1的nfs共享文件，所以lsof也有读不到那么多句柄数的理由。
