Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I've used 'top', but I need a tool that can give me an arbitrary-time history of threads that have executed on my system (CentOS 5.4)?

share|improve this question

migrated from stackoverflow.com Dec 8 '09 at 20:26

This question came from our site for professional and enthusiast programmers.

9 Answers 9

This command is useful in shell scripts or cron jobs for easy parsing, because it will only print a number. You can easily check if sum is greater than a threshold for your monitoring.

grep -s '^Threads' /proc/[0-9]*/status | awk '{ sum += $2; } END { print sum; }'

for me, prints:

share|improve this answer
This is useful on embedded systems, which have a stripped down version of top, which is missing the above features. –  Trevor Aug 20 at 14:16

See sar, part of the sysstat package by Sebastien Godard.

The sar command writes to standard output the contents of selected cumulative activity counters in the operating system. [...] The collected data can also be saved in the file specified by the -o filename flag, in addition to being displayed onto the screen. [...] By default all the data available from the kernel are saved in the data file.

share|improve this answer

use the ps command.

From the man page, there are a few thread options:


-H Show threads as if they were processes

-L Show threads, possibly with LWP and NLWP columns

-T Show threads, possibly with SPID column

-m Show threads after processes

share|improve this answer

I like htop. It's like top, but colour coded and with more features.

lsof is good if you want something more advanced. Here's an excellent lsof tutorial.

share|improve this answer
When using htop, press t to get a nested tree of threads. –  ltn100 Dec 17 at 14:41

run top, then hit 'H' to toggle thread listing

share|improve this answer

lsof is a great utility to list open files and threads

share|improve this answer

I am not aware of a logging solution in a single application. However, working with the more general logging / monitoring framework Zabbix I created the following definition to collect data on threads used by the application I wanted to monitor:

UserParameter=myapp.threads,ps --no-headers -L -p$(pgrep -x myapp)|wc -l

This one-line entry in the config makes Zabbix report, under the token 'myapp.threads' the number of threads seen each time the snippet is run. This picks up the process id via a first call to pgrep, then lists all threads using ps -L and counts them via wc -l.

Not the most elegant solution but it got the job done in a few minutes. Now, with Zabbix databasing and reporting, I can look at this through time. Of course, you probably wouldn't want to install Zabbix just for this.

share|improve this answer

ps -eLf will give you a list of all the threads and processes currently running on the system.

However you ask for a list of all threads that HAVE executed on the system, presumably since some arbitrary point in the past - are you sure that is what you mean? You could run ps as a cron job and poll the system every X minutes, but you would miss threads that were born and died between jobs. You would also have a huge amount of data to deal with.

share|improve this answer
you also use watch ps command in order to constantly see the current threads, not history related, still quite useful –  Tim Jun 13 at 13:22
Just a note to those of you who think you know the "eLf" idiom - the capital L matters. You will not get all threads if you use lower case l. –  Sridhar-Sarnobat Jul 22 at 5:09
@Tim watch doesn't monitor continuously, but polls repeatedly; on my system the interval defaults to 2s. –  boycy Sep 17 at 11:51
@boycy you can adjust the interval to the duration as you like say 100ms and getting the feeling of continuity :) –  Tim Sep 17 at 19:44

I think Linux has process auditing support. You might be able to get that set up to log every thread-creation. I don't know how to do this; I've never wanted to add overhead to kernel functions that are supposed to be fast. :/

share|improve this answer

Your Answer


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