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? :)

  • 1
    How do you use pidof command? Is it something like pidof firefox? – Ramesh Oct 22 '14 at 18:54
  • 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
  • 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
  • 2
    Just asked a related question which you may find useful - unix.stackexchange.com/questions/163681/… – Graeme Oct 22 '14 at 20:39
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
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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.