graphite-dev team mailing list archive

[Amos Shapira <question192377@xxxxxxxxxxxxxxxxxxxxx>]

Question #192377 on Graphite changed:
https://answers.launchpad.net/graphite/+question/192377

    Status: Open => Solved

Amos Shapira confirmed that the question is solved:
Please ignore my question. I think I figured out the problem. I'll
describe this here in case it's going to be useful to others:

Using the dump tool I calculated the actual frequency of data input into
the "primary archive":

$ whisper-dump.py /opt/graphite/storage/whisper/servers/confluence-
bamboo_atlassian_com/bamboo/agents/remote/busy.wsp | egrep '^[0-9]+:
[1-9][0-9]+, [0-9]+' | tr : , | sort -t, -k1,1n | awk '{ print $0, n-$2;
n=$2 }'

(explanation: dump all data from the file, look only for samples which
have a timestamp other than 0, sort by timestamp and add a column of the
difference in timestamp between every two consecutive entries).

The output starts like this:

0, 1332826495, 11 -1332826495
13, 1332826560, 12 -65
26, 1332826625, 16 -65
39, 1332826690, 16 -65
51, 1332826750, 15 -60
64, 1332826815, 15 -65
77, 1332826880, 14 -65
...

This means that a new sample is added to the archive only once every
60-65 seconds, that's on an archive which is defined as "5:120960", i.e.
it expects a new data point every 5 seconds.

The secondary archive is defined at "60:565920",and the xFilesFactor is
the default of 0.5.

My understanding is that the secondary archive remains empty simply
because the xFilesFactor dictates a minimum of 6 (half of 12 samples per
minute) before it triggers the propagation to the secondary archive,
which is never reached.

What we'll do is to increase the rate of input to the primary archive to
4 per minute and decrease the xFilesFactor to 0 (zero) and see what
happens. Later we'll see how we can save space or increase the primary
sampling rate further.

-- 
You received this question notification because you are a member of
graphite-dev, which is an answer contact for Graphite.