Nagios 1.2 fast IO-patch

BOLLENGIER Eric ebollengier at sigma.fr
Mon Mar 22 18:27:02 CET 2004


Hi,

It would be better to use mmap instead of
read the entire file ? 

if 20 users do that at the same time
with a big log file, it could be nasty... one of my nagios server
have only 32Mb of ram...

Bye

On Mon, 2004-03-22 at 17:07, Andreas Ericsson wrote:

> Hi all.
> 
> I wrote this patch the other day when I was juggling with automating 
> reports (avail.cgi), and I noticed that parsing the files alone took 8 
> seconds, even though it was less than 3MB of data.
> The solution was to rewrite the read_line() function in cgiutils.c to 
> utilize larger read()-buffers and thus allow for IO bursting.
> With this patch applied execution time went down to 0.7 seconds.
> 
> It also solves the problem with not-newline-terminated rows not being 
> read in the configuration files (discussed earlier).
> 
> The only drawback is that it will take forever to parse files that are 
> larger than you have physical RAM available (the kernel will utilize the 
> swap-space), and will fail completely (pretending the file is empty) if 
> the file is larger than the physical AND virtual RAM combined. However, 
> considering that it already takes forever even with relatively small 
> files, this shouldn't be a problem.
> 
> This patch is also available for 2.0a1, but I haven't had time to test 
> it to any extent with that release.
> 
> Tested on Openwall GNU/*/Linux, kernel 2.4.24-ow1 running on;
> a) Celeron 2.0Ghz with 256MB RAM and a single 40GB IDE-disk.
> b) Pentium 4 HT 2.8Ghz with 512MB RAM and dual 120GB IDE-disks with 
> software RAID-mirroring.
> c) Dell Inspiron PIII 866Mhz with 256MB RAM and a single 20GB IDE-disk.
> 
> Cheers,
> Sourcerer / Andreas Ericsson
>  

-- 
Eric BOLLENGIER, Administrateur Système - Poste 1325
SIGMA Informatique http://www.sigma.fr
3 rue Newton, BP 4127, 44241 La Chapelle sur Erdre Cedex
tel : 02.40.37.14.00
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20040322/7f6a132a/attachment.html>


More information about the Developers mailing list