Antwort: Performance problems

Sascha.Runschke at gfkl.com Sascha.Runschke at gfkl.com
Thu Jun 5 12:50:15 CEST 2008


nagios-users-bounces at lists.sourceforge.net schrieb am 05.06.2008 11:57:32:

> I'm running nagios 3.0.2 on a dell poweredge 2850 server with 2gb ram 
> and a xeon 2.80GHz cpu.
> Also running on this server, ndo utils 1.47b, pnp, nagvis and 
> nagiosla.(os is newest rhel5)
> Nagios checks 113 hosts and 660 services, most of them every 3 minutes.
> Server load is over 1.3 most of the time due to the mysql database, I 
think.
> Another problem is, I get frequently high ping times in the local 
> network the nagios server belongs to.
> 
> What servers do you use for this count of checks.
> Should I split it into two nagios servers?
> 
> It would be nice to get some suggestions.

I'm running nearly the same set, just missing nagiosla, on RHEL5.2.

Machine is a HP DL360 Quad-Core E5405  @ 2.00GHz with 5GB Ram.
Local 10k SAS hdd only, no SAN, local mysql.
400 hosts, 1500 servicechecks.
1400 servicechecks are scheduled every minute, 100 once per day.

I do get roundabout 1100-1200 checks throughput each minute,
averaging 80% of the expected checks each minute with a very
good latency.

Check Execution Time:   0.01 sec        10.02 sec       0.417 sec
Check Latency:          0.00 sec        7.19 sec        1.623 sec 

I've done extensive performance tests and in summary the best
practices to speed up things:

- RAM, RAM, RAM. Both for mysql (see below) and for increased
  filesystem buffers.

- Reserve enough memory for mysql to keep things buffered as
  long as possible:

  I'm currently using these settings:
 
  innodb_buffer_pool_size = 1024M
  innodb_additional_mem_pool_size = 64M
  innodb_log_file_size = 512M
  innodb_log_buffer_size = 64M
  innodb_flush_log_at_trx_commit = 1

  Beware: this will spike up mysql memory usage to nearly 2GB virtual
  and roundabout 1GB of resident memory.

- use npcd for bulk processing performance data for pnp. Direct
  injections for each performance result will stall your checks
  and result in huge check latency

- set "data_processing_options=4061953" in your ndomod.cfg
  By default ndo parses and injects every event from nagios,
  which results in unnecessary mysql queries and bloats the
  database over time - even more slowing down ndo since it
  automatically purges old data. With this option you won't have
  any aging data and the database only holds realtime info
  Attention: This setting is totally perfect with Nagvis, but I have
  no clue if nagiosla needs ndo and what information - so double check
  that.

- I'm using "use_large_installation_tweaks=1" too, but I'm not sure
  if it would have any impact on your scenario.

- I've manually built an SQL index over some tables for ndo, but I
  doubt it would have much impact on your scenario either.

hth

Regards
        Sascha

-- 
Sascha Runschke
Netzwerk-  und  Systemmanagement
Telefon : +49 (201) 102-1879 Mobil : +49 (173) 5419665 Fax : +49 (201) 
102-1102105



GFKL Financial Services AG
Vorstand: Dr. Peter Jänsch (Vors.), Jürgen Baltes, Dr. Till Ergenzinger, Dr. Tom Haverkamp
Vorsitzender des Aufsichtsrats: Dr. Georg F. Thoma
Sitz: Limbecker Platz 1, 45127 Essen, Amtsgericht Essen, HRB 13522
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20080605/0ee7008f/attachment.html>
-------------- next part --------------
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
-------------- next part --------------
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null


More information about the Users mailing list