Linux服务器中线程、CPU、内存、硬盘等资源占用100%时的问题分析及解决措施
- 1.线程爆满，出现“没有子进程”的错误
- 问题描述
- 问题分析
- 问题定位
- 2.CPU爆满，100%爆红
- 问题描述
- 问题分析
- 解决方案
- 3.内存爆满，100%爆红
- 问题描述
- 问题定位
- 问题分析
- 4.磁盘爆满，100%爆红
- 问题描述
- 问题分析
- 解决方案
1.线程爆满，出现“没有子进程”的错误
问题描述
在演示环境中，服务运行一段时间后，出现“没有子进程”的错误，ssh也无法登录，服务奔溃，演示环境不可用。
-bash: fork: retry: 没有子进程
-bash: fork: retry: 资源暂时不可用
问题分析
出现该问题肯定是线程数量被占满了，导致服务器没有资源可用了，应该分析每个进程所占用的线程数，以及线程增长速度。
问题定位
1.使用“ulimit -a”命令查看本机的线程数有多少，其中“max user processes”表示最大线程数；
root@linx:~# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 257234
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 257234
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
2.查看当前总的的线程数，发现跟线程的总限额数很接近；
root@linx:/platform# ps -xH | wc -l
257230
3.使用命令查看线程数总量在前五的进程，发现进程“3055”的线程数量明显不合理；
root@linx:/platform# ps -xH | awk '{x[$1]++;} END{for(i in x) print(i ":" x[i])}' | sort -n -k 2 -t : -r | head -n 5
3055:80393
1469:2860
12305:1511
12306:1395
20126:1368
4.确认PID为“3055”的线程数量；
root@linx:/platform# pstree -p 3055 | wc -l
80392
5.确认PID为“3055”是Docker运行的的网关服务；
root@linx:/platform# docker inspect -f "{{.Id}} {{.State.Pid}} {{.Name}}" $(docker ps -q) | grep 3055
dc8ce63a2457ab2090ead648aea0939573a6b10bccd785341058bd2e8bb43c17 3055 /gateserver-gateserver-1
6.确认是统一网关日志模块有线程泄露。
2.CPU爆满，100%爆红
问题描述
docker中全部服务启动时，10多分钟的时间内，CPU占用都是100%
问题分析
多发于在机器刚启动时，全部服务都因为docker自启动的原因同时启动，导致CPU占用100%。
原因是因为服务存在一条较长的依赖链，MySQL->Nacos->众多应用服务
在服务器刚启动时，因为大量服务同时启动，共同挤占了CPU资源，因此所有服务启动的都很缓慢
但一般情况下MySQL都能成功启动，但Nacos却不会，这是因为为了保证Nacos健康状态，通常会对Nacos设置健康检查，但又由于众多服务同时与Nacos抢资源，导致Nacos无法在健康检查期限内成功启动，Nacos无法启动又导致众多服务无法正常启动，从而不断重启，从而形成了死循环
解决方案
Nacos设置健康检查时长加长一点，避免还没给够时长正常启动就又重启了；
为每个应用服务设置启动状态检测，即等待Nacos正常后才启动。
3.内存爆满，100%爆红
问题描述
系统内存使用情况很高，如下命令输出所示：
# uptime
23:42:48 up 34 days, 13:21, 12 users, load average: 0.52, 0.75, 0.85
# free -h
total used free shared buff/cache available
Mem: 15Gi 12Gi 541Mi 1.1Gi 2.6Gi 1.7Gi
Swap: 29Gi 11Gi 18Gi
# top
top - 23:45:16 up 34 days, 13:24, 12 users, load average: 0.59, 0.68, 0.81
Tasks: 638 total, 2 running, 634 sleeping, 0 stopped, 2 zombie
%Cpu0 : 10.8 us, 3.3 sy, 0.0 ni, 83.0 id, 0.3 wa, 0.0 hi, 2.6 si, 0.0 st
%Cpu1 : 8.9 us, 4.0 sy, 0.0 ni, 85.5 id, 0.3 wa, 0.0 hi, 1.3 si, 0.0 st
%Cpu2 : 13.1 us, 2.9 sy, 0.0 ni, 82.7 id, 0.3 wa, 0.0 hi, 1.0 si, 0.0 st
%Cpu3 : 8.2 us, 3.6 sy, 0.0 ni, 87.3 id, 0.0 wa, 0.0 hi, 1.0 si, 0.0 st
MiB Mem : 15731.1 total, 529.8 free, 12563.0 used, 2638.3 buff/cache
MiB Swap: 30720.0 total, 19096.5 free, 11623.5 used. 1740.3 avail Mem
...
物理内存 16G 占用，SWAP 额外占用 11G 空间，排查内存系统使用情况，分析各个进程的内存占用情况。
问题定位
查找进程id:top -d 2 -c ,按Shift+M 来按照 %MEM 排序 以快速定位使用内存较多的进程
问题分析
1.查看JVM堆内存分配情况：jmap -heap pid(进程号)
2.查看占用内存比较多的对象: jmap -histo pid(进程号) | head -n 100
3.查看占用内存比较多的存活对象: jmap -histo:live pid(进程号) | head -n 100
4.磁盘爆满，100%爆红
问题描述
使用Docker运行服务相当长的一段时间后，出现硬盘占用超高，接近100%；
root@linx:~# df -h
文件系统 容量 已用 可用 已用% 挂载点
udev 10M 0 10M 0% /dev
tmpfs 3.2G 9.2M 3.2G 1% /run
/dev/sda2 901G 841G 14G 98% /
tmpfs 7.8G 0 7.8G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
/dev/sda1 511M 132K 511M 1% /boot/efi
tmpfs 1.6G 4.0K 1.6G 1% /run/user/119
overlay 901G 841G 14G 98% /var/lib/docker/overlay2/27076d0555ead7c7abd5bb45f058cc90af445bb8a95382ab61da5f6385729be3/merged
overlay 901G 841G 14G 98% /var/lib/docker/overlay2/691497cefac43dd117ec0e15c29cbf50de409244f70381978536f509f6169503/merged
overlay 901G 841G 14G 98% /var/lib/docker/overlay2/25d353358b213494c82a6bb7a5e179240b7804671755e3104c6093dd6dea0c31/merged
overlay 901G 841G 14G 98% /var/lib/docker/overlay2/8b775567d3ed5ab15282cd5f4b679bca400fa08c8f02728be761935eb4fb9c5b/merged
问题分析
出现这种问题一般是Docker日志或者业务日志未加限制、Docker镜像或者Exited状态的容器太多、业务数据量占用过大这几种情况。
解决方案
根据原因不同可以分为以下几种方式：
1.Docker的日志限制问题；
yuntu@node-01:~$ cat /etc/docker/daemon.json
{
"registry-mirrors": ["https://tjjv3zyc.mirror.aliyuncs.com"],
"exec-opts": ["native.cgroupdriver=systemd"],
"insecure-registries":["https://docker.ut.cn","https://docker.utpf.cn"],
"graph":"/yuntu/docker",
"log-driver":"json-file",
"log-opts": {"max-size":"500m", "max-file":"3"}
}
如果以上输出中没有”log-driver”、”log-opts”选项，则需要补充到daemon.json文件中，且需要重启Docker生效；
yuntu@node-01:~$ sudo systemctl daemon-reload
yuntu@node-01:~$ sudo systemctl restart docker
2.业务日志限制问题；
在Nacos中找到logback-common.properties配置，并且添加相应的限制配置。
3.Docker镜像或者Exited状态的容器太多
使用命令清理无用的镜像或容器；
root@linx:~# docker system prune -a
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all images without at least one container associated to them
- all build cache
Are you sure you want to continue? [y/N] y
4.业务数据量过大；
在业务数据必须保留的情况下，只能通过增加硬盘来解决。
参考文章：
CPU、内存打满排查流程、JVMGC调优
