登录
首页 >  文章 >  linux

Linux进程查看:ps与top命令使用教程

时间:2026-03-13 16:52:34 134浏览 收藏

本文深入剖析了Linux中进程查看的两大核心工具——ps与top,揭示了常见误解与实战陷阱:ps aux并非真正“全进程”,它忽略内核线程和跨namespace容器进程,其价值在于清晰呈现用户态进程、完整资源指标及跨用户可见性;而top的CPU占用率易因单核归一化、采样间隔导致误判,需善用1键切换多核视图和-b模式适配脚本。文章还纠正常见错误,如grep模糊匹配的干扰、VIRT与RES的内存误读、僵尸进程(Z)的本质与正确处置方式,并强调:真正危险的不是Z进程本身,而是背后暴露的父进程资源回收缺陷——掌握这些细节,才能从“看到进程”跃升为“读懂系统”。

Linux怎么查看进程信息_Linux ps和top命令使用【监控】

ps aux 是最常用但容易误解的“全进程”命令

它确实能列出几乎所有进程,但不是字面意义的“全部”——ps aux 不显示内核线程(如 kthreaddrcu_gp),也不显示某些 namespace 隔离下的容器进程(除非你在对应命名空间里执行)。它的核心价值在于:用户态进程 + 完整资源字段 + 跨用户可见。

常见错误是以为 ps aux | grep nginx 一定能抓到所有 nginx 进程。其实如果 nginx 启用了 master-worker 模式且 worker 进程被 cgroup 限制或运行在不同用户下,可能漏掉部分;更稳妥的是加 -f 显示完整命令行:ps -ef | grep nginx,或直接用 pidof nginx 获取 PID 列表。

  • ps aux 中的 U 表示用户,%CPU%MEM 是瞬时占用率,不是平均值
  • 想看进程树关系?别硬读 ps aux 输出,改用 pstree -pps -e --forest
  • 注意 ps 是快照命令:执行完就结束,无法反映持续行为——这点常被误当成 top 的替代品

top 实时监控时 CPU 占用率不准的三个原因

你看到某进程长期显示 95% CPU,但它实际可能只占 10% ——这不是 bug,而是 top 默认按单核归一化显示。比如 4 核机器上一个满载单线程进程,在 top 里就是 100%,但真实占用是 25% 的总 CPU 资源。

另一个坑是 top 默认刷新间隔为 3 秒,而高频率短时爆发型进程(如 cron 触发的脚本)可能刚好在两次采样之间完成,导致完全看不到峰值。

  • 1 键可切换显示各 CPU 核心负载,避免单核过载被平均掩盖
  • top -n 1 获取单次快照,适合脚本调用;top -b -n 1 输出纯文本,方便管道处理
  • 内存列里的 VIRT(虚拟内存)≠ 实际使用量,RES(常驻内存)才接近真实物理内存占用,SHR 是共享库大小,别误判为“多进程共用节省了内存”

查特定进程或用户时,别依赖模糊 grep

ps aux | grep python 会把自己这条 grep 命令也列出来,干扰判断;更糟的是,如果目标进程名含空格或特殊字符(如 node server.js),grep 可能匹配不全。

真正可靠的方式是用 ps 原生命令过滤:

  • 查指定用户:ps -u www-data(比 ps aux | grep www-data 干净得多)
  • 查指定 PID:ps -p 1234,支持多个 PID:ps -p 1234,5678
  • 查进程名精确匹配:pgrep -f "nginx: master process"pidof nginx(只返回 PID 数字)
  • top 里也能限定:top -u www-datatop -p $(pgrep -f "redis-server")

僵尸进程(Z)和孤儿进程()怎么识别和处理

僵尸进程状态标为 Z,出现在 ps auxSTAT 列;它已终止,但父进程没调用 wait() 回收,仍占 PID 和少量内核资源。大量 Z 进程会耗尽 PID 空间(默认 32768),导致新进程无法启动。

孤儿进程不是问题——它只是父进程挂了,被 init/systemd 接管(PID 变成 1 或 1960),状态仍是 SR,正常运行。

  • 查僵尸:ps aux | awk '$8 ~ /Z/ {print}',重点关注其 PPID(父进程 ID)
  • 不能用 kill -9 杀僵尸——它已经死了,只能杀它的父进程,逼父进程退出后由 init 回收;或重启父服务
  • 若父进程是 systemd,可尝试 systemctl kill --signal=SIGCHLD 触发子进程回收

真正要警惕的不是 Z 进程本身,而是它背后暴露的父进程 bug:不处理子进程退出信号、逻辑卡死、或未正确调用 waitpid()。这类问题在 C/Go 编写的守护进程中尤其常见。

以上就是本文的全部内容了,是否有顺利帮助你解决问题?若是能给你带来学习上的帮助,请大家多多支持golang学习网!更多关于文章的相关知识,也可关注golang学习网公众号。

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>