<html><head><title>Re: [smokeping-users] Question about Database Config.</title>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
</head>
<body>
<br><br>
<br>
<table>
<tr>
<td width=10 bgcolor= #0000ff><br>
</td>
<td width=802><br><br>
<span style=" font-family:'courier new'; font-size: 9pt;">On 8 Dec 2011, at 00:40, Gregory Sloop wrote:<br>
<br>
<span style=" font-size: 14pt;">Provided I understand these configs right, you've got:<br>
<br>
BC> AVERAGE 0.5 1 5040 #1008<br>
5040 minutes of 1 min resolution data. (i.e. 84 hours or 3.5 days)<br>
<br>
BC> AVERAGE 0.5 12 21600 #4320<br>
BC> MIN 0.5 12 21600 #4320<br>
BC> MAX 0.5 12 21600 #4320<br>
<br>
Then the next set is 12 minute steps, and you've got 180 days of 12min<br>
data.<br>
<br>
[These compress the prior 1 min steps by a factor or 1:12.<br>
Again, provided I understand correctly. This seems excessive - I'd<br>
probably keep 30 - 90 days of 12 min data. But I'm not sure what your<br>
goals are - perhaps that 12 minute data is more important than I<br>
realize. But I think I should catch most important stuff in 3 days,<br>
and after 30 days, the data's not terribly important for higher<br>
resolution needs.]<br>
<br>
BC> AVERAGE 0.5 144 3600 #720<br>
BC> MAX 0.5 144 3600 #720<br>
BC> MIN 0.5 144 3600 #720<br>
Then 360 days of 144 minute (~2.3 hr resolution) data.<br>
<br>
---<br>
Here's what I do:<br>
<br>
I keep one minute data too, and I use<br>
BC> AVERAGE 0.5 1 4320 #3 days, 60 sec resolution<br>
<br>
BC> AVERAGE 0.5 10 4320 #30 days at 10 min resolution<br>
BC> MIN 0.5 10 4320 #<br>
BC> MAX 0.5 10 4320 #<br>
[90 days might be better, but I don't often wish for more than 30-60<br>
days]<br>
<br>
BC> AVERAGE 0.5 144 2400 #400 days at 2 hr resolution<br>
BC> MAX 0.5 144 2400 #<br>
BC> MIN 0.5 144 2400 #<br>
<br>
IIRC, this results in about 8.5MB rrd files for each monitored device.<br>
This seems like a pretty reasonable file size for me.<br>
<br>
I just calculated it, and this appears to use roughly 0.77 KB per row of<br>
data. [~770KB per 1000 RRD rows or ~1300 rows/MB.]<br>
<br>
HTH<br>
<br>
-Greg<br>
<br>
<br>
<br>
<span style=" font-size: 9pt;">Hi Greg,<br>
<br>
Many thanks for this excellent reply. I can't find documentation that answers this question:<br>
<br>
If I adjust:<br>
<br>
*** Database ***<br>
<br>
step = 60<br>
pings = 20<br>
<br>
<br>
to different values do I have to adjust the <br>
<br>
# consfn mrhb steps total<br>
<br>
<br>
lines in step with the adjustments made to the step and pings?<br>
<br>
Thanks<br>
Brian<br>
</td>
</tr>
</table>
<br><br>
<span style=" font-family:'Courier New'; font-size: 9pt;">I don't believe you have to do so. [I'm quite sure about this.]<br>
<br>
...and I believe the graph outputs will display the highest resolution data it has available. [I'm not sure what happens if some of the selected data has high-res data and the rest doesn't...]<br>
<br>
AFAIK, you only need adjust the RRD aggregation if the history windows for each level of aggregation don't match what you need/want, and/or the total RRD size is larger than you can accept.<br>
<br>
[Option: I want high res data to quickly catch [for alerts primarily] high latency or packet loss, so I want 60 second steps. However, once that data is more than a few days old (and usually 12 hours old is good enough) I *could* take a big hit in resolution and feel fine about it. But, since the RRD's aren't so very big anyway - I'm more than willing to burn 8MB or even 20MB per RRD without worrying about it much. So, keeping more history at higher resolutions is just fine for my purposes.]<br>
<br>
...and I don't know where I/O would become a problem - I'm running in a VM with MRTG and I'm not seeing any issues with I/O - but I'd guess that with hundreds to thousands of hosts to hit with fping or other probes, and large, high-res histories, then I/O, from writing the RRD data to disk, could become a problem.<br>
<br>
I've not read of anyone who's actually hit that wall, but I'd guess it's happened before. [Hello SSD! would be my solution today.]<br>
<br>
HTH<br>
<br>
-Greg</body></html>