<br>
<br><tt><font size=2>Tobias Oetiker <tobi@oetiker.ch> schrieb am
23.02.2010 23:28:53:<br>
<br>
> Hi Peter,<br>
> <br>
> wow ... sounds impressive. Have you done performance evaluations ?<br>
> </font></tt>
<br>
<br><tt><font size=2>Only insofar, as it is fast. Accessing RRDs in /dev/shm
is just "wow". I wanted to do my first real deployment of the
software yesterday, and then I stumbled across rrdcached. And my motivation
just vanished :-(</font></tt>
<br><tt><font size=2><br>
> If you could apply your genius to rrdcached and maybe make it even<br>
> better based on the insights gained from the rrdfs implementation?<br>
</font></tt>
<br><tt><font size=2>Well, I had some plans for rrdfs: </font></tt>
<br>
<br><tt><font size=2>- Provide a memory only version of rrd_update_r. Then
I could get rid of the staging area and just cache RRDs entirely in memory
- while still providing file-level access to them. </font></tt>
<br><tt><font size=2>- The write ahead logging rrdfs is able to do would
allow for proper restart of a crashed/killed/whatever rrdfs in such a scenario
(but it would also help for the staging-area case).</font></tt>
<br><tt><font size=2>- Make it NFS capable: Access RRDs handled by rrdfs
from a remote host using normal file access. This requires a recent kernel
and has some drawbacks, though. But this would allow for HUGE RRD repositories
- distributed over any number of NFS servers.</font></tt>
<br><tt><font size=2>- It would even be possible to integrate more
of rrdtool commands into rrdfs. Just imagine a mechanism to just access
a png file by name and have it automagically computed from memory. It would
even be possible to provide "pseudo" directories for every RRD,
eg. containing RRD data as CSV "files". The sky is the limit
(or the avoidance of feature creep)...</font></tt>
<br>
<br>
<br><tt><font size=2>I don't know the inner workings of rrdcached, but
rrdfs could actually become part of it, I think (#ifdef'd on the availability
of FUSE). The question is: Is this something you would accept?</font></tt>
<br>
<br>
<br><tt><font size=2>So a plan could be:</font></tt>
<br><tt><font size=2> - factor out file access from rrd_update_r and
provide a rrd_update_mem_r as a base for rrd_update_r and become memory
only (with the transparent permanent storage handling).</font></tt>
<br><tt><font size=2> - integrate the IPC handling from rrdcached
into rrdfs or vice-versa. This MIGHT be as simple as just modifying the
main() from rrdfs to fire up a single pthread and have that take care of
rrdfs and all the rest would be handled by the existing rrdcached (plus
the backend storage/update caching would have to be integrated - in that
area I'm using a hashtable keyed on the file name essentially containing
a dynamic array of updates per file).</font></tt>
<br>
<br><tt><font size=2>peter</font></tt>
<br>
<br>
<br>
<br><tt><font size=2>> <br>
> Today Peter Stamfest wrote:<br>
> <br>
</font></tt>
<br><tt><font size=2>[.. removed ..]</font></tt>
<br>
<br><tt><font size=2><br>
_________________________________________________________________________<br>
Dipl.-Ing. Peter Stamfest UNIX, Networking & Computing
Consultant<br>
Tel: +43/699/10711205 Software Development
- Internetservices<br>
E-Mail: peter@stamfest.at WWW: </font></tt><a href=http://stamfest.at/><tt><font size=2>http://stamfest.at/</font></tt></a><tt><font size=2><br>
</font></tt>