Understanding PS Elapsed Time Format for Long Running Processes

processpstime

I'm using a ps command as part of an exercise to identify processes running longer than a given threshold.

I'm using the following template to get the elapsed time for a know process command:

ps -eo etime,command | grep <something to identify a process> | grep -v grep | awk '{print $1}'

I notice with short-running processes, the etime (elapsed time) value takes the format minutes:seconds and from this I can easily determine how long a process has been running.

For very long running processes (days long), I don't understand the format.

I have a MySQL server process that htop shows as running for 126 hours.

Executing ps -eo etime,command | grep mysql | grep -v grep | awk '{print $1}' gives me a value of 9-03:35:32.

My best guess is that this means 9 something, 3 hours, 35 minutes, 32 seconds. I can't figure out what the units are for the 9.

The process in question has been running 126 hours, about 5.25 days. This suggests that the 9 in the above output does not represent days. They can't be half days either as (9 * 12) hours + 3 hours + 35 minutes + 32 seconds is less than 5 days.

How do I interpret the elapsed time value I am seeing for long-running processes? What units accompany the 9 in the above output?

Best Answer

According to the standard:

In the POSIX locale, the elapsed time since the process was started, in the form:
[[dd-]hh:]mm:ss
where dd shall represent the number of days, hh the number of hours, mm the number of minutes, and ss the number of seconds. The dd field shall be a decimal integer. The hh, mm, and ss fields shall be two-digit decimal integers padded on the left with zeros.

So, the 9 means days, whether you believe it or not. Could you be misinterpreting the output from htop? What does top (which has a time format of minutes:seconds) say? Are you certain that the field you are looking at in htop is equivalent to etime? (for example, could it means 126 minutes of CPU time?)

Related Solutions

How Other Processes Affect Measurements with time Command

No. Process/context switches aren't free.

How much other processes running will slow yours down is very system-dependent, but it consists of things like:

Every time a processor switches to a different address space (including process), then the MMU cache must be flushed. And probably the processor L1 caches. And maybe the L2 and L3 caches. This will slow down memory access right after your process is resumed (and this counts against your "user" time).
On a SMP (or multi-core) box, if two processes are trying to access the same parts of (physical) RAM, the processors must cooperate. This takes time. It is often done at a architecture level, below even the OS. This will count against your user or sys time, depending on when it hit.
Quick kernel locking (that doesn't actually schedule another process) will count against your sys time. This is similar to the point above.
on NUMA boxes, you may get moved to a different node. Memory access may now be cross-domain, and thus slower
other processes may influence power management decisions. For example, pegging more cores will reduce Intel Turbo Boost speeds, to keep the processor package inside its electrical & thermal specs. Even without turbo boost, the processor may be slowed due to excess heat. It can work the other way too—more load may cause the CPU speed governor to increase the CPU speed.

There are other shared resources on a system; if waiting for them doesn't actually involve your process sleeping, then it'll get counted against your user or sys time.

Kernel Process Scheduling – Real Time Processes Scheduling in Linux

Question 1

It is possible for an user to use real time priority for a process as well. This configuration could be set from /etc/security/limits.conf file. I see the below contents in that file.

# /etc/security/limits.conf
#
#Each line describes a limit for a user in the form:
#
#<domain>        <type>  <item>  <value>

If we check the item section, we see the below entry which enables to set a real time priority for the users.

#        - rtprio - max realtime priority

Question 2 and Question 3

To set scheduling policy to SCHED_FIFO, enter:

chrt -f -p [1..99] {pid}

To set scheduling policy to SCHED_RR, enter:

chrt -r -p [1..99] {pid}

So to answer question 3, we should verify the scheduling algorithms available and the priorities using the chrt -m command and then use any scheduling algorithm that suits our need. To set different priorities, we could use the commands as above.

Best Answer

Related Solutions

How Other Processes Affect Measurements with time Command

Kernel Process Scheduling – Real Time Processes Scheduling in Linux

Related Question