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> 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? |
Quote:
Quote:
Quote:
Quote:
|
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. |
Thank you for your responses!
Quote:
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:
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... |
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.
|
Quote:
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 11:44 PM. |