Ad Widget

Collapse

High CPU Load with Version 1.6

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • gaijinsan
    Junior Member
    • Sep 2008
    • 3

    #1

    High CPU Load with Version 1.6

    Compared to the Beta Version 1.5.5. Zabbix Version 1.6 has a higher CPU-Load.
    With Version 1.5.5 I had an average load of 0.72 with 2200 items to check.

    Now with verison 1.6 I have an load average of 2.5 !

    I'm using Debian Etch with mysql 5.0.32.
  • gaijinsan
    Junior Member
    • Sep 2008
    • 3

    #2
    Problem Solved !

    Added StartDBSyncers=1 inside zabbix_sender.conf

    Comment

    • Alexei
      Founder, CEO
      Zabbix Certified Trainer
      Zabbix Certified SpecialistZabbix Certified Professional
      • Sep 2004
      • 5654

      #3
      Originally posted by gaijinsan
      Problem Solved !

      Added StartDBSyncers=1 inside zabbix_sender.conf
      Please be aware of possible deadlock situations causing ZABBIX server to stop. The problem will be resolved in 1.6.1. It is safer to keep StartDBSyncers=0, however it depends on load of ZABBIX server and type of database engine.

      This is the reason why we decided to keep database cache switched off by default.
      Alexei Vladishev
      Creator of Zabbix, Product manager
      New York | Tokyo | Riga
      My Twitter

      Comment

      • dyost
        Junior Member
        • Oct 2008
        • 8

        #4
        CPU consumed in 1.6

        Greetings,

        I too tried to upgrade. I did so because it sounded like performance was "much better." Instead, the new 1.6 system consumed 100% of my CPU permanently--that sure won't work. I'm not monitoring all that many items, and on 1.4.4 it's fine.

        OS: Red Hat Enterprise Linux ES release 4 (Nahant Update 7)

        uname -a: Linux myhost 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 i686 i386 GNU/Linux

        zabbix_server --version:
        ZABBIX Server (daemon) v1.6 (18 September 2008)
        Compilation time: Oct 28 2008 18:56:24


        zabbix_agent --version:
        ZABBIX Agent (daemon) v1.6 (18 September 2008)
        Compilation time: Oct 28 2008 18:56:24


        mysql --version:

        mysql Ver 14.7 Distrib 4.1.22, for redhat-linux-gnu (i386) using readline 4.3


        php --version:
        PHP 4.3.9 (cgi) (built: Jul 15 2008 10:14:59)
        Copyright (c) 1997-2004 The PHP Group
        Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies


        After upgrading, the mysql process consumes 100% of CPU, all the time. I
        followed the instructions, compiled new binaries, ran the DB upgrade patch SQL scripts for MySQL (no apparent problems).

        The system WORKS--I can login to the frontend (after it prompts for reconfig), and all appears OK. But, again, the system is 100% consumed and that's definitely unacceptable.

        I noticed this:


        (see attachment--SQL "show processlist;" output--don't want to paste here due to line wrapping)


        I never get these "sorting results" lines in 1.4.4 -- there, it's always just
        the "sleep" processes, so even though the "time" on these is 0, I am suspicious that they are a key to the 100% consumption.

        Finally, I don't even have a "zabbix_sender.conf" and, when I tried creating
        one alongside the other config files and trying the fix from this thread (StartDBSyncers=1) it had no affect, even after a restart.

        I got no errors on build, compile, install, or anything. Again, the new 1.6
        system also functioned correctly, as far as I can tell.

        But since it also ground my machine to a halt, I had to undo it all, put 1.4.4 back (and restore database), and thankfully all appears fine (but I'm back on
        1.4.4).

        Why does 1.6 hammer a machine so?

        Thanks,
        Dan
        Attached Files

        Comment

        • bbrendon
          Senior Member
          • Sep 2005
          • 870

          #5
          dyost- Are you running 1.6.0? If so, then either run 1.4.x, 1.5.x or 1.6.1 beta.
          Unofficial Zabbix Expert
          Blog, Corporate Site

          Comment

          • dyost
            Junior Member
            • Oct 2008
            • 8

            #6
            Thanks much--so far, that did it. The CPU is very cool now, basically 0% consumed (100% idle).

            I had all kinds of database problems trying to run the 1.6.1 patch script (patch.sql) for MySQL, mostly due to my own error (I didn't realize with InnoDB you can't just manipulate the files in the DB directory so had orphaned tables to fix).

            But I got it all in sync and the CPU is fine...yet now I get all kinds of PHP errors such as this one:

            Undefined index: show_events_status[/app/zabbix/zabbix-1.6.1/frontends/php/tr_status.php:199]

            That's at the bottom of the trigger page (monitoring -> triggers). During the setup on the new frontend version, I had all sorts of other errors similar to the above, which I should have recorded. It installed OK, *appears* to be working OK, but messages like the above don't give me a warm fuzzy feeling.

            Any thoughts there?

            UPDATE: sorry, I should have searched first:



            The additional problems are known issues.
            Last edited by dyost; 07-11-2008, 00:37. Reason: other solution

            Comment

            • js1
              Member
              • Apr 2009
              • 66

              #7
              Originally posted by Alexei
              Please be aware of possible deadlock situations causing ZABBIX server to stop. The problem will be resolved in 1.6.1. It is safer to keep StartDBSyncers=0, however it depends on load of ZABBIX server and type of database engine.

              This is the reason why we decided to keep database cache switched off by default.
              I'm now running 1.6.8 with MySQL InnoDB. Some of our proxies are pretty heavily loaded. Under what conditions do you guys recommend enabling StartDBSyncers? Also, please explain what this does, technically? Thanks for any insights.

              Comment

              Working...