<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:10pt"><div><span><br></span></div><div>rrdtool is very fast on updates when not having to consolidate large periods of time (ie : when it's not hitting disk for blocks to do consolidation with.)</div><div><br></div><div>Definition of very fast on a memory bound ( no disk IO ) system like yours (depending on the model of CPU): ~48 (forty eight) thousand rrd updates per second sustained, to separate rrd files (1 datasource per file.)</div><div><br></div><div>The trick is to ensure that every block is always cached so your system is never reading for any updates it must do:</div><div><br></div><div> 1) your rrd files have too many RRAs, don't consolidate to a day, or 6 hours or 3 hours, or even an hour.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>a) for every consolidation RRA that is another IOP to
write</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>b) for every consolidation rrdtool must calculate it with the pdps for it's row (that means pdps for a whole day on your 1 day RRA)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>c) since you have a lot of RRA consolidation definitions, you have incremental increase in write IOPs for each next consolidation period.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>for the 1 day you have IOPs for:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>1) filesystem meta data</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>1) rrd header</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>18) RRA updates (min/avg/max): 5 minute, 10 minute, 1 hour, 6 hour, 12 hour, 1 day</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>in total: 20 write IOPs per
rrd - compounded by 20K rrds - 400,000 write IOPs</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>d) having unused datasources defined in an rrd is just a waste of CPU/IO/disk for something that's not being used.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>e) having rrdtool doing all those consolidations even with blocks cached is CPU expended for data that's not very useful in comparison</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>to the burden it creates on system resources.</div><div><br></div><div> 2) don't bother with rrdcached ( it's slow, adds complication, so just adds an intermediate buffer (with it's own IO) which doesn't serve a useful purpose )</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>a) let the Linux VM do it's job and just set dirty_buffer tuning to hold onto dirty blocks for longer than default (30 second is
default)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>set it to something like 15 minutes, or 30 minutes (vm.dirty_expire_centisecs) which means Linux will only send the</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>block to disk after it is 30 minutes dirty ( and in your case of 5 minute updates that's 6 rrd updates per disk IO )</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>b) the *only* downside to large dirty buffers is if your server crashes you lose the data in the buffers, but if your server</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>crashes then you lose data anyway because it's likely you're server isn't replicated and is probably a single-point-of-failure</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>anyways. and hardware failures, power failures, network outages, etc, will keep your server down and losing
data during</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>the outage anyway.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>c) as point of reference, I have dirty buffers set to 2 hours, with polling interval for devices at 60 seconds and one server (a bit faster than yours)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>can store just a bit over 4 million datasources per minute. Obviously you need the disk space for that, but the CPU/memory</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>will have no problem with this and just a couple decent sized SSDs can keep up with the meager IOPs/size this entails.</div><div><br></div><div> 3) reformat your rrd filesystems from 4K blocks to 1K blocks.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>a) 1K blocks hold 128 intervals (so for 5 minute intervals that's ~10 hours
worth of data in 1 block)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>b) that saves a lot of memory in the IO cache (4x)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>c) 1K block goes back to why I do 2 hour dirty buffers, since 2 hours of 60 second steps just barely fit into 1 block at (120 updates)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>so the server is literally only writing to disk 120 times less per datasource.</div><div><br></div><div> 4) ext3, noatime, journal=writeback</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>a) just simply don't not do this, ext3 journal defaults is ordered which means a little less to your SSD (huge difference to a real drive)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>but there's little point to not doing this either way, noatime is obvious.</div><div><span
class="Apple-tab-span" style="white-space:pre"> </span>b) xfs is also a very good filesystem, though on an SSD it's debatable if it matters.</div><div><br></div><div> 5) don't bother with min/max on consolidated RRA's just buy more disk and store at 5 minute for 6 months and 30 minute AVERAGE for</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>2 years. More RRA's mean more CPU, more IO, more of everything that will slow rrdtool down.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>a) rrdtool is -crazy fast- at real time consolidation ... there's little to no point in RRA consolidation unless trying to save on disk space.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>that's about ~206K read for a full 2 year at 30 minutes (and almost no one is going to look at these anyway, most users will be</div><div><span class="Apple-tab-span" style="white-space:pre">
</span>looking at hour, day, few day, maybe a week, even less maybe a month)</div><div><br></div><div> 6) worth mentioning again: rrdtool is crazy fast</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>a) in fact it's so fast that on a multi-cpu server rrd updates are limited by the Linux VM big kernel lock</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>b) I haven't yet tested a newer kernel, I'm still using RHEL5.</div><div><br></div><div> 7) don't ever use rrdtool exec calls, if you've written your own app use either the perl (RRDs), python, ruby or C bindings</div><div><br></div><div><br></div><div>Caveat to some of this is it does depend on what monitoring application you are using, Cacti, Ganglia, etc ... they aren't all very efficient in their use of rrdtool so the 'updates per second' are likely lower with most of them, but in all cases the above will make those applications
much more efficient/performant - and you don't have to modify those apps to get the gains (except (7) - which I don't know how many of them use exec calls anymore.)</div><div><br></div><div>What you definitely want to do is make sure that your disk read IO goes away entirely or almost entirely; having it do reads for user requests only, not updates. </div><div><br></div><div>Regards,</div><div>-Ryan<br></div><div><br></div><div style="font-size: 10pt; font-family: arial, helvetica, sans-serif; "><div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "><font size="2" face="Arial"><hr size="1"><b><span style="font-weight:bold;">From:</span></b> Derek Haynes <derek.haynes@gmail.com><br><b><span style="font-weight: bold;">To:</span></b> rrd-users@lists.oetiker.ch<br><b><span style="font-weight: bold;">Sent:</span></b> Sunday, September 18, 2011 10:01 AM<br><b><span style="font-weight: bold;">Subject:</span></b>
[rrd-users] Sanity checks on Buffer Cache and I/O at peak aggregation times<br></font><br>Hi all,<br><br>I'm doing some tuning work on our rrdtool setup: we'd like to get a<br>bit more disk i/o overhead. I have two questions/assumptions I'd love<br>to get a sanity check on.<br><br>First, some background on our setup:<br><br>* Hardware<br>** 16 2.27 GHZ CPUs<br>** 16 GB of RAM<br>** Dedicated to RRDTool - no other services are installed on this server.<br>** SSD Drive<br><br>* RRDTool Config<br>** RRDtool 1.4.5<br>** 20k RRD Files, each 539K in size<br>** 20 data sources per-file<br>** 18 RRAs per file (Min/Max/Average of each: 5 minutes for 6 hours,<br>10 minutes for 12 hours, 1 hour for 3 days, 6 hours for one week, 12<br>hours for 2 weeks, 1 day for 2 years)<br><br>* Performance<br>** Typically, almost no reads (showing buffer cache is working)<br>** 315 writes/sec | 4 MB/sec<br><br>Second, what we're planning:<br><br>I've load tested several
different rrdtool file configurations and<br>what I saw aligned with the behavior in this paper by David Plonka:<br><a href="http://www.usenix.org/event/lisa07/tech/full_papers/plonka/plonka_html/" target="_blank">http://www.usenix.org/event/lisa07/tech/full_papers/plonka/plonka_html/</a>.<br>If I'm summarizing the paper correctly, the 2 RRDTool file<br>configurations that impact I/O activity are (1) # of data sources and<br>(2) # of RRAs. The number of rows in an RRA does not impact<br>performance.<br><br>* Reducing data sources per-file to 5: Most of our fields are reserved<br>for later use (since you can't add a new data source to an existing<br>file via an rrdtool command). Instead, we're going to start with 5 and<br>manually add new data sources via rrdtool dump / restore. It's rare to<br>add new data sources to a file.<br>* Reducing the number of RRAs to 7 (Adding LAST of one-minute data for<br>60 minutes, extending 5-minutes for 1 week, and
dropping all other<br>RRAs but daily).<br><br>When needing to graph data over a several day period, I'm planning on<br>using the --step option with a 60 minute or greater value to limit the<br>number of data points returned. I haven't tested this yet, but I'm<br>assuming reading the many more rows of 5-minute storage may be the<br>primary performance penalty of the new RRD setup.<br><br>And finally, the RRD performance pieces I'm having trouble understanding:<br><br>Memory Sizing ---<br><br>The "Tuning RRD" wiki page states: "To keep the header (4k) and the<br>active block of at least one RRA (4k) in memory, you need 8k per RRD<br>file." For our current configuration, we have 20 data sources and 18<br>RRAs.<br><br>>From the illustration on the page, it looks like our DS Header storage<br>space would be:<br>4k per data source * 20 data sources = 80k<br><br>Is my maths legit?<br><br>For the RRA Header, is it (1) one per-RRA independent of the number
of<br>data sources or (2) one per-RRA * the number of data sources?<br><br>If one-per RRA independent of data sources:<br>18 RRAs * 4k = 72k<br><br>If one-per RRA for each data source:<br>18 RRA * 20 data sources = 360k<br><br>Assuming my data source math checks out, this means either 152k or<br>440k must be stored in the buffer cache for the entire header. free -m<br>shows that we have 5,119 MB cached: with nearly 20k rrd files, it<br>looks like the header contains one RRA for each data source. Does this<br>check out?<br><br>High I/O Wait during peak aggregation periods ---<br><br>At 00:00 UTC, we see our peak I/O Wait. At this time, reads increase<br>to 11 reads/sec (typically we have almost no read activity) and writes<br>increase to 700 writes/sec (typically around 315 writes/sec). One<br>observation: even though our read throughput is far less than our<br>write throughput, this increase in reads seems to have a dramatic<br>impact on I/O
Wait.<br><br>I can see why there is an increase in writes: currently, we have 18<br>RRAs across 20 data sources that need to append data to the file at<br>this time. I'm a bit confused why the read activity increases<br>dramatically:<br><br>* We have 16 GB of RAM<br>* It looks like < 5 GB of that is used by the buffer cache<br><br>My low-level Linux fu is poor: can anyone give some insight into the<br>read activity at these peak aggregation times?<br><br>RRDTool is am amazing piece of work: it's a testament to how well it<br>works that we haven't needed to investigate performance significantly<br>in the 3+ years we've been using it.<br><br>Cheers,<br><br>Derek<br><br>-- <br>Derek Haynes<br>Scout Web Monitoring and Reporting ~ <a href="http://scoutapp.com" target="_blank">http://scoutapp.com</a><br>Blog ~ <a href="http://blog.scoutapp.com"
target="_blank">http://blog.scoutapp.com</a><br>415.871.7979<br><br>_______________________________________________<br>rrd-users mailing list<br><a ymailto="mailto:rrd-users@lists.oetiker.ch" href="mailto:rrd-users@lists.oetiker.ch">rrd-users@lists.oetiker.ch</a><br><a href="https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users" target="_blank">https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users</a><br><br><br></div></div></div></body></html>