[rrd-users] Sanity checks on Buffer Cache and I/O at peak aggregation times

Sun Sep 25 21:16:32 CEST 2011

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.)

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.)

The trick is to ensure that every block is always cached so your system is never reading for any updates it must do:

   1) your rrd files have too many RRAs, don't consolidate to a day, or 6 hours or 3 hours, or even an hour.
a) for every consolidation RRA that is another IOP to write
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)
c) since you have a lot of RRA consolidation definitions, you have incremental increase in write IOPs for each next consolidation period.
for the 1 day you have IOPs for:
1) filesystem meta data
1) rrd header
18) RRA updates (min/avg/max): 5 minute, 10 minute, 1 hour, 6 hour, 12 hour, 1 day
in total: 20 write IOPs per rrd - compounded by 20K rrds - 400,000 write IOPs
d) having unused datasources defined in an rrd is just a waste of CPU/IO/disk for something that's not being used.
e) having rrdtool doing all those consolidations even with blocks cached is CPU expended for data that's not very useful in comparison
to the burden it creates on system resources.

   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 )
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)
set it to something like 15 minutes, or 30 minutes (vm.dirty_expire_centisecs) which means Linux will only send the
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 )
b) the *only* downside to large dirty buffers is if your server crashes you lose the data in the buffers, but if your server
crashes then you lose data anyway because it's likely you're server isn't replicated and is probably a single-point-of-failure
anyways.  and hardware failures, power failures, network outages, etc, will keep your server down and losing data during
the outage anyway.
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)
can store just a bit over 4 million datasources per minute.  Obviously you need the disk space for that, but the CPU/memory
will have no problem with this and just a couple decent sized SSDs can keep up with the meager IOPs/size this entails.

   3) reformat your rrd filesystems from 4K blocks to 1K blocks.
a) 1K blocks hold 128 intervals (so for 5 minute intervals that's ~10 hours worth of data in 1 block)
b) that saves a lot of memory in the IO cache (4x)
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)
so the server is literally only writing to disk 120 times less per datasource.

   4) ext3, noatime, journal=writeback
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)
but there's little point to not doing this either way, noatime is obvious.
b) xfs is also a very good filesystem, though on an SSD it's debatable if it matters.

   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
2 years.  More RRA's mean more CPU, more IO, more of everything that will slow rrdtool down.
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.
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
looking at hour, day, few day, maybe a week, even less maybe a month)

   6) worth mentioning again: rrdtool is crazy fast
a) in fact it's so fast that on a multi-cpu server rrd updates are limited by the Linux VM big kernel lock
b) I haven't yet tested a newer kernel, I'm still using RHEL5.

   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

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.)

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.  

Regards,
-Ryan

________________________________
From: Derek Haynes <derek.haynes at gmail.com>
To: rrd-users at lists.oetiker.ch
Sent: Sunday, September 18, 2011 10:01 AM
Subject: [rrd-users] Sanity checks on Buffer Cache and I/O at peak aggregation times

Hi all,

I'm doing some tuning work on our rrdtool setup: we'd like to get a
bit more disk i/o overhead. I have two questions/assumptions I'd love
to get a sanity check on.

First, some background on our setup:

* Hardware
** 16 2.27 GHZ CPUs
** 16 GB of RAM
** Dedicated to RRDTool - no other services are installed on this server.
** SSD Drive

* RRDTool Config
** RRDtool 1.4.5
** 20k RRD Files, each 539K in size
** 20 data sources per-file
** 18 RRAs per file (Min/Max/Average of each: 5 minutes for 6 hours,
10 minutes for 12 hours, 1 hour for 3 days, 6 hours for one week, 12
hours for 2 weeks, 1 day for 2 years)

* Performance
** Typically, almost no reads (showing buffer cache is working)
** 315 writes/sec | 4 MB/sec

Second, what we're planning:

I've load tested several different rrdtool file configurations and
what I saw aligned with the behavior in this paper by David Plonka:
http://www.usenix.org/event/lisa07/tech/full_papers/plonka/plonka_html/.
If I'm summarizing the paper correctly, the 2 RRDTool file
configurations that impact I/O activity are (1) # of data sources and
(2) # of RRAs. The number of rows in an RRA does not impact
performance.

* Reducing data sources per-file to 5: Most of our fields are reserved
for later use (since you can't add a new data source to an existing
file via an rrdtool command). Instead, we're going to start with 5 and
manually add new data sources via rrdtool dump / restore. It's rare to
add new data sources to a file.
* Reducing the number of RRAs to 7 (Adding LAST of one-minute data for
60 minutes, extending 5-minutes for 1 week, and dropping all other
RRAs but daily).

When needing to graph data over a several day period, I'm planning on
using the --step option with a 60 minute or greater value to limit the
number of data points returned. I haven't tested this yet, but I'm
assuming reading the many more rows of 5-minute storage may be the
primary performance penalty of the new RRD setup.

And finally, the RRD performance pieces I'm having trouble understanding:

Memory Sizing ---

The "Tuning RRD" wiki page states: "To keep the header (4k) and the
active block of at least one RRA (4k) in memory, you need 8k per RRD
file." For our current configuration, we have 20 data sources and 18
RRAs.

>From the illustration on the page, it looks like our DS Header storage
space would be:
4k per data source * 20 data sources = 80k

Is my maths legit?

For the RRA Header, is it (1) one per-RRA independent of the number of
data sources or (2) one per-RRA * the number of data sources?

If one-per RRA independent of data sources:
18 RRAs * 4k = 72k

If one-per RRA for each data source:
18 RRA * 20 data sources = 360k

Assuming my data source math checks out, this means either 152k or
440k must be stored in the buffer cache for the entire header. free -m
shows that we have 5,119 MB cached: with nearly 20k rrd files, it
looks like the header contains one RRA for each data source. Does this
check out?

High I/O Wait during peak aggregation periods ---

At 00:00 UTC, we see our peak I/O Wait. At this time, reads increase
to 11 reads/sec (typically we have almost no read activity) and writes
increase to 700 writes/sec (typically around 315 writes/sec). One
observation: even though our read throughput is far less than our
write throughput, this increase in reads seems to have a dramatic
impact on I/O Wait.

I can see why there is an increase in writes: currently, we have 18
RRAs across 20 data sources that need to append data to the file at
this time. I'm a bit confused why the read activity increases
dramatically:

* We have 16 GB of RAM
* It looks like < 5 GB of that is used by the buffer cache

My low-level Linux fu is poor: can anyone give some insight into the
read activity at these peak aggregation times?

RRDTool is am amazing piece of work: it's a testament to how well it
works that we haven't needed to investigate performance significantly
in the 3+ years we've been using it.

Cheers,

Derek

-- 
Derek Haynes
Scout Web Monitoring and Reporting ~ http://scoutapp.com
Blog ~ http://blog.scoutapp.com
415.871.7979

_______________________________________________
rrd-users mailing list
rrd-users at lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/rrd-users/attachments/20110925/ab99aec7/attachment-0001.htm 