Clear questions and runnable code
get the best and fastest answer
Re^2: Memory Monitoringby steelrose (Scribe)
|on Apr 29, 2005 at 15:15 UTC||Need Help??|
Last week I tried the Proc::ProcessTable() module. Unfortunately in its build package, it installs an executable. This is bad, because were not supposed to install executables on our production system.
In the /proc/<pid>/psinfo file, the pr_psargs is an 80 character string that contains the complete command line. The pr_psargv and pr_envp fields are memory addresses that are basically offsets inside the /proc/<pid>/as file (address space).
The reason I need the complete command line are for java apps. Imagine having a classpath and env vars. You can see how quickly your command line grows above the 80 characters. In these cases, doing a grep to kill particular processes can be very dangerous.
Anyway, the /proc/<pid>/as file is only readable by the person who owns the process. /usr/ucb/ps is owned by root and can read anyfile, so it doesn't have a problem.
I really wasn't trying to "Reinvent the wheel" as your post was saying. Just trying to use what we have available and won't cause a problem with the Unix admins.
So I went back to the simpliest way to do it. A pgrep with a /usr/ucb/ps -auxww <pid>. Then I parse out the memory and cpu statistics. Not happy about the solution, but it works...
And now I know more about the internals of Solaris's proc directory :)
Thanks to all the Monks who replied.
If you give a man a fish he will eat for a day.
If you teach a man to fish he will buy an ugly hat.
If you talk about fish to a starving man, you're a consultant.