Zabbix 1.8.1

[jgerry]

I retract my earlier statement about our performance problems going away. They've returned.

The utter randomness of Zabbix's behavior, the lack of consistent performance, are causing me and my company a lot of pain. We've upgraded to a larger server, configured a custom MySQL server with multiple I/O paths to handle the heavy database load, and all that was working OK -- not great, still a lot of random behavior, but tolerable. The 1.8 upgrade, for us, increased resource utilization by a factor of 5x - 10x. Totally unacceptable.

Here's a graph (I do love the new graphs in 1.8, that's a positive comment) of our CPU utilization over the past month, I've shown where we did upgrades and/or changes:



We're getting very close to throwing Zabbix away entirely. It's behavior is simply not reliable & consistent, and that is not what we want in a monitoring product. We're looking at support options, but I'm having a lot of trouble convincing my management to spend $4000 or $8000 a year on something that's already not somewhat stable & reliable.

[jgerry]

Last update for today: Though I did convert our database to UTF8 before the 1.8 upgrade, I've decided I'm going to try and dump our entire database again (about 15GB), check all our character encodings, make sure the conversion to UTF8 went as planned, build a new database from scratch, and re-import our data. Maybe this will help with some of our issues.

[richlv]

damn. was finishing a long, insightful comment. single electricity glitch... everything's lost.

I retract my earlier statement about our performance problems going away. They've returned.

The utter randomness of Zabbix's behavior, the lack of consistent performance, are causing me and my company a lot of pain. We've upgraded to a larger server, configured a custom MySQL server with multiple I/O paths to handle the heavy database load, and all that was working OK -- not great, still a lot of random behavior, but tolerable. The 1.8 upgrade, for us, increased resource utilization by a factor of 5x - 10x. Totally unacceptable.

not only unacceptable, but quite weird as well. according to developers, 1.8 should bring some 10 time better performance, which has also been the case for most users.
this sounds like some extreme edge case, or serious misconfiguration.

Here's a graph (I do love the new graphs in 1.8, that's a positive comment) of our CPU utilization over the past month, I've shown where we did upgrades and/or changes:
...
We're getting very close to throwing Zabbix away entirely. It's behavior is simply not reliable & consistent, and that is not what we want in a monitoring product.

i'm not gonna retype all the questions again - and it would still require quite a lot of forth-back communications. maybe you can try #zabbix on freenode, and me or somebody else can provide some hints.

We're looking at support options, but I'm having a lot of trouble convincing my management to spend $4000 or $8000 a year on something that's already not somewhat stable & reliable.

as i said, your situation hardly sounds normal. unless you resolve the problem soon, i'd suggest contacting sales/support - i'm sure you can come to a reasonable agreement

[Alexei]

I retract my earlier statement about our performance problems going away. They've returned.

The utter randomness of Zabbix's behavior, the lack of consistent performance, are causing me and my company a lot of pain. We've upgraded to a larger server, configured a custom MySQL server with multiple I/O paths to handle the heavy database load, and all that was working OK -- not great, still a lot of random behavior, but tolerable. The 1.8 upgrade, for us, increased resource utilization by a factor of 5x - 10x. Totally unacceptable.

It is difficult to comment without seeing all details. Zabbix 1.8.x was designed to deliver 5x-10x better performance and much lower database load. We received very positive feedback so far.

I am absolutely with you, the numbers you have after the upgrade are not-acceptable, however (again) I do not see the whole picture, perhaps the high CPU load was caused by significant reduction of disk IO resulting in a much better performance in terms of a number of checks processed in second.

There is no randomness built-in Zabbix, I swear. In most cases it is caused by spikes of item checks, housekeeper and database-side activities.

I am absolutely confident we can help. Please send an email to support @ zabbix.com with a reference to this thread and we will investigate it. For free.

[Alexei]

Rich, you are quick!

[jgerry]

Alexi -- I appreciate your comments. Of course randomness shouldn't be built in! I'm going to try and work through our issues. Rebuilding the database, I think, is a good start.

We really like the product overall. The "randomness" to which I refer is things like sending out 20+ of the same alert emails, missing periods of data collections, and triggers & events with unknown statuses. That, and the constantly fluctuating load on the servers. I expect some variation, but not that much.

[jansonz]

We are also not happy with new Zabbix 1.8.x

Next week I have to deside to move on with Zabbix, downgrade to old version or think about changing our monitoring system. It seems that it will be the last choice..

Zabbix is great product, but it seems that it is not possible to use it in Enterprise enviroment. I'm also are not shure, that if we order Zabbix support, all our problems will desapeare.

[Palmertree]

I had the same issues everyone else had but solved it by converting the "ids" table to "MyISAM" but left the other tables to "Innodb". I was seeing a lot of deadlocks on the ids table where the pollers where trying to update the ids fields at the same time. Using MyISAM table type for the ids table got rid of 100% of slowness and issues we were having. We are monitoring about 888 host with 65,000 items using 50 pollers with very good response times. Poller has not been restarted for about 8 days now.