perspective, I don't see any reason to start from here as a branch point. I
can fish out the commit with all the configure stuff when that actually
happens.
--dho
2015-02-03 13:54 GMT-08:00 Daniel Pocock dan...@pocock.pro:
On 03/02/15 22:30, Devon H. O'Dell wrote:
2014-10-30 18:05 GMT-07:00 J.T
(And as an aside, I'm sorry that my code held up a release for so long.)
2015-02-03 15:23 GMT-08:00 Devon H. O'Dell devon.od...@gmail.com:
2015-02-03 14:05 GMT-08:00 Daniel Pocock dan...@pocock.pro:
On 03/02/15 22:59, Devon H. O'Dell wrote:
I'm one of the CK developers interested. It's been
2015-02-03 14:05 GMT-08:00 Daniel Pocock dan...@pocock.pro:
On 03/02/15 22:59, Devon H. O'Dell wrote:
I'm one of the CK developers interested. It's been a PITA to find time
to get a DD to sign a key in person. Samy has just started a new company
and I'm pretty sure that's kept him busy
2014-10-30 18:05 GMT-07:00 J.T. Conklin j...@acorntoolworks.com:
Daniel Pocock dan...@pocock.pro writes:
- 3.7 adds a new dependency, Concurrency Kit
Given the problems you describe with Concurrency Kit, is it simply
premature for ganglia to depend on it? From what I can tell, its
use is
Holding locks around blocking syscalls is indeed not great. Using CK
locks in this codepath is not advisable; they are all spinlocks. (As
an aside, I somewhat regret using them in general given how
heavyweight the hash table implementation is. It would be worthwhile
to improve this implementation
There's a lot less locking when rrdcached runs on tcp for various
reasons. I switched to spinlocks because in the general case there
aren't many metrics that people are interested in summarizing, which
is why the CPU goes so high for you. I think that using
(?:un)?summarized_metrics will
There are plenty of other things that are achievable wrt performance
improvements just by switching datastructures, reducing copies and
allocations, and possibly switching away from XML as a gmetad
serialization format. I haven't had a ton of time recently to start
working on these things or the
Perhaps configurable, then? XDR is a pain in the ass to debug. I was
considering going with JSON or BSON initially.
--dho
2014/1/15 Dave Rawks d...@pandora.com:
On 01/15/2014 06:42 AM, Jesse Becker wrote:
On Wed, Jan 15, 2014 at 8:41 AM, Nicholas Satterly nfsatte...@gmail.com
wrote:
If we
/0705a5defa284e289004daf61ea390338719d5fb
--Nick.
On Tue, Dec 10, 2013 at 8:00 PM, Chris Burroughs chris.burrou...@gmail.com
wrote:
On 12/08/2013 04:43 PM, Devon H. O'Dell wrote:
This is a simple `perf top -p $PID` on one of of our gmetad nodes
Samples: 1M of event 'cycles', Event count (approx
Hi all,
I'm intending to continue working on performance improvements for
gmetad. I'm curious if anybody uses gmetad on architectures that are
not:
* ARM
* PPC
* PPC64
* SPARCv9
* i386
* amd64
or on systems that are not:
* Linux
* ${any}BSD
* Solaris
(I'd also be interested in
2013/12/8 Chris Burroughs chris.burrou...@gmail.com:
On 12/07/2013 03:22 PM, Devon H. O'Dell wrote:
We were polling every 10 seconds, and it was taking over 2 minutes to
finish parsing the XML (which includes writing the RRDs). With my
changes, the 10 second poll is feasible.
Parse
2013/12/7 Adrian Sevcenco adrian.sevce...@cern.ch:
On 12/06/2013 10:51 PM, Devon H. O'Dell wrote:
2013/12/6 Vladimir Vuksan vli...@veus.hr:
Hello everyone,
Hi!
For few weeks now we have had performance issues due to growth of
our monitoring setup. One of my colleagues Devon O'Dell
2013/12/7 Chris Burroughs chris.burrou...@gmail.com:
Thank you Devon and Vladimir for starting this thread. We (AddThis)
have been struggling with gmetad performance and stability for a while
and I'm personally excited to see the focus here. I'll explain briefly
how we are using ganglia for
2013/12/6 Vladimir Vuksan vli...@veus.hr:
Hello everyone,
For few weeks now we have had performance issues due to growth of our
monitoring setup. One of my colleagues Devon O'Dell volunteered to help and
below is an e-mail of his findings.
Hi! I joined the ML, so I'm around to answer
14 matches
Mail list logo
