Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

In order to measure a user's total CPU time, I'm using the "utime" field out of /proc/[pid]/stat:

utime %lu   Amount of time that this process has been scheduled in user
            mode, measured in clock ticks (divide by
            sysconf(_SC_CLK_TCK).  This includes guest time, guest_time
            (time spent running a virtual CPU, see below), so that
            applications that are not aware of the guest time field do
            not lose that time from their calculations.

(from man proc (5))

So, my "user utime" is the sum of the utime of all PIDs this user is running.

I'm hoping this will give me an accurate value for the number of CPU seconds this user has spent. Am I on the right track?

Some of the things I don't understand or take into account yet:

  • Each PID also has a parent PID (or zero). But I'm counting every PID, not just the ones with a ppid of 0. Is this correct?
  • There are, in addition to utime, stime, cutime and cstime. Do I need to worry about those? I'm assuming that utime is the total number of cpu seconds for a PID, not counting the parent.

If I calculate the system's total cpu time using /proc/uptime, this value is fairly close to my sum for all users, but the difference is significant. For instance (in minutes):

system cpu_time:         96.13
sum of users_cputime:   111.45

Correction:

I get "sensible looking" values for all kinds of things. At the moment I'm using the sum of utime, stime, cutime and cstime. And it reports values that, while I don't understand them, correlate very well with measurements from time.

If I am completely on the wrong track, there's another question:

share|improve this question
    
/proc/cputime doesn't have any information about the time spent by the CPUs executing processes, so I'm puzzled what your “system cpu_time” calculation is. If you're doing something with the second number, it's the time spent by the idle task; I don't know exactly what that means in practice. –  Gilles Feb 24 '12 at 19:24
    
Your “user time” would have to add the utime values from all dead processes as well. How do you take those into account? –  Gilles Feb 24 '12 at 19:27
    
Mhh. What I call "system cpu time" is merely the first value from /proc/uptime, "system seconds". I would've thought this was too high, as it also counts kernel threads, but as you can see the sum of all "utime" values is still higher than the system time from /proc/utime. Your link, as far as I can tell, explains why. Though to be clear: I'm not interested in that number really. I'm interested in "per-user cpu time". –  Stefano Palazzo Feb 24 '12 at 19:31
    
As for the second comment: For the moment, I was planning on measuring this periodically (say every second), which would ignore short-lived processes. –  Stefano Palazzo Feb 24 '12 at 19:32
    
So your system cpu time calculation is ($1-$2/$number_of_cups) where $1 and $2 are the values from /proc/uptime? Then I guess the I/O attributed to the idle task would explain the difference. I don't know anything about the topic, so I suspect I'm missing something major: I wouldn't expect so much to happen in the idle task, especially considering that your sum of users cputime is likely missing a lot of short-lived processes. –  Gilles Feb 24 '12 at 19:57
add comment

1 Answer

The traditional way to log and track user CPU time is process accounting. On Linux, install the GNU accounting utilities, typically provided by a package called acct. I'm not sure how accurate it will be at keeping track of the time spent in very short-lived processes, but it'll at least list all the processes ever executed.

Run lastcomm to get a list of all the commands executed by any user and the time spent in each (rounded to ~10ms for short-lived processes, expect to see a lot of 0.00). Run sa to display various sums and statistics. In particular, sa -m displays per-user totals. The statistics accumulated by sa run from the last rotation of the accounting logs (typically located in /var/log/account/).

Note that you aren't going to catch all processes by sampling at intervals, not by a far cry. You'll miss almost all short-lived processes and the last few seconds of long processes. Process accounting does list all past processes.

In /proc/$pid/stat, the user time is the time spent doing computation, as opposed to the system time spent doing I/O. Which one to count depends on what you want to do with the information.

Counting all the PIDs is right. I don't know what the parent PID has to do with this.

On the system side, your description of /proc/uptime seems wrong. Wikipedia has it right as I write. The first field is the real time elapsed since the system booted, minus any time spent suspended or hibernating. The second field is the cumulated time spent in the idle task on all CPUs. I'm not sure what that really means; it's certainly not the total idle time on my machine. In the kernel, the value is summed in uptime_proc_show from variables updated in account_idle_time.

share|improve this answer
    
What about very long running processes? Does sa wait for the process to quit before reporting it's cpu time? –  Stefano Palazzo Feb 25 '12 at 11:48
    
@StefanoPalazzo Yes, accounting data is written when a process dies. That also means you get no data for processes that were running after a system crash, as far as I know. –  Gilles Feb 25 '12 at 20:09
    
That's a problem - it means I can't use it, as we'll have a lot of long-running processes. –  Stefano Palazzo Feb 26 '12 at 13:47
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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