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

[Steve Shipway]

>From: rrd-users-bounces+s.shipway=auckland.ac.nz at lists.oetiker.ch
[mailto:rrd-users->bounces+s.shipway=auckland.ac.nz at lists.oetiker.ch] On
Behalf Of Ryan Kubica
>

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

 

I would, in general, disagree with this ("rrdcached is slow"); it really
comes down to how you configure it.

 

I've done a number of tests for performance of MRTG + RRDTool + rrdcached to
see the relative performance of different versions and options.  The benefit
of rrdcached is heavily dependent on how aggressively it is configured; if
you set it to cache minimally then you have little benefit, if any.
However, a more aggressive configuration (>5 steps cache time) will give you
gains as it updates the files less frequently.  Of course, it depends again
on how often you are reading the files now, as reading via rrdcached forces
a flush and you lose any additional benefits that would be accrued over the
remainder of the caching window.

 

Another benefit of rrdcached (at least for MRTG users) is that it allows you
to decouple your collector, frontend and backend so that you can have your
RRD on one server (with a fast disk IO) but have multiple other servers
collecting data and feeding it back via rrdcached over TCP.  Similarly,
frontend web servers displaying the data can pull it via rrdcached over the
network.

 

Also, since the rrd client just has to pass over the data to rrdcached, and
not wait for the actual write, return is much faster.

 

However, on the downside, rrdcached is relatively immature - you need to use
the trunk version to get all the functionality, the stable version is
limited to update, fetch and graph.  The security side can sometimes bite
you when running over TCP.  And, of course, you have to tune it and
configure it correctly in order to get the maximum benefit, and there is as
yet not so much documentation available on how to best achieve this.

 

Steve

 

 

  _____  

Steve Shipway

ITS Unix Services Design Lead

University of Auckland, New Zealand

Floor 1, 58 Symonds Street, Auckland

Phone: +64 (0)9 3737599 ext 86487

DDI: +64 (0)9 924 6487

Mobile: +64 (0)21 753 189

Email:  <mailto:s.shipway at auckland.ac.nz> s.shipway at auckland.ac.nz

P Please consider the environment before printing this e-mail 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/rrd-users/attachments/20110927/aafec590/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4928 bytes
Desc: not available
Url : http://lists.oetiker.ch/pipermail/rrd-users/attachments/20110927/aafec590/attachment.bin