Nagios 1.2 fast IO-patch

[Andreas Ericsson]

BOLLENGIER Eric wrote:
> It would be better to use mmap instead of
> read the entire file ?
> 
Not unless the nagios core program is modified to append to the memory 
area instead of the file. Otherwise, msync() and munmap() must be called 
before exiting the program, which is basically the equivalence of 
close() (except msync() is only called if the file was opened with 
anything but O_RDONLY).

> 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...
> 
If you have enough users for 20 people to access the same file within 
the same second on a server with only 32MB RAM, you're in enough trouble 
anyway, since executable PTE's will hog about 100% of your RAM.
Also, if you have enough checks for the logs to get up to any size (I 
assume people rotate their logs on a monthly or so basis) on a system 
with that limited amount of RAM, you really ought to invest some money 
in new hardware.

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

-- 
Mvh / Best regards
Sourcerer / Andreas Ericsson
OP5 AB
+46 (0)733 709032
andreas.ericsson at op5.se


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click