Re: [Nagios-devel] Nagios 1.2 fast IO-patch
Posted: Mon Mar 22, 2004 9:27 am
--=-TNF3SomPfpO5N5rFowPN
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Hi,
It would be better to use mmap instead of
read the entire file ?=20
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.
>=20
> I wrote this patch the other day when I was juggling with automating=20
> reports (avail.cgi), and I noticed that parsing the files alone took 8=20
> seconds, even though it was less than 3MB of data.
> The solution was to rewrite the read_line() function in cgiutils.c to=20
> utilize larger read()-buffers and thus allow for IO bursting.
> With this patch applied execution time went down to 0.7 seconds.
>=20
> It also solves the problem with not-newline-terminated rows not being=20
> read in the configuration files (discussed earlier).
>=20
> The only drawback is that it will take forever to parse files that are=20
> larger than you have physical RAM available (the kernel will utilize th=
e=20
> swap-space), and will fail completely (pretending the file is empty) if=
=20
> the file is larger than the physical AND virtual RAM combined. However,=
=20
> considering that it already takes forever even with relatively small=20
> files, this shouldn't be a problem.
>=20
> This patch is also available for 2.0a1, but I haven't had time to test=20
> it to any extent with that release.
>=20
> 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=20
> software RAID-mirroring.
> c) Dell Inspiron PIII 866Mhz with 256MB RAM and a single 20GB IDE-disk.
>=20
> Cheers,
> Sourcerer / Andreas Ericsson
> =20
--=20
Eric BOLLENGIER, Administrateur Syst=E8me - 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
--=-TNF3SomPfpO5N5rFowPN
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
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
<TABLE CELLSPACING="0" C
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Hi,
It would be better to use mmap instead of
read the entire file ?=20
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.
>=20
> I wrote this patch the other day when I was juggling with automating=20
> reports (avail.cgi), and I noticed that parsing the files alone took 8=20
> seconds, even though it was less than 3MB of data.
> The solution was to rewrite the read_line() function in cgiutils.c to=20
> utilize larger read()-buffers and thus allow for IO bursting.
> With this patch applied execution time went down to 0.7 seconds.
>=20
> It also solves the problem with not-newline-terminated rows not being=20
> read in the configuration files (discussed earlier).
>=20
> The only drawback is that it will take forever to parse files that are=20
> larger than you have physical RAM available (the kernel will utilize th=
e=20
> swap-space), and will fail completely (pretending the file is empty) if=
=20
> the file is larger than the physical AND virtual RAM combined. However,=
=20
> considering that it already takes forever even with relatively small=20
> files, this shouldn't be a problem.
>=20
> This patch is also available for 2.0a1, but I haven't had time to test=20
> it to any extent with that release.
>=20
> 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=20
> software RAID-mirroring.
> c) Dell Inspiron PIII 866Mhz with 256MB RAM and a single 20GB IDE-disk.
>=20
> Cheers,
> Sourcerer / Andreas Ericsson
> =20
--=20
Eric BOLLENGIER, Administrateur Syst=E8me - 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
--=-TNF3SomPfpO5N5rFowPN
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
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
<TABLE CELLSPACING="0" C
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]