RPi2 - Hohe CPU Last in iceweasel mit FTUI

[moelski]

Moin !

Ich habe zwar schon die Frage am Start mit kweb, aber das Thema würde mich dennoch mal interessieren.
iceweasel hat auf meinem Pi 2 immer eine extreme Speicher und CPU Last. Der speicher wäre mir noch fast egal. aber die CPU Last bremst irgendwann merklich ftui aus.

Und ich habe keine besonderen Elemente auf den Seiten. Was ich aber nutze ich Shortpoll.

Hat jemand ähnliches festgestellt? Gibts da eine Lösung?
Plugins sind übrigens auch keine installiert.

Grüße Dominik

[roman1528]

Moin.

Ich habe das alles auch auf meinem Pi gestestet mit Chrome im Kiosk-Mode und und und... Wollte den Pi nämlich mit TouchScreen im Flur haben um nicht noch ein Tablet aufhängen zu müssen. Aber damit ist der Pi gnadenlos überfordert....

Die hohe CPU-Last rührt meist daher, dass, auch wenn die Programme für armhf gemacht sind, die Programme nur im Single-Core Modus arbeiten und nicht Multi-Threaded mit allen 4 Kernen.
Genau wie FHEM... statt die Last auf 4 Kerne auf zu teilen wird nur ein Kern belastet der dann mehr und mehr in den Arbeitsspeicher auslagert.

Nächstes bzgl. Arbeitsspeicher... FTUI und alles was dazu nötig ist hat einen hohen Speicherbedarf. Die generierung der Seiten, cachen der CSS-Dateien (nicht deaktivierbar) und und und.

Grüße^^

[moelski]

Moin !

Die hohe CPU-Last rührt meist daher, dass, auch wenn die Programme für armhf gemacht sind, die Programme nur im Single-Core Modus arbeiten und nicht Multi-Threaded mit allen 4 Kernen.

Single Core ist ja erstmal nicht das große Problem. Und das eine CPU stärker mit dem iceweasel Prozess belastet wird .. nun gut damit könnte ich leben.

Aber ich habe eine ständige CPU Last von 37% ohne das der Browser erkennbar irgendwas tut. Lediglich FTUI ist aufgerufen und das aktualisiert ja im Grunde nur die Webseite alls 30 Sekunden.

Habe mal die CPU Usage beobachtet wenn FTUI geladen ist. Im Normalfall dümpelt der Browser so mit 2-4% CPU Last daher. Und alle 30 Sekunden gibt es einen Peak von ~25% nämlich beim Polling/Update der Daten. Soweit alles ok. Bleibt die frage warum die CPU nach ein paar Tagen auf 37% Dauerlast geht.

Ich habe jetzt mal alles auf LongPoll umgestellt. Und mir ist aufgefallen das ich noch Debug eingeschaltet hatte.
Werde es mal weiter beobachten ...

Grüße Dominik

[Bennemannc]

Hallo,

standartmäßig sind für den RPI ja auch andere Webbrowser vorgesehen bzw. vorinstalliert, die nicht soviel Performance fressen wie der Icewaezel. Vielleicht reichen diese ja auch für Dein Vorhaben ?

Gruß Christoph

[moelski]

Hi Christoph,

schon klar. Aber die tun nicht so wie sollen ...
Siehe mein anderes Posting:
http://forum.fhem.de/index.php/topic,49768.0.html

Grüße

[ekur]

Hallo moelski,

ich habe die gleiche Thematik auch bei mir beobachtet. Nach 4 Tagen Dauerlauf von FTUI (über Webviecontrol) auf einem Android Samsung Tab2 ohne sonstige Hintergrundaktivitäten wird einer der 2 Kerne permanent ausgelastet und der zweite muss immer mal wieder dazu helfen (je nachdem was ich gerade am Tablet drücke und mir anzeigen lasse). Da es ein 2Kerner mit 1GHZ ist entspricht das ungefähr deinen 37% bei einem 4Kerner (ausser Du meintest das nur ein Kern mit 37% ausgelastet ist). Es macht bei meinem Android auch keinen Unterschied ob der Bildschirm auf Helligkeit 1 (in der Nacht) oder 120 (am Tag) steht, das Ding zieht immer den gleichen Strom,ich habe Nachts und am Tag die gleichen Laufzeiten (also Entladezeiten und Ladezeiten) für den Akku.

[moelski]

Moin !

Da ich werde einen anderen Browser (ala kweb o.ä.) nutzen kann - denn die funktionieren nicht sauber - habe ich nun eine etwas "harte" Lösung.

Ich starte iceweasel per crontab Nachts neu.

Habe mir dafür ein Script angelegt "start.sh" mit folgendem Inhahlt:

Code Auswählen Erweitern

#!/bin/bash
kill -15 iceweasel
sudo -u pi DISPLAY=:0 iceweasel

Iceweasel ist so eingestellt das er eine Startseite nach dem Start aufruft - FTUI.

Die Datei mit chmod 700 ausführbar machen.

Und dann in /etc/crontab noch folgendes:

Code Auswählen Erweitern

15 0 * * * root /home/pi/start.sh

Nicht die schönste Lösung, aber mir reicht das so ...
Und der Pi3 wird meinem FHEM Rechner bald zusätzlich unter die Arme greifen 

Grüße

[TiPpFeHlEr]

Hi,

gibt es bezüglich der CPU Auslastung eine Lösung?

getestet mit firefox-esr & chrome

beide erzeugen eine single core CPU Last von 100% wenn die FTUI Seite geladen ist.

kann man an der Performance etwas machen?
Wichtig ist hierbei der KIOSK Mode, den benötige ich.
Gibt es schlankere Browser die KIOSK unterstützen aber weniger Rechenleistung benötigen?


Oder liegts einfach an der Seite die ich aufrufe, ist dort etwas falsch oder Last fressend programmiert?

Das ist meine index.html

Code Auswählen Erweitern

<!DOCTYPE html>
<html>
<head>
    <!--
     /* FHEM tablet ui */
     /*
     * UI builder framework for FHEM
     *
     * Version: 2.2.*
     * URL: https://github.com/knowthelist/fhem-tablet-ui
     *
     * Copyright (c) 2015-2016 Mario Stephan <mstephan@shared-files.de>
     * Under MIT License (http://www.opensource.org/licenses/mit-license.php)
     *
     * - create a new folder named 'tablet' in /<fhem-path>/www
     * - copy all files incl. sub folders into /<fhem-path>/www/tablet
     * - add 'define TABLETUI HTTPSRV ftui ./www/tablet Tablet' in fhem.cfg
     * - Tadaaa! A new fhem ui in http://<fhem-url>:8083/fhem/tablet/
     */
    -->
    <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=2.0, minimum-scale=0.5, user-scalable=yes" />
    <meta name="widget_base_width" content="45">
    <meta name="widget_base_height" content="41">
    <meta name="gridster_cols" content="14">
    <meta name="gridster_rows" content="9">
    <meta name="mobile-web-app-capable" content="no">
    <meta name="apple-mobile-web-app-capable" content="no">
    <meta name="gridster_disable" content="0">
    <meta name="longpoll" content="1"> <!-- 1=longpoll;0=shortpoll every 30sec -->
     <!--   <meta name="longpoll_type" content="websocket">        -->
    <meta name="debug" content="0"> <!-- verbose level 1-6 = output to console;0 = not output -->

    <link rel="stylesheet" href="lib/jquery.gridster.min.css" />
    <link rel="stylesheet" href="css/fhem-tablet-ui.css" />
    <link rel="stylesheet" href="lib/font-awesome.min.css" />
    <link rel="stylesheet" href="lib/jquery.toast.min.css" />
    <link rel="stylesheet" href="lib/icomoon.css" />
    <!-- define your personal style here, it wont be overwritten  -->
    <!-- link rel="stylesheet" href="css/fhem-green-ui.css" / -->
    <link rel="stylesheet" href="css/ftui_maik.css" />

    <script src="../pgm2/jquery.min.js"></script>
    <script src="lib/jquery.toast.min.js"></script>
    <script src="lib/jquery.gridster.min.js"></script>
    <script src="js/fhem-tablet-ui.js" defer></script>


    <!-- Remove this line to enable for usage with WebViewControl
    <script defer>var wvcDevices = {'12345': 'Tablet'}; var wvcUserCssFile="webviewcontrol.css"</script>
    <script src="../pgm2/cordova-2.3.0.js" defer></script>
    <script src="../pgm2/webviewcontrol.js" defer></script>
    <!-- End for WebViewControl -->

    <title>FHEM-Tablet-UI</title>
</head>
<body>
<div class="gridster">
<ul>

<li data-row="1" data-col="1" data-sizex="2" data-sizey="9">
<header><div data-type="label" class="medium orange">FHEM</div></header>
            <div class="cell">
                <div data-type="pagebutton" data-url="#Power.html"      data-load="#Power" data-off-background-color="transparent" data-off-color="#606060" data-on-background-color="#606060" data-on-color="#222222" data-active-pattern="(.*/||.*#Power.html)"                            data-icon="oa-measure_power"    class="default top-space"></div>
        <div data-type="pagebutton" data-url="#Wifi.html"    data-load="#Wifi" data-off-background-color="transparent" data-off-color="#606060" data-on-background-color="#606060" data-on-color="#222222" data-active-pattern="(.*#Wifi.html)"       data-icon="oa-it_wifi"          class="prefetch top-space"></div>
                <div data-type="pagebutton" data-url="#Control.html"      data-load="#Control" data-off-background-color="transparent" data-off-color="#606060" data-on-background-color="#606060" data-on-color="#222222" data-active-pattern="(.*#Control.html)"                      data-icon="oa-message_socket"   class="prefetch top-space"></div>
                <div data-type="pagebutton" data-url="#Heating.html"    data-load="#Heating" data-off-background-color="transparent" data-off-color="#606060" data-on-background-color="#606060" data-on-color="#222222" data-active-pattern="(.*#Heating.html)"                data-icon="oa-sani_heating"     class="prefetch top-space"></div>
                <div data-type="pagebutton" data-url="#Alarm.html"    data-load="#Alarm" data-off-background-color="transparent" data-off-color="#606060" data-on-background-color="#606060" data-on-color="#222222" data-active-pattern="(.*#Alarm.html)"                data-icon="oa-message_presence" class="prefetch top-space"></div>
                <div data-type="pagebutton" data-url="javascript:history.go(0)"                      data-off-background-color="transparent" data-off-color="#606060" data-on-background-color="#606060" data-on-color="#222222" onclick="location.reload(true);"                                                     data-icon="fs-refresh"          class="top-space"></div>
               
            </div>
</li>

<li data-row="1" data-col="3" data-sizex="1" data-sizey="1">
            <div class="page" id="Power"></div>
        <div class="page" id="Wifi"></div>
            <div class="page" id="Control"></div>
            <div class="page" id="Heating"></div>
            <div class="page" id="Alarm"></div>
</li>

</ul>
</div>
</body>
</html>


Grüße Maik

[roelb]

I've had this exact same issue. The code for tablet ui (and most widgets) is a mess. Quickly looking it, it really needs a major rewrite.

I have found some causes of the CPU hog though.

In fhem-tablet-ui.js, apply the following patch:

*** /data/mnt/root/data/fhem/www/tablet/js/fhem-tablet-ui.js    2020-04-12 10:49:49.157475933 +0200
--- fhem-tablet-ui.js   2020-07-26 22:48:26.382179377 +0200
***************
*** 942,950 ****
          ftui.poll.long.lastEventTimestamp = new Date();
          if (ftui.config.doLongPoll) {
              ftui.config.shortpollInterval = $("meta[name='shortpoll_interval']").attr("content") || 15 * 60; // 15 minutes
              ftui.poll.long.timer = setTimeout(function () {
                  ftui.longPoll();
!             }, 0);
          }
      },
 
--- 942,951 ----
          ftui.poll.long.lastEventTimestamp = new Date();
          if (ftui.config.doLongPoll) {
              ftui.config.shortpollInterval = $("meta[name='shortpoll_interval']").attr("content") || 15 * 60; // 15 minutes
+           if (ftui.poll.long.timer) clearTimeout(ftui.poll.long.timer);
              ftui.poll.long.timer = setTimeout(function () {
                  ftui.longPoll();
!             }, 50);
          }
      },


Some other low hanging fruit, if you're using widget_analogclock:

*** /data/mnt/root/data/fhem/www/tablet/js/widget_analogclock.js        2019-08-30 18:27:55.000000000 +0200
--- widget_analogclock.js       2020-07-26 22:39:55.645115621 +0200
***************
*** 227,233 ****
                        clock.secondHandColor = elem.data('second-color');
                        clock.bossColor = elem.data('boss-color');
 
!                       window.setInterval(function() { clock.draw() }, 50);
          });
      }
 
--- 227,233 ----
                        clock.secondHandColor = elem.data('second-color');
                        clock.bossColor = elem.data('boss-color');
 
!                       window.setInterval(function() { clock.draw() }, 1000);
          });
      }


Really no need to refresh an anolog clock 20 times a second. Once every second is more than enough. Really, don't people think about resource usage anymore when they are programming?