[Nagiosplug-devel] Please can I have GIT access

Alain Williams addw at phcomp.co.uk
Sat Aug 29 20:31:41 CEST 2009


On Sat, Aug 29, 2009 at 02:00:59PM -0400, Max wrote:

> I am not arguing it is easier or better.  I only brought it up as a
> way to keep state for plugins in general :) as you said no one had
> responded with alternate ideas.

OK -- I understand

> Since check_procs is typically run on a remote host via NRPE or ssh,
> yes, I can see that having memcache on every managed client would not
> be a smart idea and I would not do that myself, memcache is great for
> centralized plugins running from the context of the Nagios poller.

Memcache is great for something that has high use, eg data that web server scripts need.
check_procs is going to be run about once every 5 minutes on a machine,
hardly something of critical speed importance.

> We find memcache scales very well for plugins run from the central
> Nagios poller; in our experience we have found RAM-based data stores,
> either through a memory-based cache like memcache or RAM disks,
> perform the best for us.

How many machines are you talking about -- that you have in your cluster ?

> If I were using your plugin and it required a state file and I was
> running it through NRPE I would certainly place the state file on a
> RAM disk on each monitored host to get the persistence and the best
> performance from it.

I would not use precious RAM for something that is used every 5 minutes or so
and for which a little extra delay will hardly be noticed. I would rather let
my operating system decide how to use the RAM: if the machine is lightly loaded
then a disk file is likely to remain in cache; if the machine is heavily loaded
then the cache will be used by some other file/data/...

-- 
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>




More information about the Devel mailing list