Hi Richard,
--- [EMAIL PROTECTED] wrote:
> Guys,
>
>
> the code below is in the cygwin and linux metric.c files.
>
> --------------------------------------------------------
> typedef struct {
> uint32_t last_read;
> uint32_t thresh;
> char *name;
> char buffer[BUFFSIZE];
> } timely_file;
>
> timely_file proc_stat = { 0, 15, "/proc/stat" };
> timely_file proc_loadavg = { 0, 15, "/proc/loadavg" };
> timely_file proc_meminfo = { 0, 30, "/proc/meminfo" };
> timely_file proc_net_dev = { 0, 30, "/proc/net/dev" };
>
> char *update_file(timely_file *tf)
> {
> int now,rval;
> now = time(0);
> if(now - tf->last_read > tf->thresh) {
> rval = slurpfile(tf->name, tf->buffer, BUFFSIZE);
> if(rval == SYNAPSE_FAILURE) {
> err_msg("update_file() got an error from slurpfile() reading
> %s",
> tf->name);
> return (char *)SYNAPSE_FAILURE;
> }
> else tf->last_read = now;
> }
> return tf->buffer;
> }
> --------------------------------------------------------
>
> In my ganglia setup I have a small number of metrics polled often
> (5-10
> seconds) on a large number
> of host (4,000!). I have already observed that values did not seem to
> change that fast,
> but have only now found the above code. I obviously can't poll fast
> with
> the above code.
>
let me understand, you want to sample (e.g.) cpu_* at 5 sc intervalls?
> Given that metrics are measured only at the rate defined by their
> poll
> time, what is the point
> of the above code? Is it to ensure that when (say) cpu_user, cpu_sys,
> cpu_wio etc are measured, the
> /proc file is only opened once?
>
You might be right. Before we had "collection groups" I guess this
would [kind of] ensure that all the cpu_* stats would be taken from the
same sample. Otherwise they would not add up to 100%.
Also it rate limits the reading of the /proc files, which might be
considered to be "expensive".
What happens when you compile with smaller values?
> Also it seems the delay between /proc file reads is the delay above,
> plus the poll delay of the metric.
> It this true? I measured this, but did not trace through the code
> source
> to confirm.
>
Not sure about that. If true is sounds wrong.
> So Matt (or a similar guru), can you let me know the intent of this
> code?
>
> kind regards,
> Richard G
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
