This is the mail archive of the
systemtap-cvs@sourceware.org
mailing list for the systemtap project.
[SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-1.4-372-g4de61fb
- From: dsmith at sourceware dot org
- To: systemtap-cvs at sourceware dot org
- Date: 18 May 2011 15:27:56 -0000
- Subject: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-1.4-372-g4de61fb
- Reply-to: systemtap at sourceware dot org
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "systemtap: system-wide probe/trace tool".
The branch, master has been updated
via 4de61fbe265a40bc91c73a0c96c2daaeab02b29c (commit)
via 7ecf89a9e47823c3ebe2078b5d56396061a57af8 (commit)
via 1172a8a396cac718c7143b67cdc925e557228d6e (commit)
from 11c6c5099fb750e90f7ecdeb901897f3b184a714 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 4de61fbe265a40bc91c73a0c96c2daaeab02b29c
Merge: 7ecf89a 11c6c50
Author: David Smith <dsmith@redhat.com>
Date: Wed May 18 10:27:47 2011 -0500
Merge branch 'master' of ssh://sources.redhat.com/git/systemtap
commit 7ecf89a9e47823c3ebe2078b5d56396061a57af8
Merge: 7502ddf 1172a8a
Author: David Smith <dsmith@redhat.com>
Date: Wed May 18 10:23:02 2011 -0500
Merge remote-tracking branch 'nathans/master'
commit 1172a8a396cac718c7143b67cdc925e557228d6e
Author: Nathan Scott <nathans@debian.org>
Date: Thu May 12 19:41:01 2011 +1000
Move (back?) to a select-based PMDA with custom main.
An observed problem with doing log reads only during the
metric fetch callback, is that we start getting behind in
events once the volume starts ramping up from small files
to the point that the PMDA is overwhelmed. Caused by two
issues:
- only reading new events based solely on client fetch
intervals means for relatively long intervals (say once
every few minutes) the consumption doesn't keep up with
the event generation.
- only reading once (i.e. one read(2) call) per fetch,
which made the above even more severe and noticable.
We address these issues by using a custom PMDA loop which
is awoken on either readable file descriptors or expiry of
a timer (iow server side driven event reading, not client).
Whenever we wake, we consume all available events at that
time for each file descriptor.
-----------------------------------------------------------------------
Summary of changes:
pcp/src/pmdas/logger/event.c | 27 ++++++-----
pcp/src/pmdas/logger/event.h | 4 ++
pcp/src/pmdas/logger/logger.c | 110 ++++++++++++++++++++++++++++++++---------
3 files changed, 106 insertions(+), 35 deletions(-)
hooks/post-receive
--
systemtap: system-wide probe/trace tool