CPU负载高告警问题的定位与优化建议
#作者:猎人
文章目录
- 背景
- 一.问题排查
- 1.1 找到相应的容器
- 1.2 找到对应的deployment
- 1.3 查看pod日志
- 1.4 查看nginx配置文件
- 1.5 查看deployment的yaml文件
- 二.优化建议
背景
Docker 版本:19.03.14
Operating System: Red Hat Enterprise Linux Server 7.9 (Maipo)
内核版本: Linux 5.12.9-1.el7.elrepo.x86_64
内存:252G
CPU逻辑核心数:30
问题:k8s集群一个节点192.x.x.x CPU负载高告警
原因:某省生产核心业务nginx 容器内存限制过低导致nginx进程在重启。
解决简介:
- 登陆某省生产核心业务节点192.x.x.x节点, 用top命令查看,发现CPU前一分钟,5分钟,15分钟负载高。
- 通过top 输出结果看到最前面的是nginx进程,但此节点宿主机上没有部署二进制的NGINX,因此怀疑这个进程是以容器的形式运行的。
- 通过遍历该节点上所有的容器,找到容器的PID和上面nginx一样的pid,输出容器的名称
- 根据容器的名称的前面的一部分,通过在master节点过滤,找到对应的deployment.
- 根据deployment的pod的日志和yaml文件,找到问题原因。
一.问题排查
登陆到CPU负载高的节点192.x.x.x,通过top命令查看:
查看到大多数都是nginx占用的CPU资源。
当前节点的CPU是30核心:
通常对于CPU单核心的负载,超过0.8就认为负载很高了,因此对于30核心的CPU,30*0.8=24 ,超过24就负载很高了,而通过上面的top命令我们看到前1,5,15分钟负载都超过了50了,因此,情况特别严重,需要排查定位。
1.1 找到相应的容器
在宿主机上没有找到二进制部署的nginx ,因此我们怀疑是这个NGINX进程应该是以容器的形式启动的。
通过命令遍历节点上的所有的容器:
docker ps -a -q |xargs docker inspect -f "{{.State.Pid}} {{.Config.Hostname}} {{.Id}} " |grep 59295
找到容器的名称为: xtag-ui-7df9c4d5f7-lcfsq
通过在节点192.195.5.179上执行: dmesg |grep nginx
也看到好多关于nginx的信息,报 Memory cgroup out of memory: Killed process 497 (nginx) total-vm:108656kB, anon-rss:31816kB, file-rss:1848kB, shmem-rss:0kB, UID:18345 pgtables:228kB oom_score_adj:999
[33114127.374677] oom_reaper: reaped process 497 (nginx), now anon-rss:0kB, file-rss:0kB, shmem-rss:4kB
[33114127.379830] Memory cgroup out of memory: Killed process 500 (nginx) total-vm:108656kB, anon-rss:31644kB, file-rss:1588kB, shmem-rss:0kB, UID:18345 pgtables:228kB oom_score_adj:999
[33114127.386208] oom_reaper: reaped process 500 (nginx), now anon-rss:0kB, file-rss:0kB, shmem-rss:4kB
[33114127.392363] Memory cgroup out of memory: Killed process 503 (nginx) total-vm:108656kB, anon-rss:31712kB, file-rss:1588kB, shmem-rss:0kB, UID:18345 pgtables:228kB oom_score_adj:999
可以看到NGINX 内存溢出,不断的杀掉进程,启动新的进程,这样频繁不断的杀掉老的进程,启动新的进程,将会导致CPU的负载飙升。
1.2 找到对应的deployment
通过在master节点上:
kubectl get pod -A -o wide|grep xtag
1.3 查看pod日志
查看pod日志有报错:
1.4 查看nginx配置文件
进入容器里面查看NGINX的配置文件,线程数和CPU核心数一样多:worker_connections 65535;
1.5 查看deployment的yaml文件
查看deployment的 yaml 文件:
内存最大限制为512M:
把内存修改为4G后,新的pod调度到其他节点上,调度到新节点的CPU负载正常。原来所在的节点CPU负载也降了下来,一切恢复正常。
二.优化建议
- NGINX的内存不能给的太少,内存太少,会导致内存溢出,导致CPU负载高
- 查看NGINX的配置文件,线程数和CPU核心数一样,导致对主机CPU的负载高,建议增加对CPU的限制。