Nathan,
On 5/11/2014 10:35 PM, Nathan Scott wrote:
Hi Martins,
It is good to hear someone's become interested in this topic again!
----- Original Message -----
Hello,
I have started looking into reviving the hotproc pmda. Before I
get too far into it, I wanted to make sure no one else was looking at it
and if my approach looks reasonable.
OK, I looked into both the cgroup integration that you mentioned and the
client side implementation that Frank suggested and couldn't really come
up with a clean way of implementing either, mostly due to my lack of
confidence in managing the cgroup hierarchy and keeping everything in
sync. So I just went ahead for now and did a straight up integration
with the existing proc pmda. If you decide you want to present the
information in cgroups in the end, hopefully this could at least be a
starting point, since the process selection, config parsing, etc would
still need to be done.
This version works, *but* likely has more cleanup to go if this is
an ok way forward. This is on my hotproc branch on github. I've also
attached a cumulative patch and git log since over the course of
development there were a bunch of changes and refactors and the linear
history might be confusing.
*******
github.com/ubccr/pcp/tree/hotproc
*******
Some notes on this implementation:
1. I tried to keep as much functionality as I could from the sgi version
but its been quite a while since we ran it and haven't had this hardware
for quite some time! There are a few things missing that I discuss below.
2. If you recall, the original hotproc pmda used a series of scripts to
duplicate the proc pmda and then overlay the hotproc functionality as a
separate pmda. Instead of having a separate pmda, I merged it into
linux_proc for ease of maintenance. I modified the root_proc file by
hand for now, but that could likely be done with an awk script as before
as part of the build process.
3. What should the default state of hotproc be given that proc is
usually always running? Should there be some default config file to
have some metrics available or should it be disabled (timer doesn't run,
etc) if the user does not provide a config file? I have provided a
sample that is a simplification of what we are currently using.
4. Many of the changes are actually pretty self contained. The biggest
change was in proc_pid where I needed to change the assumption that
there was only one list of processes that we cared about. This resulted
in having to change a bunch of the functions to take a process list to
operate on.
5. Some stats I couldn't find per process yet: syscalls (systemtap seems
to be the only way to get these?) , and schedwait (doesn't seem to be
available at all).
6. idletime is provided by the linux pmda. I just re-implemented this
small part of code. Is there an alternative way to do inter pmda fetches?
7.Some cleanups and error checking still to do. The original code used
lots of "externs" and I started to factor those out, but then saw use
in other pmdas so maybe thats not a concern?
8. I realize there is a lot to cleanup yet: commented out old code,
debugging left on, maybe some memory leaks, etc but wanted to make sure
there were no show stoppers before I kept going. Also, some of the data
types might might not be correct, i.e converting some of the long and
long long types in the original code.
9. I'm open to any and all suggestions as having this available makes
logging proc much more manageable for us. I have it running in a couple
of VMs right now and will be deploying further over the next week.
Thanks for any comments.
Martins
git.log
Description: Text document
hotproc.diff
Description: Text document
|