makes sense, but i know in my case the number of metrics was constant
after the server gmond had been started for about 10 minutes all gmetric
crons had a chance to submit an initial value.
-scott
On Thu, 23 Feb 2012, Matt Massie wrote:
Each unique metric (keyed on metric name) requires memory space in gmond.
A good test is to peek at the number of metrics in gmond over time, e.g.
$ telnet localhost 8649 | grep METRIC | wc -l
If the number of metrics over time increases, so will the memory use.
Ganglia will release the metric and memory when the age of the metric is
greater than DMAX. A DMAX value of zero will cause ganglia to hold the metric
indefinitely. In order to make sure that ganglia is releasing old metrics, set
the DMAX value to something like 5 minutes (300 secs).
For example, lets assume you are doing per process monitoring and the metric
name looks like
"cpu_user.%d" % (pid,)
Over time, you'll have lots of metrics (cpu_user.343493, cpu_user.343022,
cpu_user.232323) that start accumulating and taking up memory space.
-Matt
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Ganglia-general mailing list
Ganglia-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-general
