Forum: Ruby /proc/PID/stat documentation?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (regularfry)
on 2007-01-06 19:30
(Received via mailing list)
Not strictly a Ruby question, but I figure someone around here will know
the answer...

I'm using the sys-proctable gem to gather process load information on a
Debian machine (kernel 2.6.15 if it's relevant), because I'm trying to
do some load-balancing between machines and processes on those machines.
  However, I can't seem to find any documentation on what the numbers
returned actually represent - specifically, the units of the utime,
stime, cutime and cstime fields, and precisely what they represent.

The numbers are lifted straight from /proc/PID/stat, so any
documentation on that would be handy.  I've checked the documentation in
the kernel source tree, but it was singularly unenlightening - unless I
missed something.

For example:

-- konsole_ps.rb --

require 'proctable'
require 'yaml'
konsole = Sys::ProcTable.ps.find{|p| p.name == 'konsole'}
y({'utime' => konsole.utime, 'stime' => konsole.stime, 'cutime' =>
konsole.cutime, 'cstime' => konsole.cstime})

-- output --
---
cutime: 0
utime: 82
stime: 9
cstime: 0

I don't understand what the numbers that come out represent, and I can't
really tie them up with what comes out of `ps`.  Can anyone point me in
the right direction?
934180817a3765d132193a5428f99051?d=identicon&s=25 Sylvain Joyeux (Guest)
on 2007-01-19 16:30
(Received via mailing list)
Try "man 5 proc", but I'm afraid it should be more or less the same
information than in the kernel docs ...

Sylvain Joyeux
1b30b43db5bb31e512825d86f4712bab?d=identicon&s=25 Cian (Guest)
on 2007-01-19 16:31
(Received via mailing list)
On 1/6/07, Sylvain Joyeux <sylvain.joyeux@polytechnique.org> wrote:
> Try "man 5 proc", but I'm afraid it should be more or less the same
> information than in the kernel docs ...
>
Yep, the proc(5) manpage explains what the *time variables mean.

The units are 'jiffies', which appear to be Linux kernel scheduler run
time intervals. There's an explanation of what jiffies are at

  http://kerneltrap.org/node/6857

Cian
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2007-01-19 16:31
(Received via mailing list)
Alex Young wrote:
>
> require 'yaml'
>
> I don't understand what the numbers that come out represent, and I
> can't really tie them up with what comes out of `ps`.  Can anyone
> point me in the right direction?
>
utime is the amount of time spent in user mode. If it's being
accumulated correctly, it will include time from both user and "nice"
mode. stime is the amount of time spent in system or kernel mode. If
it's being accumulated correctly, it will include system, irq and
softirq time.

cutime and cstime are the cumulative values of utime and stime,
respectively. When a process forks (clones) a child process (thread),
said child accumulates its own utime and stime. When the process exits,
its accumulated utime gets added back into the parent's cutime, and its
stime gets added back into the parent's cstime. Have a look at the
values for cutime and cstime for the "init" process -- they will be huge
because a parentless process cannot exist -- if a process's parent dies,
"init" adopts it. :)

Now on to "ps". "ps" lives in the "procps" package. It, for some reason,
lumps system and user time together. "ps" converts (utime+stime) to TIME
and (cutime+cstime) to CTIME. It shouldn't do that, but it does and IIRC
the developer of "procps" flat out refuses to change it. "top" is also
in "procps".

One final note: if you really need to know the next layer of detail down
to manage your server, send me an email off list and I'll point you to
some resources. I've never really seen a lot of documentation on this
other than the excellent O'Reilly book, "Understanding The Linux
Kernel", which isn't really written for server managers. Most of the
other books either have just the "top" layer (pun intended) or are
written around a specific tool set.

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (regularfry)
on 2007-01-19 16:31
(Received via mailing list)
Cian wrote:
>
Thanks - that's exactly what I was after.
7b3680c6d346834891793bde8f65eb6e?d=identicon&s=25 Chaim B. (chaim_b)
on 2011-09-07 10:14
A clarification:

There is a difference between forking a process, and spawning a thread
(pthread library in C).

In the case of forked processes, the utime/stime represent the parent
only. Once the forked processes die, their utime/stime are added to the
cutime/cstime of the parent.

In the case of spawned threads however, the parent continues to
accumulate utime/stime earned by its children, even if it is
sleeping/waiting for its children to join. On a multi-processor system,
these utime/stime parent counter increments will reflect the
parallelism. In the case of spawned threads, the parent's cutime/cstime
counters remain zero, even when the children die.

One most systems the "units" of time are 10 milisec. So a utime of 100
represents one second of CPU time.

To understand the usage breakdown of the parent and children threads, it
is necessary to go into the /proc/PID/task/ structure.
This topic is locked and can not be replied to.