gydtep
发表于 2020-7-27 11:15:13
用htop和top命令监控CPU、内存使用大的进程。先看看哪个进程消耗资源较多,用户态、内核态、内存、IO……同时sar -b查io的历史定时抽样。
gydtep
发表于 2020-7-27 14:24:39
有可能因为打开文件数阻塞而导致CPU都在等待。针对连接数的问题，大不了最后一步试试echo 6553500 > /proc/sys/fs/file-max 测试打开文件对CPU的影响。
gydtep
发表于 2020-7-27 15:55:32
查看进程数量，数量几百。列出来也看到都是熟悉的进程，可以先排除异常进程。
gydtep
发表于 2020-7-27 16:03:20
监控容器的资源使用，里面很不稳定，首先是xunsearch容器使用80%的CPU，关掉xunsearch，又变成了其他容器使用CPU最高。
gydtep
发表于 2020-7-27 17:18:55
不过这个现象有点奇怪，ECS2和ECS1在一样的机房一样的配置一样的网络环境，一样的操作系统，一样的服务，一样的容器，为什么一个有问题，
gydtep
发表于 2020-7-27 17:42:44
一个没问题呢？不同的只是有一台是共享nfs。难道是静态文件共享了，其他人读了，也算是本服务器打开的？
gydtep
发表于 2020-7-27 21:54:18
后来上升到专家排查，专家直接在阿里云后端抓取了coredump文件分析打开的文件是图片，程序是nfsd。
gydtep
发表于 2020-7-28 08:01:15
玩意测出来了消耗CPU的进程，可以使用strace最终程序。用户态的函数调用跟踪用「ltrace」，所以这里我们应该用「strace」-p PID
gydtep
发表于 2020-7-28 10:16:46
监控容器的资源使用，里面很不稳定，首先是xunsearch容器使用80%的CPU，关掉xunsearch，又变成了其他容器使用CPU最高。很大程度上可以排查容器的问题和执行程序的问题。
gydtep
发表于 2020-7-28 11:10:41
那就能下个小结论，ECS1被神秘程序打开了6万多句柄数，打开业务就多了2000多的句柄数，然后就崩溃了。
