2

Well, I've just found out that with extensive usage of pidof in very short intervals, the seemingly tiny tool can be a great CPU hog. (Source: top)
On my older machine, it can easily reach 30 percent peaks especially in batch usage, though only for a short time, but I think that for a simple task like finding the PID of a process, the footprint of such tool should be one fifth of pidof's (if at all).

That is also why I wonder if it might be more sensible to "construct" the finding of the process ID with built-in standard tools. It would not be surprising to me if the sum of CPU load caused by executing the whole pipe managed to stay below the load caused by running pidof standalone.

Furthermore, it would be interesting to know what is causing these high peaks. Maybe there is even somebody here amongst you guys who has dug a little deeper into the pidof code? :)

syntaxerror
  • 2,236
  • 2
  • 27
  • 49
  • 1
    How do you use `pidof` command? Is it something like `pidof firefox`? – Ramesh Oct 22 '14 at 18:54
  • Well, you could use `lsof -c firefox` to list all files opened by a particular command. It lists the pids as well. So it could be tweaked as a smaller footprint. – Ramesh Oct 22 '14 at 18:57
  • 3
    It would be _very_ surprising to me if you could get it better than pidof. Anyway, please tell us how exactly you are using `pidof` and bear in mind that a high CPU usage is not necessarily a bad thing. It is only a problem if you don't have enough to go around. Do these spikes also happen when that 30% would make a difference? Finally, and most importantly, if you are running it repeatedly, presumably via a bash loop, it is almost certainly bash and not pidof itself that is causing the spike. – terdon Oct 22 '14 at 18:58
  • 1
    If using `pidof` gets you up to 30% it's definitely not the tool. All it does is read `/proc/%s/exe` and that's about as lightweight as you can get. – Bratchley Oct 22 '14 at 19:00
  • @Ramesh yes, like `$(pidof firefox)` in a `bash` script, for instance. @terdon `bash` might indeed be the actual culprit, yes. However that's merely speculating. :) BTW, it's just that I think such easy task *ought not* produce these spikes. Whether there is still some air to breathe for my CPU or not, does not matter here. – syntaxerror Oct 22 '14 at 19:01
  • 1
    How long does it peak at 30% for? Just the process of loading the program could cause a spike. You could compare with something like `/bin/true` to check this (be sure to use the actual program though and not a shell builtin). – Graeme Oct 22 '14 at 19:09
  • Thanks for the `true` tip. (Instead of prefixing the path, `env true` should do the trick.) Peaks are usually short, as I wrote in the OP. But considering that `pidof` might be executed *several times* per one second, lots of high peaks can be significant as well. – syntaxerror Oct 22 '14 at 19:15
  • 2
    Just asked a related question which you may find useful - http://unix.stackexchange.com/questions/163681/print-pids-and-names-of-processes-as-they-are-created – Graeme Oct 22 '14 at 20:39
  • 1
    pidof takes a fraction of a second to run, but during that time it isn't doing any sleeping, it's either using the CPU or reading in-memory files. So if you happen to catch it with ps or top, it will appear to be using a high percentage of CPU time. As for an alternative, it depends what problem you're trying to solve. It's simpler to have the target process write its PID to a file in a known place, such as /var/run, if you can. – Mark Plotnick Oct 22 '14 at 21:14
  • ... and read it out. That's a good approach, even though I'm always so reluctant with using temp files. In fact, your method is not much different from that of a computer graphics artist who reads off a sine table for periodically repeating values instead of *computing* the "live" sine several thousand times per minute. It's closer to the matter than you think: running `pidof` an uncountable number of times even though the PID might be still unchanged is pretty much the same thing. Thank you very much, I think I *will* (albeit reluctantly) try to use a temp file. – syntaxerror Oct 22 '14 at 21:45

3 Answers3

1

Here are some examples to find pids of processes named "apache2". There are minor differences (newlines in output) between these and pidof but otherwise ought to work the same, in pipelines, etc.

Using pidof:

$ pidof apache2
31751 31750 31749 31748 31747 31489 31488 31487 31486 31485 1500

Newline-separated:

$ ps aux | grep apache2 | grep -v grep | awk -n '{print $2}'
1500 
31485 
31486 
31487 
31488 
31489 
31747 
31748 
31749 
31750 
31751

Space-separated:

$ ps aux | grep apache2 | grep -v grep | awk -n '{printf $2" "}'
1500 31485 31486 31487 31488 31489 31747 31748 31749 31750 31751

I did some silly timings of the above commands.

$ 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 nanoseconds

ps | grep | awk : 16,682,606 nanoseconds

On my machine, pidof is loads faster (as expected).

The output of pidof seems to be sorted reverse, so this would be my preferred alternative incantation:

$ ps aux | grep apache2 | grep -v grep | awk -n '{print $2}' | sort -rn
31751
31750
31749
31748
31747
31489
31488
31487
31486
31485
1500
Dan Stoner
  • 94
  • 2
0

I agree that it is weird that pidof is spiking to 30%. But if it's just a temporary spike would that be such a bad thing?

Alternatively you could use ps(1). Example: 

$ ps ax | grep firefox
8621 ??  S       5:20.24 firefox
10409 p3  R+      0:00.00 grep firefox
Johnathon Scott
  • 1
  • 3
0

There is a set of command to manage processes (pgrep, pkill, etc.); so, the best option is (for macOSX):

$ ps -ef | pgrep login
102
103
6245
6361

... or, in reverse order:

$ ps -ef | pgrep login | sort -rn
6361
6245
103
102

... or, the last one:

$ ps -ef | pgrep login | sort -rn | head -n 1
6361
Carlos Camargo
  • 1
  • You don't need the initial `ps -ef`: `pgrep` already scans the process list on its own, so your examples are doing it twice. – FGM Nov 29 '20 at 15:19