Re: [Nagios-devel] Broker and latency.
Posted: Wed Apr 16, 2008 12:15 am
Dies ist eine mehrteilige Nachricht im MIME-Format.
--=_alternative 002D5C5CC125742D_=
Content-Type: text/plain; charset="US-ASCII"
Hi,
I'm facing nearly the same problem here, using nagios 3.0.1, ndoutils
1.4b7 and MySQL 5.0.22 running on RHEL5.1.
as soon as i enable the NDO module in nagios.cfg, the service and host
latencies are increasing (values about 700 sec and above...)
after disabling NDO and restarting everything is normal again... at the
moment there are only 90 host and 280 service checks.
any help would be appreciated!
I've reported a problem with NDO, in which the latency would start
to go up and the nagios process consume a lot of memory, when using NDO.
Because of this I started to develop my own broker to write just
some data to the database, and after 3 days, the same thing started to
happen, the latency started to go up, the load with it until suddenly
the load dropped to zero and it seems like nagios stops processing
checks and by the time it does that, it is consuming a lot of memory.
I am using nagios-3.0 on CentOS 5 and I've checked and recked my
broker and I can't find where it would have any allocation problems. I
am running nagios with 150 hosts and 2500 services.
A nagios restart fixes the latency back to where is was, 0.3s, and
then it starts going up again.
Is there a known problem in the nagios broker schema? Any tests I
could run to try and spot the problem?
Thanks
---
Alessandro Ren
OpServices
http://www.opservices.com.br
--=_alternative 002D5C5CC125742D_=
Content-Type: text/html; charset="US-ASCII"
Hi,
I'm facing nearly the same problem here,
using nagios 3.0.1, ndoutils 1.4b7 and MySQL 5.0.22 running on RHEL5.1.
as soon as i enable the NDO module in
nagios.cfg, the service and host latencies are increasing (values about
700 sec and above...)
after disabling NDO and restarting everything
is normal again... at the moment there are only 90 host and 280 service
checks.
any help would be appreciated!
I've reported a problem with NDO, in which the latency would
start
to go up and the nagios process consume a lot of memory, when using NDO.
Because of this I started to develop my own broker to write
just
some data to the database, and after 3 days, the same thing started to
happen, the latency started to go up, the load with it until suddenly
the load dropped to zero and it seems like nagios stops processing
checks and by the time it does that, it is consuming a lot of memory.
I am using nagios-3.0 on CentOS 5 and I've checked and recked
my
broker and I can't find where it would have any allocation problems. I
am running nagios with 150 hosts and 2500 services.
A nagios restart fixes the latency back to where is was,
0.3s, and
then it starts going up again.
Is there a known problem in the nagios broker schema? Any
tests I
could run to try and spot the problem?
Thanks
---
Alessandro Ren
OpServices
http://www.opservices.com.br
--=_alternative 002D5C5CC125742D_=--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
--=_alternative 002D5C5CC125742D_=
Content-Type: text/plain; charset="US-ASCII"
Hi,
I'm facing nearly the same problem here, using nagios 3.0.1, ndoutils
1.4b7 and MySQL 5.0.22 running on RHEL5.1.
as soon as i enable the NDO module in nagios.cfg, the service and host
latencies are increasing (values about 700 sec and above...)
after disabling NDO and restarting everything is normal again... at the
moment there are only 90 host and 280 service checks.
any help would be appreciated!
I've reported a problem with NDO, in which the latency would start
to go up and the nagios process consume a lot of memory, when using NDO.
Because of this I started to develop my own broker to write just
some data to the database, and after 3 days, the same thing started to
happen, the latency started to go up, the load with it until suddenly
the load dropped to zero and it seems like nagios stops processing
checks and by the time it does that, it is consuming a lot of memory.
I am using nagios-3.0 on CentOS 5 and I've checked and recked my
broker and I can't find where it would have any allocation problems. I
am running nagios with 150 hosts and 2500 services.
A nagios restart fixes the latency back to where is was, 0.3s, and
then it starts going up again.
Is there a known problem in the nagios broker schema? Any tests I
could run to try and spot the problem?
Thanks
---
Alessandro Ren
OpServices
http://www.opservices.com.br
--=_alternative 002D5C5CC125742D_=
Content-Type: text/html; charset="US-ASCII"
Hi,
I'm facing nearly the same problem here,
using nagios 3.0.1, ndoutils 1.4b7 and MySQL 5.0.22 running on RHEL5.1.
as soon as i enable the NDO module in
nagios.cfg, the service and host latencies are increasing (values about
700 sec and above...)
after disabling NDO and restarting everything
is normal again... at the moment there are only 90 host and 280 service
checks.
any help would be appreciated!
I've reported a problem with NDO, in which the latency would
start
to go up and the nagios process consume a lot of memory, when using NDO.
Because of this I started to develop my own broker to write
just
some data to the database, and after 3 days, the same thing started to
happen, the latency started to go up, the load with it until suddenly
the load dropped to zero and it seems like nagios stops processing
checks and by the time it does that, it is consuming a lot of memory.
I am using nagios-3.0 on CentOS 5 and I've checked and recked
my
broker and I can't find where it would have any allocation problems. I
am running nagios with 150 hosts and 2500 services.
A nagios restart fixes the latency back to where is was,
0.3s, and
then it starts going up again.
Is there a known problem in the nagios broker schema? Any
tests I
could run to try and spot the problem?
Thanks
---
Alessandro Ren
OpServices
http://www.opservices.com.br
--=_alternative 002D5C5CC125742D_=--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]