嗯,我刚刚发现,随着pidof
in的广泛使用间隔很短,看似微小的工具也可以是一个伟大的工具占用CPU。 (来源top
:)
在我的旧机器上,它可以轻松达到 30% 的峰值,尤其是在批量使用中,尽管时间很短,但我认为对于像查找进程的 PID 这样的简单任务,此类工具的占用空间应该是 的五分之一pidof
(如果有的话)。
这也是为什么我想知道使用内置标准工具“构建”进程 ID 的查找是否可能更明智。如果和执行整个管道造成的 CPU 负载设法保持不变以下独立运行造成的负载pidof
。
此外,了解一下会很有趣什么造成了这些高峰。也许你们当中有人对pidof
代码进行了更深入的研究? :)
答案1
以下是查找名为“apache2”的进程的 pid 的一些示例。它们之间存在细微差别(输出中的换行符),pidof
但在管道等中应该工作相同。
使用pidof
:
$ pidof apache2
31751 31750 31749 31748 31747 31489 31488 31487 31486 31485 1500
换行符分隔:
$ ps aux | grep apache2 | grep -v grep | awk -n '{print $2}'
1500
31485
31486
31487
31488
31489
31747
31748
31749
31750
31751
空格分隔:
$ ps aux | grep apache2 | grep -v grep | awk -n '{printf $2" "}'
1500 31485 31486 31487 31488 31489 31747 31748 31749 31750 31751
我对上述命令做了一些愚蠢的计时。
$ date +%T:%N; pidof apache2 ; date +%T:%N
17:06:05:627088798
31751 31750 31749 31748 31747 31489 31488 31487 31486 31485 1500
17:06:05:634500908
$ date +%T:%N; ps aux | grep apache2 | grep -v grep | awk -n '{printf $2" "}' ; date +%T:%N
17:06:29:887314682
1500 31485 31486 31487 31488 31489 31747 31748 31749 31750 31751
17:06:29:903997288
pidof: 7,412,110 纳秒
附:|查询 | awk:16,682,606 纳秒
在我的机器上,pidof
加载速度更快(如预期)。
的输出pidof
似乎是反向排序的,所以这将是我首选的替代咒语:
$ ps aux | grep apache2 | grep -v grep | awk -n '{print $2}' | sort -rn
31751
31750
31749
31748
31747
31489
31488
31487
31486
31485
1500
答案2
pidof
我同意飙升至 30%很奇怪。但如果这只是暂时的飙升,那会是一件坏事吗?
或者你可以使用ps(1)
.例子:
$ ps ax | grep firefox
8621 ?? S 5:20.24 firefox
10409 p3 R+ 0:00.00 grep firefox
答案3
有一组命令来管理进程(pgrep、pkill 等);所以,最好的选择是(对于 macOSX):
$ ps -ef | pgrep login
102
103
6245
6361
...或者,按相反顺序:
$ ps -ef | pgrep login | sort -rn
6361
6245
103
102
...或者,最后一个:
$ ps -ef | pgrep login | sort -rn | head -n 1
6361