阿里云服务器CPU 100%问题

笨比master

已于 2024-02-14 15:15:34 修改

阅读量1.1k

点赞数 24

文章标签：阿里云服务器云计算

于 2024-02-14 15:14:28 首次发布

本文链接：https://blog.csdn.net/m0_37454852/article/details/136113525

版权

原创内容，未经同意，请勿转发，原文地址：
复制到CSDN，图片链接失效，建议直接访问原站：哇塞码农网

1、问题描述

最近趁着阿里云服务器搞活动买了几年的阿里云服务器，2c2g的配置，用于本站（哇塞码农）的部署和运维

之前是部署在bandwagon的服务器上，但价格比较贵，而且也存在不可描述的风险，这里的配置是1c1g

明明阿里云服务器的配置更高，但是部署到阿里云之后反而出问题了，经常部署之后运行两三天服务器cpu利用率就会100%，磁盘读也很高，服务直接不可用，网站也无法正常访问了

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

2、排查过程

2.1、工单提问

2.1.1、事后排查工具atop

由于问题出现后便无法远程登录，只能重启。但重启只能临时解决，过段时间后便会再次出现。

于是，我先找到了阿里云的技术支持（题外话，阿里系的客服还是可以的），询问有没有办法事后排查问题原因的办法。阿里云的技术支持推荐使用atop：

您好，您这边可以使用atop工具监控系统资源使用情况：https://help.aliyun.com/zh/ecs/how-to-use-the-linux-system-atop-monitoring-tools?spm=a2c4g.11186623.0.i6 后续可以通过atop日志分析下占用资源的进程

在按照阿里云的atop文档安装完毕后，便只能静静等待问题再次出现了……

注意，若各位遇到类似的情况，不要强制重启服务器，强制重启服务器会导致atop的日志文件丢失！

2.1.2、罪魁祸首kswapd0

终于，在下次问题出现时，根据atop的日志，排查到了罪魁祸首：kswapd0进程！

新图片

来自chatGPT的kswapd0简介：

kswapd0是Linux系统中的一个内核线程，它的作用是在系统内存不足时执行页面交换（swap）操作。当系统的物理内存不足以满足当前运行程序的需求时，Linux内核会将部分不常用的内存页面（页）移到交换空间（swap space）中，以释放物理内存供其他程序使用。kswapd0负责管理这些页面交换的过程，包括选择哪些页面需要被换出、将页面写入交换空间、以及从交换空间中换入页面等操作，以确保系统内存的有效利用和性能稳定。

kswapd0通常在系统空闲时运行，其优先级相对较低，以免影响到正在执行的其他重要任务。在系统负载较低且内存充足时，kswapd0可能处于睡眠状态，只有在内存压力增加时才会被唤醒执行页面交换操作。

在发现是系统进程时，我先是再次找到阿里云的技术支持，询问是否是机器或系统有问题，但是回复是内存太小，java应用比较吃内存，建议我升级内存配置……

我大为震惊，为什么搬瓦工1c1g都没有这个问题，阿里云2c2g却有问题？无奈，不再寄希望于阿里云官方，只能自己排查原因了

2.2、kswapd0病毒疑云

百度kswapd0占用cpu利用率过高，很多中文网站都在说kswapd0病毒的问题，吓得我按他们一些文章查了下，但是并没有发现他们说的问题……

2.3、内存泄漏分析

继续往下排查，难道是迁移后对java应用做了一些改造出现内存泄漏了？

于是又按照排查内存泄漏的思路进行排查，但仍旧一无所获！我的应用并没有明显的内存泄漏情况

full GC情况都很正常，内存泄漏分析工具分析出来的结果也是正常的

下面也列举一下排查gc和内存泄漏的方法，各位如果需要也可以按这个思路查一下：

2.3.1、gc情况查询

使用 jstat 命令查看垃圾回收的统计信息，例如：

docker exec -it <container-id-or-name> jstat -gc <pid>

这些信息包括不同区域（S0、S1、EC、OC等）的容量（C：容量，U：已使用），垃圾回收的次数（YGC：Young GC次数，FGC：Full GC次数，CGC：Compacting GC次数）以及相应的时间和耗时等。

下面是对一些关键字段的解释：

S0C 和 S1C：S0和S1区的容量（Capacity）。
S0U 和 S1U：S0和S1区的已使用（Used）空间。
EC 和 EU：Eden区的容量和已使用空间。
OC 和 OU：Old区（老年代）的容量和已使用空间。
MC 和 MU：元空间（Metaspace）的容量和已使用空间。
CCSC 和 CCSU：压缩类空间的容量和已使用空间。
YGCT：Young垃圾回收的总时间（秒）。
FGC 和 FGCT：Full垃圾回收的次数和总时间。
CGC 和 CGCT：压缩垃圾回收的次数和总时间。
GCT：总的垃圾回收时间。

2.3.2、内存泄漏分析

使用 jcmd 和 jmap

连接到运行中的Java进程，并使用 **jcmd 或 jmap 生成堆转储文件

我这里使用了docker，没有用docker请酌情修改：

bashCopy code
docker exec -it <container-id-or-name> jcmd <pid> GC.heap_dump /path/to/dump.hprof

**替换 ** 为您的容器ID或名称，为Java进程的ID。这将在容器中生成堆转储文件。

之后将dump.hprof文件保存到本地，借助于分析java dump文件的工具分析

我这里用到了Memory Analyzer (Eclipse MAT)，分析后的结果可以参考：

新图片

2.4、内存太小？

折腾了一番之后，并没有发现问题原因。

于是，我回到最初的问题，阿里云技术支持说是内存太小了

并且，kswapd0是处理内存交换的进程，但是我这台阿里云服务器好像没有开启内存交换；而我之前用的搬瓦工是开了内存交换区的

难道是因为内存耗尽，并且没有开交换区，导致服务器kswapd0进程频繁读写磁盘，cpu利用率变高的吗？

想到这，我倒吸一口冷气🥶开干！我玩的就是真实！😡

2.4.1、开启交换区

开启交换区可以参考阿里云文档：

https://help.aliyun.com/zh/ecs/how-do-i-configure-a-swap-partition-on-a-linux-instance-and-resolve-frequently-asked-questions?spm=a2c6h.14164896.0.0.798447c52MTB5u&scm=20140722.S_help@@%E6%96%87%E6%A1%A3@@42534._.ID_help@@%E6%96%87%E6%A1%A3@@42534-RL_swap-LOC_llm-OR_ser-V_3-RE_new2-P0_0

部分参数本文做一些简单的补充说明：

dd if=/dev/zero of=/mnt/swap bs=1M count=4096

这些参数是 Linux 内核的一些系统调整参数，用于配置系统的行为。以下是每个参数的简要说明：