=head1 SYNOPSIS
-B<rrdcached> [B<-l/-L> I<address>] [B<-w> I<timeout>] [B<-z> I<delay>] [B<-f> I<timeout>] [B<-j> I<dir>] [-F] [B<-b> I<dir> [B<-B>]]
+B<rrdcached>
+[B<-l/-L>E<nbsp>I<address>]
+[B<-w>E<nbsp>I<timeout>]
+[B<-z>E<nbsp>I<delay>]
+[B<-f>E<nbsp>I<timeout>]
+[B<-p>E<nbsp>I<pid_file>]
+[B<-t>E<nbsp>I<write_threads>]
+[B<-j>E<nbsp>I<journal_dir>]
+[-F]
+[B<-b>E<nbsp>I<base_dir>E<nbsp>[B<-B>]]
=head1 DESCRIPTION
Sets the name and location of the PID-file. If not specified, the default,
C<I<$localststedir>/run/rrdcached.pid> will be used.
+=item B<-t> I<write_threads>
+
+Specifies the number of threads used for writing RRD files. The default
+isE<nbsp>4. Increasing this number will allow rrdcached to have more
+simultaneous I/O requests into the kernel. This may allow the kernel to
+re-order disk writes, resulting in better disk throughput.
+
=item B<-j> I<dir>
Write updates to a journal in I<dir>. In the event of a program or system
updated by the daemon, assuming the base directory
"/tmp".
+B<WARNING:> The paths up to and including the base directory B<MUST NOT BE>
+symbolic links. In other words, if the base directory is
+specified as:
+
+ -b /base/dir/somewhere
+
+... then B<NONE> of the following should be symbolic links:
+
+ /base
+ /base/dir
+ /base/dir/somewhere
+
=item B<-B>
-Only permit writes into the base directory specified in B<-b>. This does
-B<NOT> detect symbolic links. Paths containing C<../> will also be blocked.
+Only permit writes into the base directory specified in B<-b> (and any
+sub-directories). This does B<NOT> detect symbolic links. Paths
+containing C<../> will also be blocked.
=back
are printed to C<STDERR>. One of the steps when starting up is to fork to the
background and closing C<STDERR> - after this writing directly to the user is
no longer possible. Once this has happened, the daemon will send log messages
-to the system logging daemon using L<syslog(3)>. The facility used it
+to the system logging daemon using L<syslog(3)>. The facility used is
C<LOG_DAEMON>.
=head1 HOW IT WORKS
+---+----+---+ +------+-----+ +---+----+---+
! File: foo ! ! File: bar ! ! File: qux !
! First: 101 ! ! First: 119 ! ! First: 180 !
- ! Next: ---+--->! Next: ---+---> ... --->! Next: - !
+ ! Next:&bar -+--->! Next:&... -+---> ... --->! Next:NULL !
+ | Prev:NULL !<---+-Prev:&foo !<--- ... ----+-Prev: &... !
+============+ +============+ +============+
! Time: 100 ! ! Time: 120 ! ! Time: 180 !
! Value: 10 ! ! Value: 0.1 ! ! Value: 2,2 !
Causes the daemon to start flushing ALL pending values to disk. This
returns immediately, even though the writes may take a long time.
+=item B<PENDING> I<filename>
+
+Shows any "pending" updates for a file, in order. The updates shown have
+not yet been written to the underlying RRD file.
+
+=item B<FORGET> I<filename>
+
+Removes I<filename> from the cache. Any pending updates B<WILL BE LOST>.
+
+=item B<QUEUE>
+
+Shows the files that are on the output queue. Returns zero or more lines
+in the following format, where E<lt>num_valsE<gt> is the number of values
+to be written for the E<lt>fileE<gt>:
+
+ <num_vals> <file>
+
=item B<HELP> [I<command>]
Returns a short usage message. If no command is given, or I<command> is
for, so describing the mechanism again is unnecessary. Read L<HOW IT WORKS>
above for a detailed explanation.
+Note that rrdcached only accepts absolute timestamps in the update values.
+Updates strings like "N:1:2:3" are automatically converted to absolute
+time by the RRD client library before sending to rrdcached.
+
=item B<WROTE> I<filename>
This command is written to the journal after a file is successfully
updates have already been applied. It is I<only> valid in the journal; it
is not accepted from the other command channels.
+=item B<BATCH>
+
+This command initiates the bulk load of multiple commands. This is
+designed for installations with extremely high update rates, since it
+permits more than one command to be issued per read() and write().
+
+All commands are executed just as they would be if given individually,
+except for output to the user. Messages indicating success are
+suppressed, and error messages are delayed until the client is finished.
+
+Command processing is finished when the client sends a dot (".") on its
+own line. After the client has finished, the server responds with an
+error count and the list of error messages (if any). Each error messages
+indicates the number of the command to which it corresponds, and the error
+message itself. The first user command after B<BATCH> is command number one.
+
+ client: BATCH
+ server: 0 Go ahead. End with dot '.' on its own line.
+ client: UPDATE x.rrd 1223661439:1:2:3 <--- command #1
+ client: UPDATE y.rrd 1223661440:3:4:5 <--- command #2
+ client: and so on...
+ client: .
+ server: 2 Errors
+ server: 1 message for command 1
+ server: 12 message for command 12
+
+=item B<QUIT>
+
+Disconnect from rrdcached.
+
=back
=head2 Performance Values
=item B<DataSetsWritten> I<(unsigned 64bit integer)>
-Total number of "data sets" written to disk since the daemon was started. A
-data set is one or more values passed to the B<UPDATE> command. For example:
-C<N:123:456> is one data set with two values. The term "data set" is used to
-prevent confusion whether individual values or groups of values are counted.
+Total number of "data sets" written to disk since the daemon was
+started. A data set is one or more values passed to the B<UPDATE>
+command. For example: C<1223661439:123:456> is one data set with two
+values. The term "data set" is used to prevent confusion whether
+individual values or groups of values are counted.
=item B<TreeNodesNumber> I<(unsigned 64bit integer)>
projects / rrdtool.git / blobdiff