[Nagiosplug-devel] Please can I have GIT access

[Alain Williams]

On Tue, Sep 01, 2009 at 12:21:28PM -0400, Max wrote:
> On Tue, Sep 1, 2009 at 11:22 AM, Thomas Guyot-Sionnest <dermoth at aei.ca> wrote:
> > Back to the data retention debate, I agree if we go that way functions
> > could be used for state retention. Another thing we could consider
> > (although I believe you don't like it much) is shared memory...
> 
> Files in RAM or memcache is a lot easier to manage than shared memory.

Files:

* easy to set up, flexible
* don't use up RAM - some sites RAM is precious
* those who do want the speed of RAM, simply create a RAM disk or tmpfs and put the
  files there
* if it is a 'disk' directory and the system is not hard pressed on RAM, the files
  end up in RAM anyway (buffer cache)

What needs to be agreed is a ''standard'' directory where these things can be stored,
or perhaps a $STATE_SAVE_DIR$ that we can use.

Maybe there ought to be some plugin state save/restore code, but I suspect that that may
take some time to get agreed.

> > Finally I believe there's another method that should be considered, and
> > although people are usually not very used to it it's pretty elegant
> > IMHO. Just open two file descriptors for the plugin to use, one for
> > reading in state and one for saving it. This could be done by Nagios
> > and, for older Nagios versions or passive checks, a simple wrapper could
> > be used to save the data to a file. Here's a Quick'nDirty(tm) example:
> 
> So FD 3 and 4 would be provided by Nagios to every plugin regardless
> of language?
> 
> As I mentioned earlier, we have been using Memcache for this and
> getting very good performance from it from our poller even with 1000
> or so plugin calls on a machine saving/getting state from it every few
> minutes .. it also has the advantage of being located off server if
> need be ...

Do the math: 1,000 plugins every 5 minutes. Let us say that all of them save
state (highly unlikely). Assume that the size of a state file is 1KB.
That is 3 state read/save per second, some 3KB read/written per second.

Now look at how a typical plugin works. Take one written in C (nice & efficient).
I looked at check_pop using strace.
It opens 34 files.
It does 32 read system calls.
It does 59 mmap system calls.

Much of this is in the startup code, mapping in libraries, etc. (On a CentOS 5 machine)

Maybe it is untypical, how about check_ping
It opens 19 files.
It does 22 read system calls.
It does 28 mmap system calls.

Now check_procs which is what this fuss is about, the numbers include those of child processes:
It opens 648 files.
It does 647 read system calls.
It does 29 mmap system calls.

So: if on top of this is does one or two extra opens & a read/write - will it
really make that much of a difference ?

> Or are you still speaking here of an extension to do state for
> NRPE-hosted plugins?

Regards

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h>