This patch does two things:
- the code for calculating header length is moved to a function in
rrd_format.c
- the header length is reported by `rrdtool info', useful for studying
file size and memory usage
Regards,
Daniel
Index: src/rrd_info.c
> Hi friends,
> Please tell how to deal with the NAN values due to
> xff in RRD graphs. I saw the ADDNAN patch, it is very useful
> to get most of the graphs but i dont know how to use it. Also
> send any other choices left to deal with NAN values.
This is something that interests me
> > Also I am wondering if it may not be sensible to include the php
> > bindings code with rrdtool itself.
> > It is currently a separate tar ball, that is needed for
> building and
> > this breaks building via "rpmbuild -ta
> rrdtool-1.3.99908121014.tar.gz"
> > without the option "--define
> so does
>
> Index: rrd_fetch.c
> ===
> --- rrd_fetch.c (revision 1703)
> +++ rrd_fetch.c (working copy)
> @@ -390,6 +390,8 @@
> else
> rra_pointer = rrd.rra_ptr[chosen_rra].cur_row +
> 1 + start_offset;
>
> note that there is code to wrap the rra_pointer back to the
> start of the archive once it ventures over the end of the archive ...
>
> if (rra_pointer >= (signed)
> rrd.rra_def[chosen_rra].row_cnt) {
> rra_pointer -= rrd.rra_def[chosen_rra].row_cnt;
It doesn't
>
> the patch is actually very simple ...
>
I think this has exposed another issue, in my latest attempt to run my
tests:
rows = 120960
cur_row = 104821
start_offset = 116378
rra_pointer = 221200
rra_pointer shouldn't be greater than rows, should rra_pointer =
rra_pointer % rows perhaps?
_
> -Original Message-
> From: Tobias Oetiker [mailto:[EMAIL PROTECTED]
> Sent: 27 November 2008 10:57
> To: Pocock, Daniel: IT (LDN)
> Cc: rrd-developers@lists.oetiker.ch
> Subject: Re: [rrd-developers] rrd_fetch seek issue
>
> Hi Daniel,
>
> (I have not yet looked at the code).
>
> I
If an RRD hasn't been updated recently, and I try to invoke rrd_fetch
for a more recent time interval, it tries to seek on the file anyway - I
only discovered this issue when the RRD hadn't updated for over 2 hours,
and it tried to seek beyond the end of the file, causing this "seek
error in RRA
> -Original Message-
> From: kevin brintnall [mailto:[EMAIL PROTECTED]
> Sent: 11 November 2008 08:52
> To: Pocock, Daniel: IT (LDN)
> Cc: rrd-developers@lists.oetiker.ch
> Subject: Re: [rrd-developers] rrdcached measurements in Ganglia
>
> On Tue, Nov 11, 2008 at 08:48:34AM -,
>
Hi Kevin,
I'm thinking about writing a module for Ganglia to read the STATS output
from rrdcached
It's also probably worthwhile reading some data from Apache (has anyone
already written such a module for Ganglia?) so that I can compare some
of the following:
- time taken to serve each web reque
When I kill rrdcached (TERM signal), it closes the command socket
immediately, even though it continues working for several minutes
flushing data to disk.
It would be useful to have access to commands like `STATS' during the
shutdown phase - would it be better to have an additional socket for
t
> Now, rrdcached can have more simultaneous I/O requests into
> the kernel.
> This may allow the kernel to re-order disk writes, resulting
> in better disk throughput. In practice, throughput is
> increased by 2-3x.
Hi Kevin,
Before I integrate this with my own code, could you propose some
> rrdcached now frees all of its resources correctly. This
> facilitates memory debugging. g_tree now knows how to free
> the nodes when it removes them.
>
Thanks for this, I will be looking at the issue again early next week.
The issue that I had the other day was not a leak (as I confir
I suspect that the memory growth observed with rrdcached under high load
results from small I/O sizes. The kernel is only getting those pages
that are being written, and so the queue is growing.
I've made some improvement by using madvise(MADV_WILLNEED) followed by
mlock() on the area of my st
> > The memory leak could be the cause of the performance issue
> - it grows
> > to several gigabytes and there is swapping, that might be
> reducing the
> > amount of RAM available for caching the mmap() pages. Can you make
> > any suggestions for using valgrind or another tool in this scen
> > They all become un-stuck at the same time, maybe 20 seconds
> later, and
> > then the graphs appear very quickly.
>
> The FLUSH commands are waiting to be notified that the file
> has been written out to disk. They block on
> pthread_cond_wait() and don't return until the queue thread
I've got about 50,000 RRDs updated every 10 seconds (each with 6 RRAs)
When I refresh a ganglia page, it invokes about 20 different rrdtool
graph processes simultaneously. Each process connects to the rrdcached
daemon over the socket and sends the flush command.
I'm noticing a lot of threads g
Will anyone else from Ganglia or rrdtool be at either of these events?
http://www.linuxexpolive.co.uk/
http://www.ukuug.org/events/linux2008/
Regards,
Daniel
___
This e-mail may contain information that is confidential, privileged or
otherwise pr
> Try removing the "-z" argument. It causes RRD write times to
> be randomly spread over the "-z" time. This may reduce the
> degree to which your writes are coalesced.
I will try that and report back
>
> I'd be interested to see what your approach is for managing
> the striped files once w
I've configured a stripe file, each stripe is 32 bytes, and there are
32768 stripes.
The data section of the file is aligned with the filesystem block size.
The RRA pointers are aligned when the RRDs are created.
The data file on disk is accessed with mmap(). memcpy() is used to move
data on
rrdcached makes some calls to access and stat, which don't work for my
virtual filesystem abstraction.
This patch:
- provides implementations of rrd_stat and rrd_access, invoking the C
library methods by default
- modify rrdcached to use the rrd_open API for these methods
- update Makefile.am s
rrdcached makes some calls to access and stat, which don't work for my
virtual filesystem abstraction.
This patch:
- provides implementations of rrd_stat and rrd_access, invoking the C
library methods by default
- modify rrdcached to use the rrd_open API for these methods
- update Makefile.am
> >
> > Rather than hammering out an API spec and then finding that
> it has to
> > be changed, I would like to get my stripe implementation
> running this
> > week, test it a little, and use feedback from that to guide
> decisions
> > on the API.
>
> :-) fine with me. I just dont like the
> I think the best would be if you started writing
> documentation for the functions you are implementing /
> planning as well as some general notes on the design ideas.
>
> To become realy useful, the abstraction may have to be pushed
> even further ... keep in minde that as we go to a new c
> > rrd_notify_row patch:
> >
> > - Delegate choice of starting row for newly created RRD
> files to the
> > rrd_open.c API.
> > - Introduce the rrd_notify_row() function so that an implementation
> > can choose to align the rows of new RRDs with existing
> RRDs, if desirable.
> > - Maintain t
> [EMAIL PROTECTED] wrote:
> > The madvise stuff has come out, but it will go back in.
> There are a
> > couple of options:
> > - pass the header size (which is already known) to
> > rrd_file->vfs->open_impl, and call madvise once for the whole region
> > - add an madvise function to rrd_vfs_
I've started generalising the rrd_open API
The madvise stuff has come out, but it will go back in. There are a
couple of options:
- pass the header size (which is already known) to
rrd_file->vfs->open_impl, and call madvise once for the whole region
- add an madvise function to rrd_vfs_t
Also
rrd_notify_row patch:
- Delegate choice of starting row for newly created RRD files to the
rrd_open.c API.
- Introduce the rrd_notify_row() function so that an implementation can
choose to align the rows of new RRDs with existing RRDs, if desirable.
- Maintain the existing behaviour (random star
>
> kevins aproach does sound pretty neat to me though, after all
> the code is only for writing rrd files and with rrd files we
> always know in advance how big they will be ... this is sort
> of a core property of the format.
>
Ok, file size is now set shortly after open and can't be chan
Are there any test scripts I should run before submitting patches? At
the moment, my testing is limited to those things that I think might be
impacted by a change.
Regards,
Daniel
___
This e-mail may contain information that is confidential, privile
> I think a better approach would be to determine the length of
> the file in advance and just create/mmap it once. I already
> wrote the code that determines the size of the data portion
> (it's in rrd_open):
>
You are right, but I didn't want to be so strict with my implementation.
It ma
As a first step towards allowing alternative block storage backends, the
file descriptor and mmap related variables are encapsulated in
rrd_simple_file_t
This patch applies on top of my other recent patches.
___
This e-mail may contain information
rrd_lock() accesses rrd_file.fd, so it should be within rrd_open.c
___
This e-mail may contain information that is confidential, privileged or
otherwise protected from disclosure. If you are not an intended recipient of
this e-mail, do not duplicat
> oops thanks for picking this up ... I have reverted r1601 and r1606
>
> @daniel, please resubmit without mremap dependency ...
>
The https method for SVN works for me, thanks for providing that
Now using munmap followed by a new call to mmap
This has a few consequences:
- The effects of an
As already discussed on the list, this moves selection of the initial
RRA row into the rrd_open.c API
The current implementation (random row) is used by default. However, it
now provides an opportunity for alternative implementations to integrate
with rrdtool in a single place.
Maybe there ar
> But that's missing in your patch, right? Or did I miss something?
>
It already exists in rrd_open.c
___
This e-mail may contain information that is confidential, privileged or
otherwise protected from disclosure. If you are not an intended recipien
> > --- src/rrd_create.c(revision 1598)
> > +++ src/rrd_create.c(working copy)
> [...]
> > -#if defined(_WIN32) && !defined(__CYGWIN__) &&
> !defined(__CYGWIN32__)
> > -flags |= O_BINARY;
> > -#endif
>
> Why did you remove that? Afaik, that's required on windows -
> it ha
>
> having things configurable at runtime is certainly a 'good thing'
> in todays world where skills in compiling stuff are rapidely
> dwindling ...
>
It's also good for troubleshooting - e.g. if someone has a problem, they
can quickly switch from mmap to regular file access to see if the
prob
> -Original Message-
> From: Tobias Oetiker [mailto:[EMAIL PROTECTED]
> Sent: 13 October 2008 19:44
> To: Pocock, Daniel: IT (LDN)
> Cc: rrd-developers@lists.oetiker.ch
> Subject: RE: [rrd-developers] rrd file access code
>
> Today [EMAIL PROTECTED] wrote:
>
> > To maximise the benefi
> what you might want to keep in mind is that I intend to
> create a new platform independent file format. This will also
> have an impact on this ... so if you are looking closely at
> all this code, the fileformat work might be integrated ...
>
> what I have done so fahr is documented on
>
Hi,
I've just been reviewing the file access code and starting to implement
a mechanism for striping multiple RRDs into one big file, to further
reduce IO load.
There are various functions in rrd_open.c (e.g. rrd_read, rrd_write)
that can be abstracted to do what is required.
However, I notice
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Lars Thegler
> Sent: 10 October 2008 13:25
> To: Pocock, Daniel: IT (LDN)
> Subject: Re: [rrd-developers] SVN over HTTP?
>
> The http proxy settings for subversion can be found in
> ~/.subversion/s
This patch does two things:
- remove the --pidfile check, for compatibility with older RHEL/Centos
systems
- update the username used by the init script, to remain consistent with
Bernard's changes to the spec file
Regards,
Daniel
___
This e-mail
Is it possible to access the repository for rrdtool using the http://
method instead of svn:// ?
The Subversion client is unable to go through proxy servers when using
svn://
Regards,
Daniel
___
This e-mail may contain information that is confidenti
Bernard, are you already re-working the spec file, or should I go ahead
and do it? Either way, I have some more comments on the subject:
I notice this is in the spec file:
%define pre rc9
Is that still needed? There are various references to this %{pre}
variable, I just deleted them all
> do you 'stay' authenticated after login ?
>
When I refresh this page:
http://oss.oetiker.ch/rrdtool-trac/
it says I am still `logged in as human'
When I click the `New Ticket' link, it goes to this URL:
http://oss.oetiker.ch/rrdtool-trac/newticket
where I notice that the `logged i
> > The init script does not work on my system (CentOS 4.x) as
> is, because
> > the `daemon` function which I have does not support --pidfile -- is
> > that argument necessary?
My target for this is RHEL5 - in other words, although I have to run the
gmond agent on quite a diverse range of
> -Original Message-
> From: Bernard Li [mailto:[EMAIL PROTECTED]
> Sent: 07 October 2008 19:07
> To: Pocock, Daniel: IT (LDN)
> Cc: rrd-developers@lists.oetiker.ch
> Subject: Re: [rrd-developers] crash - full hard disk
>
> Hi Daniel:
>
> On Tue, Oct 7, 2008 at 5:18 AM,
> <[EMAIL PR
As part of the scalability tests I've been doing, I regularly fill up my
hard disk with RRDs.
I've noticed that rrdtool (trunk, linked with Ganglia 3.1) creates one
or more files with size 0 or with other unusual sizes when the disk
fills up, and shortly after, there is a seg fault (gdb output
> I think this leads to the rrd as a dbms discussion we touched
> a few days ago on the list. This would open up up many
> possibilities but also have to potential of makeing things a
> lot more complex. In my eyes it is primarily a matter of
> finding a really clever design for something lik
> -Original Message-
> From: Pocock, Daniel: IT (LDN)
> Sent: 29 September 2008 13:28
> To: [EMAIL PROTECTED]; rrd-developers@lists.oetiker.ch;
> [EMAIL PROTECTED]
> Subject: Re: [Ganglia-developers] Integrating rrdcached with Ganglia
>
>
>
>
> > http://ganglia.wiki.sourceforge.ne
> http://ganglia.wiki.sourceforge.net/rrdcached_integration
>
> Comments/feedbacks welcome.
Thanks for this - I decided to try it:
- RHEL5
- 64 bit
- APR 1.2.7
- rrdtool 1.3.2 + rrdcached patch from here:
http://dist.rufus.net/~kbrint/rrdcached/rrdcache.patch
- Ganglia 3.1.0
gmetad stor
> Normally the filesystem should be able to take care of quite
> a lot of otimization duties as long as you present it with a
> siutable workload. So maybe there is some low hanging fruit
> to be harvested by looking at when and in what order
> rrdcached does its updates and also maybe how th
> supply an update ... the first patch is already in ... now
> there is something to work off ...
>
attached
___
This e-mail may contain information that is confidential, privileged or
otherwise protected from disclosure. If you are not an intende
With a system such as Ganglia, there are many RRD files all created with
exactly the same parameters.
While rrdcached provides benefits by caching updates to each file, we
still see lots of small 4kb random access writes to the SAN.
Has anyone considered the possibility of aggregating multiple
> Is there any specific reason why you default to a world read-
> and write-able socket? I don't think this is a good idea.
Agreed, it is not a good idea, nor is it essential - it is just a
convenient setting for my lab, where I have httpd running under a
different user. Should I re-submit the
> On Wed, Oct 01, 2008 at 09:37:17AM +0100,
> [EMAIL PROTECTED] wrote:
> > I've occasionally had segfaults in rrdcached. I'm still
> investigating
> > the root cause.
>
> What SVN version are you running? Can you send a backtrace?
>
I downloaded yesterday's snapshot tarball. I'm not able
I've adapted an init script for rrdcached, and also incorporated it into
the spec file so that it is deployed with the RPM.
There are also some other changes to the spec file so that I could build
an RPM successfully from trunk. I'm happy to tidy up the spec file some
more if no one else wants
I've occasionally had segfaults in rrdcached. I'm still investigating
the root cause.
However, two things I notice:
- When I try to restart rrdcached, it refuses to run because the PID
file already exists - maybe it should check the validity of the PID
file, and delete it if the process has go
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Pocock, Daniel: IT (LDN)
> Sent: 30 September 2008 11:19
> To: [EMAIL PROTECTED]
> Cc: rrd-developers@lists.oetiker.ch;
> [EMAIL PROTECTED]
> Subject: Re: [rrd-developers] [Ganglia-developers]
>
> >>
> >> - RHEL5
> >> - 64 bit
> >> - APR 1.2.7
now using the trunk snapshot for 30/09/2008
> >> - Ganglia 3.1.0
> >>
> >> gmetad stores the data and IO levels are definitely better.
> >>
I deleted the rrd files and started again, just monitoring a single
server (gmond on the same server as
61 matches
Mail list logo
