ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm rebuilding a part of my conky and have noticed that the built in top command doesn't actually return total cpu usage, but only on a per processor basis, so I'm trying to extract the information that I want using the top command.
I want the top 4 processes, only by name and processor usage, and this is what I have:
Code:
top -b -n 1 | grep -Ev top | head -11 | tail -4 | sed 's/^.* [A-Z] *\([0-9]*\).*\.[0-9]\{2\} \(.*\)/\2 \1 /g'
Now, it does work and provides exactly what I want, but I'm sure there must be a more efficient way of doing it. Any ideas?
Note - the grep part is to exclude the top command itself from the returned results. I know that using top in interactive mode I could get the information from top without all the parsing, but I can't find a way to do it directly without interactive mode.
NB. I'm including conky formatting codes in the substitution which I've stripped out for the purpose of this post.
AFAIK, top simply reads from the /proc filesystem, and you can probably find all of the information you want there, without resorting to attempting to parse the output of top. The format of the data in /proc pseudo-files is more likely to remain constant, than will the format of the output of top.
Thanks for the suggestion. awk is something I still need to study, but I did a test and the time for your suggestion to execute is practically identical to the time for mine. Incidentally, your sort command failed with "+9 file not found". I've never used sort so not sure what it does. I simply did the timed tests without the sort.
@theNbomr,
Interesting. I had a look through /proc, and whilst I can find the processes and the names I'm not sure where exactly the cpu usage comes from. Nevertheless, as best as I can see I would have to walk the /proc FS to establish the same information, which would be essentially recreating what top does anyway (probably much less efficiently). It does, however, explain why top is so slow to return the information (0.5 seconds here).
Thanks for the suggestion. awk is something I still need to study, but I did a test and the time for your suggestion to execute is practically identical to the time for mine. Incidentally, your sort command failed with "+9 file not found". I've never used sort so not sure what it does. I simply did the timed tests without the sort.
I think top command needs a few seconds to compute CPU usage
For the sort command, maybe sort -r -k9 would work...
Also I just see top output more carefully and cpu field number is 9, not 10 (awk should print $9 instead of $10)
Some time perusing manpages would be well spent methinks. Anything (well, most) in /proc is documented in "man proc". Also note the warning in "man top" - under BUGS.
Top output is user controllable - including sort key and column placement. This can make it difficult aligning suggestions to a particular setup.
Personally I've always found awk best for this, but I don't know if conky would like all that shelling out to run separate commands.
/proc/stat
kernel/system statistics. Varies with architecture. Common entries include:
cpu 3357 0 4313 1362393
The amount of time, measured in units of USER_HZ (1/100ths of a second on most architectures,
use sysconf(_SC_CLK_TCK) to obtain the right value), that the system spent in user mode, user
mode with low priority (nice), system mode, and the idle task, respectively. The last value
should be USER_HZ times the second entry in the uptime pseudo-file.
In Linux 2.6 this line includes three additional columns: iowait - time waiting for I/O to com‐
plete (since 2.5.41); irq - time servicing interrupts (since 2.6.0-test4); softirq - time ser‐
vicing softirqs (since 2.6.0-test4).
Since Linux 2.6.11, there is an eighth column, steal - stolen time, which is the time spent in
other operating systems when running in a virtualized environment
Since Linux 2.6.24, there is a ninth column, guest, which is the time spent running a virtual
CPU for guest operating systems under the control of the Linux kernel.
page 5741 1808
The number of pages the system paged in and the number that were paged out (from disk).
swap 1 0
The number of swap pages that have been brought in and out.
intr 1462898
This line shows counts of interrupts serviced since boot time, for each of the possible system
interrupts. The first column is the total of all interrupts serviced; each subsequent column is
the total for a particular interrupt.
disk_io: (2,0):(31,30,5764,1,2) (3,0):...
(major,disk_idx):(noinfo, read_io_ops, blks_read, write_io_ops, blks_written)
(Linux 2.4 only)
ctxt 115315
The number of context switches that the system underwent.
btime 769041601
boot time, in seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC).
processes 86031
Number of forks since boot.
procs_running 6
Number of processes in runnable state. (Linux 2.5.45 onwards.)
procs_blocked 2
Number of processes blocked waiting for I/O to complete. (Linux 2.5.45 onwards.)
Ok - perhaps my "I don't know" was misleading. Whilst I can see the value of /proc/stat for identifying overall CPU usage, I can't see a way to separate the usage out to identify an individual task's CPU usage.
No. Using conky's built in top function only provides the top process on a "per processor" basis rather than overall CPU usage. For example, I run a server that uses approx 25 - 39% CPU, but conky's built in function only ever reports 8% - 9%. The server is multi threaded, and the conky function only reports usage for one core, rather than total percentage of all cores. Top reports it correctly, hence my desire to use the system top rather than the conky top.
EDIT: I should add that this is probably another one of my computer obsessive behavioural traits (more over at the Arch forums - https://bbs.archlinux.org/viewtopic.php?id=129022) and I use the top readout in conjunction with temperature readouts to make sure that everything is kinda OK. Joys of a self-built system that really needs re-building - personal paranoia.
Okay, now (I think) I understand. Sorry for contributing to the confusion.
If you know the PID of the process, it seems that /proc/[pid]/stat provides the aggregate CPU time statistics. In fact, in reading the proc man page, it isn't clear how the individual processor statistics are acquired.
All the data is in there - getting it and doing the math is a pain. Top is easiest, but as I said, I don't know if I'd want to use it on a constant basis shelled out from something like conky.
The problem I have is, using bash (which is how I get the information for conky using top) I can't imagine that I could write a script that would be faster than top when it would have no choice but to walk the top filesystem. If you know a way to speed it up, I'd be happy to be corrected. As it stands, I have conky updating each second (apart from one or two items that I've extended deliberatley, such as my google calendar appointments script which I only run every 30 seconds). I can afford a half second each cycle, though it does on occasion freeze conky longer, usually if I'm doing something else more processor intensive.
I could drop the conky output to each two seconds for example, or 5 seconds, which for purpose I guess would be OK, but then my Computer OCD would kick in again that I'm not getting the update often enough.
Until someone can come up with a faster solution than top (which is the bottleneck it seems, not the grep, not the sed, and not awk) I'm probably stuck with either conky's limited functionality or the .5 second delay.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.