【原创】CPU 100%+磁盘写满 问题排查

最新推荐文章于 2024-05-09 09:34:25 发布
最新推荐文章于 2024-05-09 09:34:25 发布
阅读量572 收藏
点赞数
文章标签： 运维 操作系统 python
原文链接：https://my.oschina.net/moooofly/blog/418710
版权

2019独角兽企业重金招聘Python工程师标准>>> hot3.png

情景：测试人员在进行 RabbitMQ 服务器问题排查时，进行了各种重启操作，之后突然发现机器变的很卡。
排查过程：
1. 通过 top 查看，发现名为 sa 的进程 CPU 占用率几乎 100% 。
2. 查看 sa 进程中哪个线程占用 CPU 比较高

[root@rmq_2 ~]# top -Hp 1362
top - 05:36:26 up 2 days,  3:08,  2 users,  load average: 1.77, 3.69, 5.11
Tasks:  16 total,   0 running,  16 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.4%us,  2.8%sy,  0.0%ni, 95.7%id,  0.0%wa,  1.1%hi,  0.0%si,  0.0%st
Cpu1  :  0.4%us, 14.7%sy,  0.0%ni, 29.4%id, 53.8%wa,  0.0%hi,  1.8%si,  0.0%st
Cpu2  :  0.7%us,  2.1%sy,  0.0%ni, 95.9%id,  0.0%wa,  0.0%hi,  1.4%si,  0.0%st
Cpu3  :  0.3%us,  5.8%sy,  0.0%ni, 77.1%id, 16.4%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   3924376k total,  3775972k used,   148404k free,   143432k buffers
Swap:  2097144k total,   688428k used,  1408716k free,   883568k cached


  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1532 root      20   0 83964  37m 1196 D 94.7  1.0 127:59.46 MQProducerTask
 1497 root      20   0 83964  37m 1196 S  0.3  1.0   3:22.10 OspTimerTask
 1362 root      20   0 83964  37m 1196 S  0.0  1.0   0:03.41 sa
 1495 root      20   0 83964  37m 1196 S  0.0  1.0   0:42.97 OspLogTask
 1496 root      20   0 83964  37m 1196 S  0.0  1.0   0:00.00 OspDispatchTask
 1498 root      20   0 83964  37m 1196 S  0.0  1.0   0:00.14 OspTeleDaemon
 1499 root      20   0 83964  37m 1196 S  0.0  1.0   0:00.00 OspPostDaemon
 1500 root      20   0 83964  37m 1196 S  0.0  1.0   0:05.18 OspNodeMan
 1501 root      20   0 83964  37m 1196 S  0.0  1.0   0:06.28 WDClient
 1504 root      20   0 83964  37m 1196 S  0.0  1.0   0:00.00 ModuleInst
 1505 root      20   0 83964  37m 1196 S  0.0  1.0   0:01.79 LgsInst
 1506 root      20   0 83964  37m 1196 S  0.0  1.0   0:19.88 BmcInst
 1507 root      20   0 83964  37m 1196 S  0.0  1.0   9:04.17 LogicSrvInst
 1508 root      20   0 83964  37m 1196 S  0.0  1.0   0:00.00 FileSend
 1531 root      20   0 83964  37m 1196 S  0.0  1.0   0:07.58 MQProducerTask
 1533 root      20   0 83964  37m 1196 S  0.0  1.0   0:38.01 MQConsumerTask

从上面的信息中可以发现两点：

  • 名字为 MQProducerTask 的线程占用的 CPU 几乎为 100%；
  • 名字为 MQProducerTask 的线程的状态为 D ；

3.跟踪 MQProducerTask 线程的执行

[root@rmq_2 guard]# strace -p 1532
Process 1532 attached - interrupt to quit
[ Process PID=1532 runs in 32 bit mode. ]
write(2, "[MQ][producer_tag s:52][fsm:conn"..., 75) = -1 ENOSPC (No space left on device)
write(2, "[MQ][producer_tag s:52][fsm:conn"..., 75) = -1 ENOSPC (No space left on device)
write(2, "[MQ][producer_tag s:52][fsm:conn"..., 75) = -1 ENOSPC (No space left on device)
write(2, "[MQ][producer_tag s:52][fsm:conn"..., 75) = -1 ENOSPC (No space left on device)
write(2, "[MQ][producer_tag s:52][fsm:conn"..., 75) = -1 ENOSPC (No space left on device)
write(2, "[MQ][producer_tag s:52][fsm:conn"..., 75) = -1 ENOSPC (No space left on device)
write(2, "[MQ][producer_tag s:52][fsm:conn"..., 75) = -1 ENOSPC (No space left on device)
write(2, "[MQ][producer_tag s:52][fsm:conn"..., 75) = -1 ENOSPC (No space left on device)
write(2, "[MQ][producer_tag s:52][fsm:conn"..., 75) = -1 ENOSPC (No space left on device)
write(2, "[MQ][producer_tag s:52][fsm:conn"..., 75) = -1 ENOSPC (No space left on device)
write(2, "[MQ][producer_tag s:52][fsm:conn"..., 75) = -1 ENOSPC (No space left on device)
...

发现该线程一直在向 stderr 输出打印信息，并且已经出现磁盘空间不足的提示信息。
4.确认磁盘情况确实已满

[root@rmq_2 guard]# df -h
Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-LogVol01  195G  195G     0 100% /
tmpfs                          1.9G     0  1.9G   0% /dev/shm
/dev/sda1                      194M   34M  150M  19% /boot
[root@rmq_2 guard]#

从业务开发了解到，sa 进程为排查问题，会将 stderr 重定向到 log/sa_rabbitmq.log 日志中。经确认， 该文件已经达到 110G+ 。
5.测试人员手动删除 sa_rabbitmq.log 文件，但是问题依然没有得到解决。可以看到磁盘占用仍旧是 100% ，然后查看 log 下的文件，却发现日志大小为 0 。

[root@rmq_2 log]# ll
total 192472
-rw-r--r-- 1 root root   5243673 May 21 15:30 0sa.txt
-rw-r--r-- 1 root root   5243277 May 21 23:44 10sa.txt
-rw-r--r-- 1 root root   5243373 May 22 00:33 11sa.txt
-rw-r--r-- 1 root root   5243704 May 22 01:22 12sa.txt
-rw-r--r-- 1 root root   5243609 May 22 02:28 13sa.txt
-rw-r--r-- 1 root root   4714496 May 22 03:35 14sa.txt
-rw-r--r-- 1 root root     28672 May 22 04:42 15sa.txt
-rw-r--r-- 1 root root     12288 May 22 05:26 16sa.txt
-rw-r--r-- 1 root root    155648 May 22 05:27 17sa.txt
-rw-r--r-- 1 root root    135168 May 22 05:27 18sa.txt
-rw-r--r-- 1 root root    114688 May 22 05:32 19sa.txt
-rw-r--r-- 1 root root   5243431 May 21 16:20 1sa.txt
-rw-r--r-- 1 root root   5243711 May 21 17:09 2sa.txt
-rw-r--r-- 1 root root   5243431 May 21 17:58 3sa.txt
-rw-r--r-- 1 root root   5243278 May 21 18:48 4sa.txt
-rw-r--r-- 1 root root   5243285 May 21 19:37 5sa.txt
-rw-r--r-- 1 root root   5243698 May 21 20:26 6sa.txt
-rw-r--r-- 1 root root   5243573 May 21 21:16 7sa.txt
-rw-r--r-- 1 root root   5243399 May 21 22:05 8sa.txt
-rw-r--r-- 1 root root   5243647 May 21 22:54 9sa.txt
-rw-r--r-- 1 root root 118338715 May 22 01:30 daemon.log
-rw-r--r-- 1 root root     38613 May 22 01:26 saexc.log
-rw-r--r-- 1 root root      7099 May 22 01:26 saexc.log-maps
-rw-r--r-- 1 root root         0 May 22 02:54 sa_rabbitmq.log
-rw-r--r-- 1 root root     16384 May 22 05:46 sa.txt
-rw-r--r-- 1 root root      8019 May 20 02:28 startsrv.log
[root@rmq_2 log]#

      查看网上相关资料，结论就是： 磁盘文件虽然被删除，却仍被某进程占用，并且还在写（这个说法其实不准确，因为磁盘已满情况下，是无法写入的）。在这种情况下，通过 du 命令是无法找到占用磁盘的大文件。与此同时，被删除的文件仍然会占用磁盘空间。
 6.通过命令确认被删除的文件仍在被进程使用

[root@rmq_2 log]# lsof | grep deleted
sa         1362      root    2w      REG              253,0 197264424960    1312057 /opt/mcu/guard/log/sa_rabbitmq.log (deleted)
...
[root@rmq_2 log]#

确实文件被删除了，但仍旧被进程 sa 所占用，解决办法就是把相关的进程进行重启，空间自然就被释放了。

至于上面业务线程狂刷打印问题的原因和解决办法如下：
      分析 MQProducerTask 线程狂刷上面的日志信息的原因，是因为 FSM 在 conn_idle 状态收到了非 EV_TIMEOUT 事件。并且代码中没有对这个错误分支做事件相关处理，只是输出打印信息。故代码执行完毕后会重新进入 conn_idle 状态，并沿用前一次的事件，导致死循环。源代码如下

default:
    fprintf( stderr, "[MQ][%s s:%d][fsm:conn_idle][*] Weird! NOT Trigger by EV_TIMEOUT\n", 
        conn->tag, amqp_get_sockfd(conn) );
    break;

变更如下

default:
    fprintf( stderr, "[MQ][%s s:%d][fsm:conn_idle][*] Weird! NOT Trigger by EV_TIMEOUT, but by %d\n", 
        conn->tag, amqp_get_sockfd(conn), trigger_ev );

    update_event( conn, 0, RET_IMMEDIATELY );
    conn_set_state( conn, conn_idle );
    stop = 1;
    break;

    另外，还可以将代码中所有要跳转到 conn_idle 状态，且事件更新 XXX 不为 0 的地方都进行修改，以彻底杜绝其它事件的干扰。

update_event( conn, XXX, RET_IMMEDIATELY );
    conn_set_state( conn, conn_idle );

补充：

  • 进程状态为 D 表示当前进程正处于 uninterruptible sleep 状态。
  • Linux 进程有两种睡眠状态，一种为 interruptible sleep 状态，处在这种状态的进程是可以通过向它发信号来进行唤醒的。比如发 HUP 信号给 nginx 的 master 进程可以让 nginx 重新加载配置文件，而不需要重新启动 nginx 进程；另外一种是 uninterruptible sleep 状态，处在这种状态的进程不接受外来的任何信号，所以也无法通过 kill 进行杀死，要想干掉处在 D 状态进程就只能重启整个 Linux 系统了（具有有些情况下，甚至都无法重启）。


进程为什么会被置于 uninterruptible sleep 状态呢？
      处于 uninterruptible sleep 状态的进程通常是在等待 I/O，比如磁盘 I/O，网络 I/O，其他外设 I/O，如果进程正在等待的 I/O 在较长的时间内都没有响应，那么就会很不幸地被 ps 所看到（或者通过 top 看到）。
      出现这个状态就意味着很可能有 I/O 出了问题，可能的原本包括但不限于外设本身故障，磁盘写满，挂载的远程文件系统已经不可访问等原因。

 

 

 

 

 

转载于:https://my.oschina.net/moooofly/blog/418710

weixin_34001430
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
2024年Unity 面试题 |五萬字 二佰道| Unity面试题大全，面试题总结【全网最全，收藏一篇足够面试】
努力前行，总会成为自己心中的那道光
02-23 11万+
正所谓 金三银四 ，又到了找工作的大好时机了，不知道大家有没有意向找一份更好的工作呢~ 之前写了很多Unity的学习和实例文章，但是面试题部分还没有一个系统的整理。 那本篇文章就来整理一下Unity中一些常见的面试题，说不准就会面试的时候就会遇到！ 本篇文章会将Unity所有方面的面试资料都融会贯通，绝对是2022年Unity面试领域最实用的文章啦！
模拟磁盘满的工具
01-09
小工具可以模拟磁盘占满的情况，方便测试一些软件的异常情况
cpu负载4800，根目录磁盘100%，问题排查和解决
guijianchouxyz的博客
09-28 930
就在昨天下午3点的时候，接到机房的电话，说有一台服务器根目录100%了，当时第一反应就是，靠，谁又往根目录上面放文件了，安排处理下就ok了，但是后来机房又曝出来一个猛料，当前机器的LOAD值已经4000+了，那就不得了了，这一点不科学呀，赶紧操作起来看看怎么回事。
磁盘和内存的存储原理
捕影世界
12-27 6640
       我们在程序中的数据处理主要是操作磁盘和内存，硬盘是磁盘里面最常用的一种，以前有所谓的软盘,也是磁盘的一种，原理和硬盘是一样：都是利用磁性物质的特性来保存信息，磁盘的原理就是利用电磁转换，学物理时我们知道电可以使物质带上磁性，而金属在磁场运动时切割磁感线时会产生电流，磁盘上有很多微粒的磁粉；当写通过磁头写数据时，磁头中的电流会导致磁粉极化，改变方向；读数据时,导体磁头经过磁粒的区域时会...
【Linux运维】磁盘告警排查过程及常用磁盘命令
Think In JAVA—Max
11-06 1429
如上问题，/var/log/journal/下日志文件过大，那便可设定journalctl --vacuum-size=500M，因为系统日志会随时间不断增长占用磁盘空间。通过指定一个大小值，journalctl 将删除旧的日志条目，以使日志保持在指定的大小范围内。当日志大小超过这个限制时，journalctl 将删除一些旧的日志条目，以减小日志的总体大小。珍视排查一个看似简单问题的过程，通过排查问题，记录问题的排查思路，引申出新的知识点，并且回顾旧有知识， 温故知新 不断夯实沉淀。
Flink Checkpoint 问题排查实用指南
阿里云技术
09-17 147
在 Flink 中，状态可靠性保证由 Checkpoint 支持，当作业出现 failover 的情况下，Flink 会从最近成功的 Checkpoint 恢复。在实际情况中，我们可能会遇到 Checkpoint 失败，或者 Checkpoint 慢的情况，本文会统一聊一聊 Flink 中 Checkpoint 异常的情况（包括失败和慢），以及可能的原因和排查思路。 1. Checkpoint ...
带你玩转Logview: MaxCompute Logview参数详解和问题排查
xstardust的博客
09-05 360
摘要： 对于Logview上的诸多参数信息，究竟应该怎么“拨开云雾”，发现问题所在呢？又如何通过Logview了解每个instance、task运行状态及资源占用情况，如何分析执行计划，分析query存在问题，找到Long-Tails task，让数据分析业务高效又省钱呢？本文中，阿里巴巴计算平台产品专家云花将为大家揭晓答案。 摘要：Logview是MaxCompute Job提交后查看和Deb...
K8S线上集群排查，实测排查Node节点NotReady异常状态
Tulipyx的博客
02-19 4241
一，文章简述 大家好，本篇是个人的第 2 篇文章。是关于在之前项目中，k8s 线上集群中 Node 节点状态变成 NotReady 状态，导致整个 Node 节点中容器停止服务后的问题排查。 文章中所描述的是本人在项目中线上环境实际解决的，那除了如何解决该问题，更重要的是如何去排查这个问题的起因。 关于 Node 节点不可用的 NotReady 状态，当时也是花了挺久的时间去排查的。 二，Pod 状态 在分析 NotReady 状态之前，我们首先需要了解在 k8s 中 Pod 的状态都有哪些。并且每个状态都
【原创】20180510_RAC节点重启原因分析.zip
01-16
3. **排查硬件**：检查硬件健康状态，如内存、CPU、磁盘I/O和网络连接。 4. **检查软件版本**：确认所有软件组件（包括操作系统、Oracle数据库、集群ware）是否为最新补丁级别。 5. **性能监控**：分析性能指标，...
磁盘的内部结构及原理（详细）
最新发布
蚂蚁小哥
05-09 1873
机械硬盘（HDD，Hard Disk Drive）是一种数据存储设备，采用机械运动来读取和写入数据。它由一个或多个盘片组成，每个盘片正反面都有磁头负责读写数据。
Linux学习之旅（六）——磁盘管理
weixin_43569314的博客
06-26 923
磁盘管理 基本信息 磁盘作为存储数据的介质，在计算机中的不可或缺，管理好磁盘也是一项最基本的技能 虽然现代的存储介质很少用到磁盘，但是其本质都是差不多的，所以能够套用磁盘的一些概念： 盘片（platter）：一个机械式磁盘一般由若干磁性盘片组成； 磁头（head）：每个盘片一般有上下两面，盘片的两个面均能存储数据，因此需要两个磁头； 磁道（track）：每个盘片沿着半径的方向可以划分为很多同心圆...
磁盘基本知识介绍
技术积累，技术分享
01-30 4758
数据库的数据存储在文件系统中。 文件系统是操作系统用来明确存储设备或分区上的文件 的方法和数据结构(存储设备常见的是磁盘，也有基于NAND Flash的固态硬盘) 磁盘上数据必须用一个三维地址唯一标示：柱面号、盘面号、块号(磁道上的盘块)。 硬盘只是磁盘的一种，或说是经典代表，以下通过硬盘模型图讲解磁盘中的各个概念。 硬盘整体模型图 硬盘模型图 磁盘重点概念 盘片（platter）：硬盘中承载数据存储的介质 硬盘一般由多个盘片组成，每个盘片包含两个面，每个盘面都对应地有一个读/写磁头。受到硬盘整体体积
磁盘的基本概念介绍
HFUT_Uzi的博客
03-07 2083
盘面，磁道，扇区，柱面，簇
磁盘概述、磁盘缓存、虚拟内存及虚拟内存与内存的交换方式
m0_61961937的博客
10-03 2692
磁盘概述、磁盘缓存、虚拟内存及虚拟内存与内存的交换方式
磁盘空间已满导致rabbitmq无法启动
weixin_30367169的博客
07-12 2550
rabbitmq-server 启动问题 今天遇到一个挺奇怪的 rabbitmq-server 的启动问题。 在内部使用的 openstack 环境上，rabbitmq-server突然就关掉了，无法启动。 于是，尝试生动启动一下： rabbitmq-server 错误报告说是： Could not create dir /var/lib/rabbitmq/mnesia/rabbit@host-p...
磁盘I/O那些事
美团技术团队
05-19 3081
背景 计算机硬件性能在过去十年间的发展普遍遵循摩尔定律，通用计算机的CPU主频早已超过3GHz，内存也进入了普及DDR4的时代。然而传统硬盘虽然在存储容量上增长迅速，但是在读写性能上并无明显提升，同时SSD硬盘价格高昂，不能在短时间内完全替代传统硬盘。传统磁盘的I/O读写速度成为了计算机系统性能提高的瓶颈，制约了计算机整体性能的发展。 硬盘性能的制约因素是什么？如何根据磁盘I/O特...
rabbitmq技术的一些感悟（一）
热门推荐
网易搬砖选手
08-19 4万+
Rabbitmq 初识rabbitmq RabbitMQ是流行的开源消息队列系统，用erlang语言开发。RabbitMQ是AMQP（高级消息队列协议）的标准实现。如果不熟悉AMQP，直接看RabbitMQ的文档会比较困难。不过它也只有几个关键概念，这里简单介绍 几个概念说明： Broker：简单来说就是消息队列服务器实体。 Exchange：消息交换机，它指定消息按什么规则，路由到
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值