Linux进程多导致CPU卡死的问题

本文详细记录了服务器CPU负载过高和邮件系统空间不足导致的问题,包括日志分析、进程检查、空间清理以及系统优化的过程。通过top命令监控进程、使用lsof查看文件打开情况、清除历史监控日志、修改cron.d中的sysstat配置等步骤,最终解决了服务器性能问题并释放了磁盘空间。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

转载请注明出处: http://blog.csdn.net/guoyjoe/article/details/49924557

一、邮箱收到一堆监控,报警内空大致如下,很明显是CPU不够用了,IO也有点问题:主机: bwebser2__10.253.5.198 时间: 2015.11.15 15:25:17状态: PROBLEM 级别: Warning报警原因: Processor load is too high on bwebser2内容: Processor load (1 min average per core):value=52.53原始事件ID: 30605主机: bwebser2__10.253.5.198时间: 2015.11.18 15:42:23 状态: PROBLEM级别: Warning 报警原因: Disk I/O is overloaded on bwebser2 内容: CPU iowait time:value=68.7 %原始事件ID: 30812

二、用top查看进程,发现有近2000个进程

[root@bwebser2 ~]# top
top - 10:00:32 up 184 days, 19:55,  2 users,  load average: 49.39, 52.06, 53.04
Tasks: 1826 total,   1 running, 1825 sleeping,   0 stopped,   0 zombie
Cpu(s): 22.5%us,  3.8%sy,  0.0%ni, 31.7%id, 41.3%wa,  0.7%hi,  0.0%si,  0.0%st
Mem:   8058056k total,  7631808k used,   426248k free,   718780k buffers
Swap:        0k total,        0k used,        0k free,   358720k cached


三、猜测可能和sendmail有关,查maillog日志,一直报警:No space left on device

[root@bwebser2 ~]# tail -f  /var/log/maillog     
Nov 19 10:12:15 bwebser2 postfix/postdrop[19470]: warning: mail_queue_enter: create file maildrop/878633.19470: No space left on device
Nov 19 10:12:15 bwebser2 postfix/postdrop[27287]: warning: mail_queue_enter: create file maildrop/900082.27287: No space left on device
Nov 19 10:12:15 bwebser2 postfix/postdrop[12347]: warning: mail_queue_enter: create file maildrop/919377.12347: No space left on device
Nov 19 10:12:15 bwebser2 postfix/postdrop[21222]: warning: mail_queue_enter: create file maildrop/937001.21222: No space left on device
Nov 19 10:12:16 bwebser2 postfix/postdrop[25028]: warning: mail_queue_enter: create file maildrop/956095.25028: No space left on device
Nov 19 10:12:16 bwebser2 postfix/postdrop[28123]: warning: mail_queue_enter: create file maildrop/980022.28123: No space left on device
Nov 19 10:12:16 bwebser2 postfix/postdrop[26680]: warning: mail_queue_enter: create file maildrop/999360.26680: No space left on device


四、用lsof确定sendmail、postdrop进程数量,进程数达到2000多个,为什么有这么多呢?

[root@bwebser2 ~]# lsof |grep sendmail |wc -l
24682
[root@bwebser2 ~]# lsof |grep postdrop  |wc -l
24108



五、查看文件索引节点inode,发现空间满了:

[root@bwebser2 log]# df -i
Filesystem       Inodes   IUsed    IFree IUse% Mounted on
/dev/xvda1      1310720 1310720        0  100% /
tmpfs           1007257       1  1007256    1% /dev/shm
/dev/xvdb1     13107200    6142 13101058    1% /u01

用df -Th命令:
root@cwebser3 statistics]# df -Th
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/xvda1     ext4    20G  4.1G   15G  22% /
tmpfs          tmpfs  3.9G     0  3.9G   0% /dev/shm
/dev/xvdb1     ext3   197G   18G  170G  10% /u01


六、通过清除zookeeper监控日志把腾出根的空间

cd /home/zookeeper/monitor 
[root@bwebser2 monitor]# ll
total 8
drwxrwxr-x 163 zookeeper zookeeper 4096 Nov 12 00:16 charts
drwxrwxr-x 167 zookeeper zookeeper 4096 Nov 18 17:31 statistics
[root@bwebser2 monitor]# cd charts
rm -rf *
[root@bwebser2 monitor]# cd ../statistics/
[root@bwebser2 statistics]# rm -rf 201506*
[root@bwebser2 statistics]# rm -rf 201507*
[root@bwebser2 statistics]# rm -rf 201508*
[root@bwebser2 statistics]# rm -rf 201509*
[root@bwebser2 statistics]# rm -rf 201510*


七、杀死所有sendmail和postdrop进程后

[root@bwebser2 ~]#ps -ef|grep sendmail | grep -v grep | awk  '{print "kill -9 " $2}' |sh
[root@bwebser2 ~]#ps -ef|grep postdrop | grep -v grep | awk  '{print "kill -9 " $2}' |sh



八、lsof查看,进程数为0

[root@bwebser2 ~]# lsof |grep sendmail |wc -l
0
[root@bwebser2 ~]# lsof |grep postdrop  |wc -l
0


九、被忽略的/etc/cron.d下的sysstat,修改sysstat,操作如下:

[root@bwebser2 cron.d]#cd /etc/cron.d/
[root@bwebser2 cron.d]# ll
total 12
-rw-r--r--. 1 root root 113 Nov 23  2013 0hourly
-rw-r--r--. 1 root root 108 Apr  7  2014 raid-check
-rw-r--r--. 1 root root 235 Nov 23  2013 sysstat
 
vi sysstat添加&>/dev/null
# run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib/sa/sa1 1 1 &>/dev/null
# generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib/sa/sa2 -A &>/dev/null  


十、再次用top命令查看进程只有100多个,监控报警消失,问题搞定!

[root@bwebser2 cron.d]# service sendmail restart
sendmail: unrecognized service
[root@cwebser3 cron.d]# top
top - 10:43:12 up 184 days, 20:37,  2 users,  load average: 1.03, 1.54, 14.15
Tasks: 105 total,   1 running, 104 sleeping,   0 stopped,   0 zombie
Cpu(s): 43.4%us,  1.3%sy,  0.0%ni, 47.9%id,  7.0%wa,  0.3%hi,  0.0%si,  0.0%st
Mem:   8058056k total,  6762996k used,  1295060k free,  1422060k buffers
Swap:        0k total,        0k used,        0k free,   381392k cached




<think>嗯,用户想排查导致console卡死的空闲进程问题,问进程无操作但导致console卡死的原因及解决方法。首先,我需要回忆一下之前学过的系统进程管理和卡死相关的知识。根据用户提供的引用,特别是引用[1]提到的Linux系统死机情况,比如gnome进程卡死,可能和底层软件bug有关,或者X Server的问题。另外,引用[3]提到定时器导致页面卡顿,虽然这里说的是网页,但可能类似的后台进程占用资源也会导致问题。 首先,用户的问题是console卡死,可能是指终端界面无响应,但系统其他部分可能还能运行。或者整个控制台都卡住了?需要分情况讨论。可能的原因有几个方面: 1. **资源占用过高**:比如CPU、内存或I/O被某个后台进程占用,导致系统无法响应。比如某个进程虽然看起来空闲,但可能陷入死循环或者大量占用磁盘I/O,导致系统负载过高。引用[1]提到系统负载高可能导致键盘无反应,但如果是X Server的问题,可能和显示相关。 2. **驱动或内核问题**:硬件驱动不兼容或内核模块bug可能导致系统卡死。比如显卡驱动问题会影响图形界面,但控制台卡死可能涉及终端驱动的问题。 3. **进程死锁或阻塞**:某个进程可能在等待某个资源而无法释放,导致其他进程被阻塞。尤其是系统关键进程如果出现问题,会影响整个系统的响应。 4. **文件系统损坏**:如引用[1]中的例子,分区表损坏导致问题,虽然用户现在的情况可能不同,但文件系统错误也可能导致进程卡住。 5. **定时器或后台任务**:类似引用[3]中的定时器问题,虽然这里是浏览器页面,但系统级的定时任务(如cron job)如果有问题,可能会占用过资源。 接下来,解决方法需要逐步排查: 第一步,用户可能需要检查系统资源使用情况。即使控制台卡死,可以尝试切换到其他虚拟终端(比如Ctrl+Alt+F2),登录后使用top或htop查看进程资源占用情况。如果无法切换,可能需要通过SSH远程登录查看。 如果发现某个进程占用过高CPU或内存,可以尝试终止它。或者使用dmesg检查内核日志,看是否有硬件错误或驱动问题。 另外,I/O等待高的情况可以用iostat或iotop检查,看是否有进程大量读写磁盘,导致系统卡顿。 关于驱动或内核问题,可以查看/var/log/Xorg.0.log,或者使用journalctl查看系统日志,寻找错误信息。如果是驱动问题,可能需要更新或回滚驱动版本。 进程死锁的情况可能需要使用strace跟踪进程的系统调用,看是否卡在某个系统调用上。例如,进程可能在等待一个无法响应的网络请求,或者文件锁无法释放。 文件系统问题可以运行fsck检查,但需要注意在卸载分区的情况下进行,可能需要使用Live CD/USB。 此外,用户提到的“空闲进程”可能指进程处于休眠状态,但由于某些原因无法被调度,或者存在内核中的竞争条件。这种情况下可能需要更新内核或相关软件包。 最后,用户可能需要检查是否有定时任务或后台服务异常,比如cron job配置错误,导致资源泄漏。使用systemctl或service命令查看服务状态,是否有失败的服务。 总结下来,可能的解决步骤包括:检查资源使用情况、查看系统日志、检查驱动和内核问题、分析进程状态、处理文件系统错误、调整或禁用有问题的服务或定时任务。需要用户一步步排查,找到具体原因后采取相应措施。</think>### 排查控制台卡死的空闲进程问题:原因与解决方法 #### **一、可能原因分析** 1. **系统资源耗尽** - **CPU/内存占用过高**:某个后台进程可能因代码缺陷(如死循环、内存泄漏)导致资源耗尽,即使表面显示“空闲”,实际可能因内核调度异常占用资源[^1]。 - **I/O 阻塞**:进程因频繁读写磁盘或网络请求阻塞,导致系统无响应(例如数据库进程长时间占用磁盘)。 2. **驱动或内核问题** - 显卡驱动、终端模拟器(如 `tty`)驱动与内核版本不兼容,可能引发控制台卡死[^1]。 - 内核模块(如文件系统模块)存在 Bug,导致进程调度异常。 3. **进程死锁或僵死(Zombie)** - 进程因同步机制错误(如未释放锁)进入死锁状态,或父进程未正确处理子进程退出信号,导致僵死进程积累[^1]。 4. **文件系统损坏** - 文件系统元数据损坏可能导致进程在访问文件时卡死(如引用[1]中提到的 `ext4` 分区损坏问题)。 --- #### **二、排查步骤与解决方法** 1. **检查系统资源占用** - **通过SSH或物理终端切换**:若图形界面卡死,尝试 `Ctrl+Alt+F2` 切换至虚拟终端,登录后执行: ```bash top # 查看CPU/内存占用最高的进程 iotop -o # 检查I/O占用高的进程 free -h # 查看内存使用情况 ``` - **终止异常进程**:找到异常进程后,使用 `kill -9 PID` 强制终止。 2. **分析系统日志** - 查看内核日志: ```bash dmesg | tail -n 50 # 检查硬件或驱动错误 ``` - 查看系统服务日志: ```bash journalctl -p 3 -xb # 过滤错误级别的日志 ``` 3. **排查驱动与内核问题** - **更新驱动**:例如更新显卡驱动或终端驱动: ```bash sudo apt update && sudo apt upgrade ``` - **回退内核版本**:若问题出现在内核升级后,可尝试回退到稳定版本。 4. **处理进程死锁或僵死** - **检测僵死进程**: ```bash ps aux | grep 'Z' # 筛选僵死进程 ``` - **手动释放资源**:若僵死进程进程为 Shell,可重启 Shell;若为系统进程,需重启服务。 5. **修复文件系统** - 使用 `fsck` 工具修复(需卸载目标分区): ```bash umount /dev/sdXN # 卸载分区 fsck -y /dev/sdXN # 自动修复 ``` 6. **优化后台服务与定时任务** - 检查定时任务(`crontab -l`)或后台服务(`systemctl list-units --type=service`),禁用可疑任务: ```bash systemctl stop service_name # 临时停止服务 ``` --- #### **三、预防措施** - 定期清理日志与临时文件,避免磁盘空间耗尽。 - 使用 `cgroups` 限制进程资源占用: ```bash cgcreate -g cpu,memory:/limited_group cgset -r cpu.cfs_quota_us=50000 limited_group # 限制CPU为50% ``` - 启用系统监控工具(如 `Prometheus` + `Grafana`)实时跟踪资源使用。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值