Announcement

Collapse
No announcement yet.

RPI3 average load high

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    RPI3 average load high

    Hey, im trying to iron out delays for my lights and wondering if im pushing the limit of the RPI3. I have the full linux version of hs3 running on my pi, nothing else. when i run the htop command it shows me that the processors are spiking to 98% every 30 seconds or so, only one at a time but the average load figure is nearly double that what ive read it should be. Ive attached these below, one shows the spike and the other when no spike is present

    Edit: sorry for the image quality, dont know whats happened there
    Attached Files

    #2
    Ok so i stopped homeseer on the rpi and restarted this morning and the cpu usage was cut dramatically. Currently running at a load average of 1.14, 1.2, 1,96 now after half hour of uptime, ill monitor through out the day and night to see if the delays are present and if the cpu usage creeps back up.

    Can anyone think of a reason why homeseer would need more cpu resources over time?

    Also I cannot figure why I have two instances here of the HSconsole.exe using so much of the cpu, I know one is sleeping but I imagine it is being run, then sleeping, quicker than a one second interval that htop uses for monitoring whether a process is running or not. Can anyone else using homerseer on a rpi please check to see if they see the same as below. Many thanks
    Attached Files
    Last edited by Steaktastic87; March 11, 2018, 07:59 AM.

    Comment


      #3
      Last edited by mwolter; March 11, 2018, 09:05 AM.

      Comment


        #4
        Yeah i've had a quick look but most posts are old and relate to a specific plugin.

        I have 4 plugins

        ZWave - 20% cpu usage at its worst (spikes), 10-14% average
        IFTTT - below 1%
        NEST - below 1%
        Ultralighting - 7% at worst, 4% average

        I think i can rule plugins out but that is assuming i can rely on the refresh rate of htop for the accurate cpu usage. I dont know if theres a way to pull the max cpu usage for a specific process, maybe some clever linux guy knows some code to do that.

        Ive selected the tree view on htop to further break down the processes but im still left with multiple HSconsole.exe -- log and one instance of these is using over 100% in the R (running state) with a runtime of 3hr02 say and another further up the tree in the S (sleep) state using over 100% and a runtime of 3hr26 (established this switches from run to sleep too quick for the htop refresh). With my limited knowledge i have no idea why there are many instances of the same process and why some are using virtually using no cpu time yet 2 are pretty much constantly running.

        Ive attached yet another screenshot and highlighted one of the HSconsole cpu hogs (constantly running instance)
        Attached Files

        Comment


          #5
          So did a quick search to find linux commands to get a real time cpu use but found this command which basically replicates htop/top output but it gave me the actual command for the process of the HSconsole.exe instances. Does anyone have more info on these?


          First one is the constantly running process - Timer-Scheduler ??
          Second is sleeping/running - (system)_11-mar
          Attached Files

          Comment


            #6
            So from running atop, another monitoring linux tool i came to the conclusion that the Sleeping HSconsole.exe process is a total of all the HSconsole.exe processes running/sleeping which makes sense as i would off expected to see two of the four cpus hitting the 100% mark (if you added up the cpu% consumed by both i highlighted in the above post).

            So seems to me homeseer is the culprit but finding out why is the next stage. Im running raspbian stretch lite, would be interesting to see other peoples cpu usage on this version so i can rule that out. Thanks


            Edit: below i captured it when one of the processors was at critical level highlighted in red by atop, above that you will see CPU which is total% of all 4 cpu usage. atop is measured in 10s intervals as opposed to top/htop which is 1s. Below the highlighted header is the cpu consuming process with PID 29032
            Attached Files

            Comment


              #7
              Spent the time using a spare new raspberry pi 3, rebuilt a new sd card exactly as my current one, installed homeseer but did no configuration at all, no events plugins etc. The average load was below 0.2 on all values (cant remember exact values). So booted back up the old pi and the average load values had dramatically dropped, running at 0.18 , 0.18, 0.18.

              It appears the cpu usage spikes when a event runs, the plugin does not exceed what i observed before 10-15% for zwave plugin but the same HSConsole.exe -- log processes spike the cpu to about 40%. After 30 mins of uptime that spike is now increased back to 100% so the load averages will inevitably begin to increase again.

              The light delays are gone but i predict over time it will deteriorate again. I can only speculate that the cpu processes get that backed up, it can delay the motion led on my aeotec multisensors 6 from lighting up or even detecting motion at all.

              Ill monitor over the next few days to see what occurs. I could do with anyones inner working knowledge of the two HSConsole.exe --log processes Timer-Scheduler and (system) or any settings or homeseer setup practices i may have done/missed for how best to proceed
              Last edited by Steaktastic87; March 11, 2018, 05:38 PM.

              Comment


                #8
                Might be an idea to tell us what version of Raspbian and Mono you are using. The more info the better chance you might get some help here.

                Unresolved or incomplete events can cause unexplained spikes in some cases. What version of HS3 are you using. What version of the Z-Wave is running. Usually a process of elimination helps too. What class of SD card are you using. So many factors could be in play here both hardware and software.

                Disable all plugins and events. Re enable them one by one until you can recreate the problem

                Comment


                  #9
                  That looks a lot like what I was seeing a while back, with load averages staying up around 4 and 5. I spent a LOT of time trying to track it down and got nowhere. Both of my RPi3 HS3 systems were bogging down with more than three or four plugins, and it didn't seem to matter which plugins. I tried running some remotely, and that helped a little. For one of my systems I ended up upgrading to more powerful hardware.

                  But on my other system, I left it as is. I am now running 10 plugins on that same system (7 local and 3 remote) with a load average under 2. The only changes were an upgrade to mono 5 (currently 5.10.0.160) and installing the most recent HS3 betas (currently .423). At least on my system, it has significantly improved performance.

                  Comment


                    #10
                    RPI3 average load high

                    Which version of HS3?
                    Are you running power monitoring?
                    Are you running HSTouch service in HS3?
                    Do you have your timers/counters listed in your devices menu?
                    Which version of mono?
                    Which version of RASPBIAN are you running?
                    Are you running GUI ON THE OS?
                    How many devices are you controlling?
                    How many scripts do you have setup?


                    Sent from my iPhone using Tapatalk

                    Comment


                      #11
                      Yeah I apologise didn't give much info on my setup. During my late night reading i stumbled across the homeseer version updates topic and read through the entirety, came across a post from rich regarding a problem with the timer scheduler process which has now been resolved in an update.

                      Currently running homeseer version .368, didn't realise how far behind I am. Mono version is 4.62 i think so I'll make sure to update that too aswell as zwave plugin but think I have the latest.

                      All being well once updated I shouldn't see these delays but now I have better knowledge of Linux tools I can troubleshoot them quicker than my trial an error approach. Had these delays from day one and it's hard to know where to look, everyone's hardware/setup is different.

                      Luckily my system is currently very basic and just running light automation events for 3 rooms (was alot more complex but was trying to limit the variables involved). No scripts apart from a autostart service but I've setup the new pi with the same but with no events or plugins so will monitor that.

                      I appreciate the responses and I'll post back here with results and more info if it itsnt resolved.

                      Comment


                        #12
                        Just decided to go one step at a time. Removed mono completely and installed the latest stable version 5.10.0.160 and so far cpu has stabilised and load averages are at 0.19, 0.18, 0.20 after a runtime of 2hrs. The spike when the timer-scheduler process kicks in has been reduced to 10% now.

                        Ill probably update homeseer version at the end of this week once i've monitored for longer, see if the delays return. At least then i know i have a stable version to roll back to.

                        Comment


                          #13
                          Curious if you are using Stretch lite or Jessie lite?

                          You can update Jessie to Stretch in vivo...takes a bit of time and easy.
                          - Pete

                          Auto mator
                          Homeseer 3 Pro - 3.0.0.548 (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU 16Gb
                          Homeseer Zee2 (Lite) - 3.0.0.548 (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro
                          HS4 Lite - Ubuntu 22.04 / Lenovo Tiny M900 / 32Gb Ram

                          HS4 Pro - V4.1.18.1 - Ubuntu 22.04 / Lenova Tiny M900 / 32Gb Ram
                          HSTouch on Intel tabletop tablets (Jogglers) - Asus AIO - Windows 11

                          X10, UPB, Zigbee, ZWave and Wifi MQTT automation-Tasmota-Espurna. OmniPro 2, Russound zoned audio, Alexa, Cheaper RFID, W800 and Home Assistant

                          Comment


                            #14
                            Originally posted by Steaktastic87 View Post
                            Just decided to go one step at a time. Removed mono completely and installed the latest stable version 5.10.0.160 and so far cpu has stabilised and load averages are at 0.19, 0.18, 0.20 after a runtime of 2hrs. The spike when the timer-scheduler process kicks in has been reduced to 10% now.

                            Ill probably update homeseer version at the end of this week once i've monitored for longer, see if the delays return. At least then i know i have a stable version to roll back to.
                            What version of Raspbian are you using, Jessie or Stretch.

                            Comment


                              #15
                              I recently rebuilt on stretch lite and completely rebuilt homeseer events etc from scratch back in December after having kitchen/lounge done and added two more wired in aeotec multisensors, hoping to strengthen my zwave network and rid these delays.

                              Previously ran Jessie lite and random delays were consistent and apparent in this and the stretch setup.

                              Was and still running homeseer .368

                              Comment

                              Working...
                              X