Linux如何查看当前运行的所有进程

说实话，说到Linux系统的进程管理，我十几年来跑遍了各种场景，发现没有万能钥匙。
必须根据情况使用工具。
例如，当我在银行担任系统主管时，有时系统会在半夜突然卡住。
仅仅盯着 ps aux 是不行的，我必须使用一些无情的策略。

我们先来说说最基本的PS命令。
这东西确实是古董。
记得刚入行的时候，师傅教了我ps aux 组合。
他说：“这取决于资源的使用情况。
”现在想想，USER、PID这样的字段都是基础的，但当时我花了很长时间才明白VSZ和RSS的区别——VSZ是虚拟内存，RSS是实际占用的物理内存。
如果判断混乱，就很容易误入歧途。
比如某个服务的内存突然上升，只要看这两个数字就可以判断是代码存在内存泄漏还是配置问题。

有趣的是动态监控工具提示，特别适合实时监控系统。
我在电信行业从事运营和维护工作。
有一次半夜我看到最上面有一个进程，CPU速度为9 0%，但是看了CMD一栏我也看不出它是什么。
后来我按P和M来回切换，发现是某个监控脚本的问题。
这个东西的一个好处就是可以直接杀掉进程。
只需按 k 并添加 PID 即可杀死它。
这比找到 PID 然后打开终端并使用kill 命令要容易得多。
但您需要密切关注顶层系统负载信息。
我见过好几次，系统明显CPU低，但是当负载超过5 时系统就死机了，这种情况就需要结合free看看swap空间是否满了。

后来才接触到htop的改进版，用起来很好玩。
记得当时在阿里云调优一个电商系统的时候，通过htop的树形视图，可以立刻了解到nginx进程下面挂了多少个子进程。
这比 ps ef 生成的 PPID 列直观得多。
特别是在多核CPU时代，htop对于显示每个核心的负载分布特别有用。
我在调试一个高并发场景时，发现一个核心的负载一直很高。
我用htop鼠标点了一下，直接选择kill，问题立刻就解决了。
但是，安装 htop 需要 root 权限，并且客户端环境中的一些限制需要解决方法。

说到筛选工具，我有一个陷阱经历。
以前我用过 ps aux |抓了nginx来查看某国企系统上的进程。
我发现握把本身也在输出中，花了半个小时终于找到了问题。
后来我改用了 ps aux | 的常规方法grep "[n]ginx" 来解决问题。
pgrep 特别适合脚本。
我经常使用 pgrep -l nginx 编写监控脚本来返回 PID 和名称，这比 ps aux | 效率高得多。
紧握。
然而，pidof 有一个小陷阱。
它仅返回第一个匹配的 PID。
上次使用pidof nginx查看Nginx进程时，只看到了httpd的PID，因为系统默认安装了Apache。
这必须用 ps aux 确认。

关于进程状态，我遇到过的最奇怪的事情就是大量的Z状态进程。
这是在国家系统上。
运维告诉我ps aux中的Z状态进程堆积如山，问我是否有僵尸进程泄漏。
后来我检查日志，发现某个计划任务挂起，但没有正确释放资源，最终必须重新启动服务才能解决问题。
还有一种情况是某个服务卡在D状态，最终发现是磁盘阵列有问题。
这让我明白了，看进程状态不能只看R/S/D/Z，还要与系统的其他指标结合起来。

说到深度分析，iotop这个工具简直就是救星。
我记得当我调整金融交易系统时，这是一个内存低但磁盘 I/O 高的进程。
我用iotop查看，发现日志操作过于频繁。
vmstat 也是必须的。
我经常使用vmstat 1 不断更新来查看CPU和I/O的实时波动。
这比上面看单个进程的CPU更全面。
free -h命令虽然简单，但是非常方便。
它一定在我随身携带的 bash 脚本中。

说白了，Linux进程管理是一种合力。
在做应急准备时，单独使用top可能就足够了，但如果想更深入地挖掘问题，则需要切换到ps、iotop和vmstat的组合。
后来我总结了一个经验：用ps aux看全貌，用ps ef检查关系，用htop实时监控，用grep/pgrep筛选目标，检查STAT列诊断状态，用iotop/vmstat查找瓶颈。
每个工具都有其自身的局限性。
关键是知道什么时候用哪把“刀”。

linux查看进程的命令是什么

说实话，刚接手服务器的时候，我对Linux进程管理完全是一头雾水。
直到有人向我解释了这种组合，我才想：“哦，原来是这样。
”以 ps 命令为例。
当我第一次在终端上输入 ps aux 时，我查看了填满屏幕的进程列表。
CPU 和内存列中的数字跳动得非常快。
那一刻我的手在颤抖——我根本不明白！后来管理员给我演示了一下，说：“你看这个PID，这个USER，还有CMD后面的命令名。
”然后我发现了一些提示，值得注意的是，这个参数组合起来其实是“所有扩展用户”的缩写，但只知道它的字面意义是没有意义的，你必须在现实场景中反复使用它才能记住它。

我更印象深刻的是更高的命令，它是一个交互式工具，一打开它，一组当我开始调整服务器CPU使用率时，我依靠这个东西，将鼠标悬停在一个进程上，它会更详细地展开，但是要小心，如果在配置不佳的服务器上使用此命令太多，您会陷入困境：
在查找进程PID时，我的一个朋友曾经犯过这样的错误。
pgrep找到bash进程，但是命令行炸了。
后来他说他把bash写成了Bash，因为它区分大小写！所以，在使用这些工具时，记得要确认进程名称完全匹配。
还有一个细节，就是我在使用kill命令杀死进程时，最好不要直接写上kill PID，否则可能会默认只发送一个SIGTERM信号。
pstree 命令对我来说是一个救命稻草。
一个 shell 启动了十几个子进程，光看 ps 列表就完全搞乱了，而且关系变得一团糟。
但是，使用 pstree，所有进程都变成一棵树，谁是父进程，谁是子进程，一目了然。
但是，需要注意的是，这个命令可能需要在某些系统上安装 psutils 软件包。

最后，说实话，这些命令单独使用时非常有用，但要真正发挥 Linux 进程管理的作用，你需要将这些工具结合起来，例如，首先使用 ps 查找重度 CPU 用户的 PID，然后使用 top 持续监视它，然后使用kill -9 杀死它，你对这种组合的研究越深入，你就越能真正了解进程的氛围。

linux查看进程命令

嗯，昨晚调试代码的时候，服务一直挂着，CPU使用率高达9 8 %。
我快速打开终端并输入 ps aux | grep myservice。
屏幕上充满了进程。
我盯着每一行，终于找到了有问题的进程。
接下来是一系列的参数，包括-D选项，当时我并没有太在意。
但实际上这个命令是有效的。
我查了手册，发现a显示了所有用户的进程，x显示了没有终端的进程，u在前面列出了用户信息。
这很有趣。
Linux命令喜欢像这样堆叠参数。
它很难学，但很容易使用。
等等，还有别的事。
-f 全尺寸显示。
上次我看到系统崩溃日志时只有乱码。
由于STIME时间戳太早，系统自动补上了乱码。
突然我注意到我不常使用的-e选项显示了所有进程，包括内核进程？一定要尝试一下。