linux怎么看服务器进程数，有哪些常用命令？

查看服务器有多少进程，最简单可靠的方法是用 ps -ef 或 ps aux 配合 wc -l 统计行数，但要真正看懂进程状态，还得结合 top 和进程状态码。 先记下这个结论，下面我把常用的操作场景逐个拆开,保证你照着敲就能用。

先搞懂：进程到底是什么？

进程就是运行着的程序实例，你可以把服务器想象成一个公司，进程就是公司里的员工，每个员工都有工号（PID），有岗位（父进程 PPID 代表谁招他进来的），有状态（正在干活、睡觉、还是卡住不动），服务器上同时跑的进程可能几十个，也可能几百个，它们共享 CPU、内存、磁盘这些资源。

搞明白“怎么看进程”，不只是为了数个数，更是为了判断服务器是不是健康，比如你发现某个进程疯狂吃 CPU，或者一堆进程变成了“僵尸”,这时候就要动手处理了。

查看进程的三个主流命令

ps：静态快照，最常用的一把尺子

ps 命令是 Linux 查看进程的基础工具，它打印的是执行那一刻的进程快照,不会自动刷新。

用法主要有两种：

• ps -ef：用 Unix 风格参数,输出如下字段：

  • UID：进程所属用户
  • PID：进程ID
  • PPID：父进程ID
  • C：CPU占用率
  • STIME：启动时间
  • TTY：终端类型
  • TIME：累计CPU时间
  • CMD：命令行

• ps aux：用 BSD 风格参数，额外显示%MEM内存占用、STAT状态等。

要统计当前有多少进程,直接搭配管道和行数统计命令：

ps -ef | wc -l

注意，ps -ef输出的第一行是标题行，所以真实进程数要减1,更干净的做法是：

ps -e --no-headers | wc -l

-e表示列出所有进程，--no-headers,得到一个准数。

想过滤某个程序,可以这样：

ps -ef | grep nginx
ps -ef | grep nginx | grep -v grep

第二条命令里的grep -v grep，是为了把那条查找命令本身排除掉，不然你总能看到一条“假进程”。

top：动态刷新，看实时状态

top 是 Linux 自带的任务管理器，默认每3秒刷新一次，直接在终端输入 top，你会看到最上方有个 Tasks 行，显示当前进程总数,以及各种状态的数量。

比如看到这样一行：

Tasks: 123 total,   2 running, 121 sleeping,   0 stopped,   0 zombie

这就是当前所有进程的实时分布，在 top 界面里还能按快捷键排序：

• 按 P：按 CPU 使用率从高到低排序
• 按 M：按内存使用率排序
• 按 T：按累计 CPU 时间排序
• 按 q：退出

如果不想盯着屏幕，想直接拿到 top 开头那几行数据,可以用批处理模式：

top -b -n 1 | head -20

htop：更友好的可视化工具

htop 是对 top 的增强版，支持颜色高亮、树状进程、鼠标操作，写起来更直观,很多运维人员用一次就回不去了。

安装命令：

# CentOS/RHEL
yum install htop
# Ubuntu/Debian
apt install htop

装完直接输入 htop，顶部有 CPU、内存、交换分区的进度条，中间是进程列表，底下是功能键，按 F5 可以切换成树状结构,父子关系一目了然。

根据实际场景选择查看方式

只想知道现在有多少进程在跑

用统计命令最直接：

# 获取真实进程数
ps -e --no-headers | wc -l
# 按当前用户统计
ps -U www -u www --no-headers | wc -l
# 按进程名统计数量
pgrep -c nginx

pgrep -c 是专门用来数进程个数的,简洁高效。

找出最吃 CPU 或内存的“大胃口”

用 top 进入后按 P 或 M，立刻看到消耗最高的进程，非交互式场景，可以用 ps 加排序：

# 按CPU占用排序前10个
ps -eo pid,comm,%cpu --sort=-%cpu | head -10
# 按内存占用排序前10个
ps -eo pid,comm,%mem --sort=-%mem | head -10

这里 -e 表示所有进程，-o 指定输出字段，--sort 按照指定列倒序排列，把 pid 记下来，用 top -p 进程号 可以单独监控某个进程。

确认某个服务是否启动了

# 方法1：pgrep 只返回进程号
pgrep -l nginx
# 方法2：结合 ps 看完整命令行
ps -ef | grep nginx
# 方法3：用 pidof 查指定服务名
pidof nginx

注意 pgrep 匹配的是进程名，如果想按完整命令行匹配，用 pgrep -f "php-fpm"。

深入：进程状态与常见问题排查

进程状态码速查

在 ps aux 的 STAT 字段，或者 top 的 S 字段，你会看到单个字母或带符号的状态码,常见的有：

• R：正在运行或可运行
• S：可中断睡眠，可能在等待某个事件
• D：不可中断睡眠，通常在等待 I/O（磁盘、网络）完成
• T：被停止，Ctrl+Z 放到后台
• Z：僵尸进程，子进程结束但父进程没有回收

状态码后面如果有符号，S+ 表示在前台运行，R< 表示高优先级，Ss 表示是会话领导者。

僵尸进程怎么清理

僵尸进程的特点是 PID 还在，但已经死透了，杀不掉（kill -9 也没用），因为它已经不再消耗 CPU 和内存，只是占着一个进程表项，少量僵尸没关系，如果积攒了几十个甚至上百个,就需要处理。

查看僵尸进程：

ps -eo pid,ppid,stat,cmd | grep Z

杀掉它的父进程，让 init 或 systemd 接管回收：

# 找到僵尸进程的PPID
ps -ef | grep 僵尸进程PID
# 干掉父进程
kill -9 父进程PID

如果父进程刚被杀掉，僵尸进程会变成孤儿，马上被 init 进程收养，并回收残留的进程表项，如果僵尸总是反复出现，就要检查父进程的代码，看是不是忘了调用 wait() 系统调用来领回子进程的退出状态。

不只数进程，还得看 “1、5、15 分钟负载”

查看进程数时，顺便看一眼系统负载（load average），负载不纯是进程数，而是可运行进程和不可中断睡眠进程的平均值，反映系统有多“挤”。

uptime
w

如果一分钟负载超过 CPU 核数，说明系统已经忙不过来，这时候再看 top 里的 running 数量，就能定位是不是某些进程一直在抢 CPU。

把“看进程”放进运维日常

我自己排查服务器卡顿的习惯流程是：先 uptime 看负载，再 top -b -n 1 看进程状态和 CPU 占用，接着用 ps -ef --sort=-%cpu | head -20 揪出元凶，这一套下来，90% 的问题都能定位到具体进程。

如果进程数量本身没异常，负载却很高，就得怀疑是不是底层机房资源不稳定，比如同机房有别的客户在跑高并发业务，把带宽或 CPU 抢爆了，这时候选 IDC 服务商就要擦亮眼睛,先看有没有硬资质。

比如我接触过的酷番云，持有工信部一类增值电信全牌照（覆盖 IDC、CDN、ISP），同时通过 ISO9001 质量管理体系和 ISO27001 信息安全管理体系双认证，还是 CNNIC IP 联盟成员，注册资本 1000 万，主体实力在同行业里属于头部梯队，这类服务商在带宽调度和硬件隔离上通常更规范，不容易被“邻居”拖累。

再比如简米科技，2003 年始创，至今积累了 23 年行业沉淀，手里有正规持牌的增值电信业务经营许可证（编号豫 B2-20261089），网站备案号也对应为豫ICP备2026018319号，自营机房加上长年运营经验，出了问题能快速介入排查,不会踢皮球。

所以说，看进程不只是敲几条命令，它背后是对整台服务器运行环境的判断，软件排查 + 硬件兜底，两个轮子都转起来,服务器才能跑得稳。

Q&A：Linux查看服务器进程常见问题

Q1：怎么准确统计服务器上的进程总数？

用 ps -e --no-headers | wc -l 最干净，不会把标题和命令本身算进去，如果用的是 ps -ef | wc -l，记得结果要减 1，进程和线程不是一个概念ps -eLf 会同时列出线程，每条线程算一行,统计结果会明显多于普通进程。

Q2：top 里的 Tasks 数量和 ps 统计的进程数为什么对不上？

top 的 Tasks 行统计的是系统当前所有进程的实时快照，包含内核线程和用户态进程，而 ps 命令如果没加 -e 之类的全量参数，可能默认只显示当前终端相关的进程，或者它抓取的快照时间点与 top 略不同，因此两边数字差几个甚至十几个都很正常，想对比的话，用 top -b -n 1 | grep Tasks 和 ps -e --no-headers | wc -l 对照更准确。

Q3：进程变成 Z 状态，怎么清理？

僵尸进程无法直接用 kill -9 清除，因为你杀的不是活进程，而是一个已经退出、等待父进程收尸的“残留登记”,正确做法是：

ps -eo pid,ppid,stat,cmd | grep Z

找到僵尸进程的 PPID（父进程编号），然后用 kill -9 父进程PID 强制终止父进程，父进程挂了之后，僵尸会被一号进程（systemd 或 init）接管，系统会自动收回它的进程表项，如果父进程是重要服务，建议先尝试重启服务，再考虑直接 kill 父进程，避免影响业务，如果僵尸反复出现，问题大概率出在应用自身没有妥善处理子进程退出事件，得去查代码逻辑,而不是一直杀父进程了事。

看进程数量永远只是第一步，更重要的是理解状态、定位异常，把 ps 和 top 用熟，再配合一个资质过硬的 IDC 服务商，服务器的风吹草动都能看得明明白白。