I'm only monitoring 6 server and Zabbix can't keep up

[johnw230873]

I must be doing something wrong but unsure what

I am monitoring 6 servers and each server is monitoring 38 items each. Out of the 38 items, 18 of them are at 10 second update as I'm wanting to monitor these as close to real time as possibly.

The issue I'm having is that I always have a queue of about 67 items and I'm only on avg processing 7 values a second. This is causing me to loose values on my graph etc

Can I monitor this amount of servers and items at a 10 second period?

I'm thinking it could be the agents that is the problem, is there anything here I can do?

Cheers

[walterheck]

Can you tell us the configuration your using? HW in the server, software used, other software on that server, etc.

[johnw230873]

As I'm only testing Zabbix to see if it would work in our environment I have been testing both the VMDK and the Live CD versions of 1.8.3 or 2 machines

The VMDK was being used Dual core laptop with 4 Gb of ram (only 512 allocated to the VMDK) and the live CD was tried on another machine with about the same specs as the laptop, I did this as I wanted to rule out the VMDK.

Configuration is just the standard out of the box.

A example of the 10 second update checks is
Agent Type: Zabbix_agent
Key: perf_counter[\LogicalDisk(M\% Disk Write Time]
Update interval (in sec): 10
everything is default

Agents are the windows 1.8.3 64 bit.

The Zabbix server also gets delays in the queues when updating it's own information (if that helps)

[eas]

A few things:

1. you mention that Zabbix gets backed up just updating its internal information. If that internal info includes "zabbix[history]," or "zabbix[history_str], get rid of them. I tried setting those up when I was trying to diagnose my performance problems, and they resulted in obscene disk I/O.

2. From the reading I've done, it doesn't sound like this should be as big a problem on 1.8.3, but on 1.8.2 server, I had some mis-configured items that caused big backups. There were items that were trying to store integers for keys that reported floating point values. These seemed to cause things to get backed up. Before I knew what was going on, I tried lots of tuning of #of processes and time-outs, which sort of helped, but fixing or disabling the bad items seemed to clear stuff out for good.