<br>
<br><tt><font size=2>Tobias Oetiker &lt;tobi@oetiker.ch&gt; schrieb am
23.02.2010 23:28:53:<br>
<br>
&gt; Hi Peter,<br>
&gt; <br>
&gt; wow ... sounds impressive. Have you done performance evaluations ?<br>
&gt; </font></tt>
<br>
<br><tt><font size=2>Only insofar, as it is fast. Accessing RRDs in /dev/shm
is just &quot;wow&quot;. 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>
&gt; If you could apply your genius to rrdcached and maybe make it even<br>
&gt; 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 &nbsp;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 &quot;pseudo&quot; directories for every RRD,
eg. containing RRD data as CSV &quot;files&quot;. 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>&nbsp;- 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>&nbsp;- 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>&gt; <br>
&gt; Today Peter Stamfest wrote:<br>
&gt; <br>
</font></tt>
<br><tt><font size=2>[.. removed ..]</font></tt>
<br>
<br><tt><font size=2><br>
_________________________________________________________________________<br>
Dipl.-Ing. Peter Stamfest &nbsp; &nbsp; UNIX, Networking &amp; Computing
Consultant<br>
Tel: +43/699/10711205 &nbsp; &nbsp; &nbsp; &nbsp; Software Development
- Internetservices<br>
E-Mail: peter@stamfest.at &nbsp; &nbsp; 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>