LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (http://www.linuxquestions.org/questions/programming-9/)
-   -   More efficient way to obtain process-related information: ps or /proc ? (http://www.linuxquestions.org/questions/programming-9/more-efficient-way-to-obtain-process-related-information-ps-or-proc-773702/)

Black_Light 12-05-2009 03:22 PM

More efficient way to obtain process-related information: ps or /proc ?
 
I am currently working on a software product (on RHEL4) which includes a process monitoring application. The application is supposed to find information about all the processes included in the software product.

Currently, this is accomplished through a
Code:

ps -aef | grep <procname>
command (run using psopen()) which is run at regular intervals.

This seems pretty extraneous to me, so I searched for a different method to obtain process-related information just from the process name.

There doesn't seem to be a direct method; the only alternative I can think of is to sift through the whole of /proc and find out the process' information by searching by its name.

Would this be more efficient, or would the performance improvement be minuscule?


P.S. I might also have to take care of the dynamic nature of the /proc filesystem, isn't it?

jhwilliams 12-05-2009 03:28 PM

Quote:

Originally Posted by Black_Light (Post 3781156)
Code:

ps -aef | grep <procname>

This doesn't seem so bad to me. You could use pgrep, I suppose -- a little more to the point.

Quote:

command (run using psopen()) which is run at regular intervals.
Prithee, what is psopen?

Quote:

Would this be more efficient, or would the performance improvement be minuscule?
I would not imagine that it would be more efficient.

Quote:

P.S. I might also have to take care of the dynamic nature of the /proc filesystem, isn't it?
"Dynamic" eh? I think most file-systems are dynamic. But yes -- whenever you mess with /proc you should be concerned that your reading process might hit a file that causes it to block for a long time.

syg00 12-05-2009 04:01 PM

Every "monitoring" command probably sifts through /proc - that's what it's there for. Certainly "ps" does.
I'd suggest you look at the manpage - ps can be filtered any way you want, and you can even request no headers. Generating output for every pid, then reading the whole lot again merely to toss most away is poor design. The grep call is superfluous I would imagine.
You *may* be able to write the trawling through /proc more effeciently (than ps), but you'll do better concentrating elsewhere. That can always be done later. Most of the data you're after should be under /proc/<pid>/* - you should know the pid(s) of interest.
As for the concerns re the "dynamic nature" of /proc - that's what /proc is by definition. It's a pseudo filesystem - and doesn't "exist" as a real filesystem. The data you see as "files" in /proc is created in response to a call to view it. Use it without concern, but it *will* change between calls. Use ps to do the math for you.

Black_Light 12-05-2009 04:33 PM

Thank you for your responses!


Quote:

Prithee, what is psopen?
Apologies. That should be popen().

I was specifically thinking about the cost of the calls to popen(). If I were to have an inbuilt function that would accomplish the same thing as ps, I might improve performance by the amount of the cost of popen()... (would that be negligible?)

Quote:

The data you see as "files" in /proc is created in response to a call to view it.
Okay, that answers a lot of questions.

However, what would happen if, say, I open a "file" from /proc/<pid>/ , and the corresponding process terminates before I read something from that "file"?

Also, I don't have a list of the pids I need to monitor as of now, but that can be done...

syg00 12-05-2009 06:23 PM

At some point the process will "go away" - you have to accommodate that. Likewise it may restart/spawn under a different pid. Standard error recovery situations.

cyent 12-06-2009 03:22 PM

Quote:

Originally Posted by syg00 (Post 3781181)
Every "monitoring" command probably sifts through /proc - that's what it's there for. Certainly "ps" does.

syg00 is quite right....

strace -o tlog ps -aef;grep '/proc' tlog
open("/proc/version", O_RDONLY) = 3
open("/proc/stat", O_RDONLY) = 3
open("/proc/self/stat", O_RDONLY) = 3
open("/proc/uptime", O_RDONLY) = 3
open("/proc/sys/kernel/pid_max", O_RDONLY) = 4
open("/proc/meminfo", O_RDONLY) = 4
stat64("/proc/self/task", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 5
stat64("/proc/1", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/1/stat", O_RDONLY) = 6
open("/proc/1/status", O_RDONLY) = 6
open("/proc/1/cmdline", O_RDONLY) = 6
stat64("/proc/2", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/2/stat", O_RDONLY) = 6
open("/proc/2/status", O_RDONLY) = 6
open("/proc/2/cmdline", O_RDONLY) = 6
stat64("/proc/3", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/3/stat", O_RDONLY) = 6
open("/proc/3/status", O_RDONLY) = 6
open("/proc/3/cmdline", O_RDONLY) = 6
stat64("/proc/4", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/4/stat", O_RDONLY) = 6
open("/proc/4/status", O_RDONLY) = 6
open("/proc/4/cmdline", O_RDONLY) = 6
stat64("/proc/5", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/5/stat", O_RDONLY) = 6
open("/proc/5/status", O_RDONLY) = 6
open("/proc/5/cmdline", O_RDONLY) = 6
.
.
.


All times are GMT -5. The time now is 03:37 PM.