Re: [Nagios-users] Recommend hardware specs

2007-03-01 Thread Sean Keplinger

On Wed, 28 Feb 2007, [EMAIL PROTECTED] wrote:

> Do you guys agree with this list? The article also said that disk speed 
> (scsi) was also very important. I think I will be monitoring 1000> 
> hosts. With distributed nagios servers.

I'm running on an HP DL380 (dual 1.4Ghz PIII's) with 2GB RAM. The disks 
are SCSI, RAID5. The OS is SLES10. We have about 500 hosts and over 550 
service checks.

The load average is 3.01, 1.03, 0.51. Memory usage is about 1.5 GB with 
most of that in cache.

>From the results we've seen, the box that I'm using (although fairly old 
now) is over powered. Adding more service checks or increasing their 
frequency would probably have an impact on overall load.


HTH,
Sean
-- 
Sean Keplinger  /  Visit my Hiking/Backpacking and Projects
skeplin AT gmail DOT com   /   blog at: http://spookyworld.dnsalias.com/

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Nagios-users mailing list
Nagios-users@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


Re: [Nagios-users] Recommend hardware specs

2007-02-28 Thread Trask
> I was looking for some recommend hardware specs, but I didn't find any.
> The only think that I was able to find was in the "Apress Pro Nagios 2.0"  
> book, it had the following table:
>
> #of host# of cpuCPU SpeedMemoryDisk Space
> <1001800MHz+ 512MB+5GB+
> 100-500 1 1GHz+   1GB+10GB+
> 500-10001+3GHz+   1GB+20GB+
> 1000>   1+3GHz+   2GB+40GB+
>
> Do you guys agree with this list?

First off, when you get to doing your install, make sure to reference
this: http://nagios.sourceforge.net/docs/2_0/tuning.html.  It has lots
of things that will improve your performance.  Keep in mind when
reading the below that we have implemented almost all of those
suggestions.

I will give you the specs of our servers to give you an idea of what
we are seeing:

P4 2.4GHz / 512MB RAM / standard 7200 rpm IDE drive
4 nagios servers -- 3 doing active checks and one receiving all check
data passively (and filling in for any server that goes down).

One of the 3 servers doing active checks has a disproportionaly high
number of checks to do than the others.  It is the only one that shows
a load > 1.  It varies between 5-10 and usually runs up to a 30 second
check latency.

This server checks only 200 servers but about 2625 services in total.
About half of the services are passive (the client runs the check
code).

It is my feeling that that our performance isn't really all that bad
-- it is just that the sending of the results passively gets a little
backed up sometimes and causes the load count to go up.  Also note
that even with the high load, that particular server rarely goes into
swap even with only 512MB.


> The article also said that disk speed (scsi) was also very important.

I agree with this.  Although I have put the status.log on a ramdisk, I
still believe our performance is limited by our slow IDE disks.  I
can't prove that, though.


> And what are the benefits of the following technologies: 64bit, 
> Hyper-Threading
> and Dual-core in comparison with Nagios.

I don't have any idea about 64bit performance.  For HT and dual-core I
would imagine that it will help, but I think the real bottleneck is
the disk for us.  Our server with the most checks and highest load
uses on average about 30% cpu.  The central server, which runs nagios,
nrpe, ncsa, mysql/ndo2db, misc data collection/rrdtool scripts and
apache getting hit by 8+ people all the time runs at about 10% cpu
utilization (this machine has 1GB of mem and uses all of it, though).

> I'm using nagios 2.7, but maybe the upcoming nagios 3.0 will have different 
> specs?

No idea.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Nagios-users mailing list
Nagios-users@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


[Nagios-users] Recommend hardware specs

2007-02-28 Thread chiel
Hi,

I was looking for some recommend hardware specs, but I didn't find any.
The only think that I was able to find was in the "Apress Pro Nagios 2.0"  
book, it had the following table:

#of host# of cpuCPU SpeedMemoryDisk Space
<1001800MHz+ 512MB+5GB+
100-500 1 1GHz+   1GB+10GB+
500-10001+3GHz+   1GB+20GB+
1000>   1+3GHz+   2GB+40GB+

Do you guys agree with this list? The article also said that disk speed (scsi) 
was also very important.
I think I will be monitoring 1000> hosts. With distributed nagios servers.

And what are the benefits of the following technologies: 64bit, Hyper-Threading 
and Dual-core in comparison with Nagios.
I'm using nagios 2.7, but maybe the upcoming nagios 3.0 will have different 
specs?

Like to see you comments.

-- 
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Nagios-users mailing list
Nagios-users@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