[mrtg] ext3 sync speed

[Steve Shipway]

> > You get significant savings by making sure MRTG is using daemon mode (as
> > opposed to using cron or similar) with RRD 1.4, so that the cfg files are
> > cached and the memory-mapped features of RRD1.4 kick in.
> 
> I use CRON mode. Do you think, that memory-mapped features are not used
> in cron mode?
> I have over 1.2GB cached memory. It was worse with older RRDTool versions...

If you use daemon mode rather than cron, you get the benefit that the .cfg files are not re-read and re-parsed every round, plus the RRD files stay mapped in memory, which seems to give noticeable benefits.

I've run tests on different versions of RRD, cron vs. daemon mode, noatime/atime, and rrdcached/none to compare.

> I use 14all.cgi and my own index cgi and search engine.
> I don't want to much experiment on this production box. With rrdcached
> I will probably wait some time when it stabilize.

Rrdcached is fairly easy to bolt on, provided you don’t do anything odd.  If you use the trunk version, and your custom scripts stick to info/update/create/graph/fetch then you can simply set the RRDCACHED_ADDRESS env var and it should continue to work via the daemon (if you are using RRD 1.4 trunk).  Worth testing, though.

> Did you know about some filesystem tests? It will be better to use ext4
> or btrfs for faster sync?

I haven't done any tests on comparative performance using different filesystems, though I've previously noticed that IO performance of the disk hardware is very significant.

I have a Powerpoint presentation from LISA'10 that compares the performance of the various MRTG/RRD configurations.  Email me directly if you're interested (I can't attach it here)

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: s.shipway at auckland.ac.nz
 Please consider the environment before printing this e-mail 


-------------- 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/mrtg/attachments/20110630/8032460e/attachment-0001.bin