Hallo! Ich habe folgendes Problem - wollte einen 2. Raspberry Pi mit FHEM installieren und habe alles so gemacht wie hier (und auf meinem seit jetzt fast einem Jahr mit FHEM laufenden Pi...)
http://www.computerhilfen.de/info/schnell-anleitung-fhem-auf-einem-raspberry-pi-installieren.html
Also SD Karte formatiert, Noobs aufgespielt, Raspbian installiert, dann Perl geladen und FHEM. Das hat auch wunderbar geklappt, konnte direkt mit dem Browser darauf zugreifen. Nach einem Neustart des Rechners läuft Perl aber plötzlich mit 100% CPU Last (wenn ich den Befehl "top" eingebe), der Browser versucht zwar noch, sich mit dem Rechner zu verbinden, es kommt aber keine Seite. Habe das ganze an einem 2. Raspberry probiert mit einer ebenfalls neuen SD Karte, wieder formatiert, installiert etc. Bis zum Neustart funktioniert alles problemlos, danach läuft auch da FHEM mit 100% und liefert keine Webseite mehr aus.
Update: Auch auf dem neuen Raspberry Pi 4 machte FHEM / Perl bei mir Probleme und kam auch wieder auf immerhin über 55% CPU Last. Interessanterweise lief dann auch MPD (für die Audio-Ausgaben von FHEM bei mir zuständig) mit über 60%. Einen Trick gibt es aber: Wenn ich den Start von FHEM mit einem "sleep 5" um 5 Sekunden verzögere, läuft alles normal und Perl und MPD haben wieder eine einstellige CPU-Auslastung - jetzt auf mehreren Raspberry Pis getestet. Wie das aussehen muss, habe ich hier als Screenshot für Euch: https://www.computerhilfen.de/hilfen-64-426312-0.html
Ich hoer das zum ersten mal.
Ich wuerde FHEM abschiessen, in fhem.cfg "attr global verbose 5" setzen, FHEM neu starten, und danach das logfile pruefen.
Im "normalen" Log-file (ohne verbose 5) ist nichts ungewöhnliches zu erkennen, ist ja auch noch fast leer, da frisch installiert... :)
Mit einem "kill PROZESSID" oder "killall perl" komme ich nicht weiter, der Prozess lässt sich anscheinend nicht beenden (kommt aber keine Fehlermeldung). Kann ich das "verbose 5" einfach über die Konsole in die fhem.cfg schreiben und dann neustarten?
Kann es sein, dass auf dem alten (funktionierenden) RasPi eine ältere Raspbian Version mit älterem Perl läuft als auf dem neuen? Kann ich erst später prüfen - aber kann es an so etwas liegen?
Komischerweise läuft es jetzt, nachdem der Rechner die Nacht über aus war...
Perl ist im Moment in der Top-Liste gar nicht mehr zu sehen...
Aber: Die installierten Perl-Versionen sind tatsächlich unterschiedlich: Perl 5.14.2 auf dem Rechner, der seit langem läuft und Perl 5.20.2 auf dem neuen Rechner...
Ich werde das mal weiter beobachten :)
edit:
Leider zu früh gefreut, nach kurzer Zeit ist der Server-Load wieder auf 100.0% gestiegen und die Seite wird im Browser wieder nicht geöffnet :(
Also die Perl-Version würde ich jetzt erst mal nicht als Ursache erkennen. habe hier auch eine 5.20.2 laufen, allerdings x86
Hast Du Zusätzliche Perl-Module aus Nichtpacketquellen installiert?
Hallo,
ich habe seit heute ein ähnliches Problem.
Nache dem Update des Ubuntu läuft perl mit 99% Systemlast. Ich kann es auch nicht via kill abschießen.
Meine fhem-Startseite ist nicht erreichbar.
Wie kann ich den Rechner starten, ohne perl zu starten? Ich würde dann alle Schritte manuell ausführen.
Ich habe mich an die oben verlinkte FHEM Anleitung gehalten - und auf 2 anderen PIs mit dem älteren Wheezy lief es problemlos. Ob es an Perl liegt, weiß ich nicht, dass war nur eine Vermutung, weil es für FHEM ja dringend nötig ist und eine andere Version.
Ich habe das Problem gelöst, indem ich alles platt gemacht habe und Raspbian mit Wheezy installiert. Jetzt geht es :-)
Hallo,
kann das nur bestätigen. Hatte mit Jesie auch 100% CPU Last auf einem RPI2.
Nach dem flashen von Wheezy läuft wieder alles.
LG
Hallo Zusammen,
gibt es inzwischen eine Lösung für dieses Problem ? Oder muss ich downgraden auf Wheezy ?
Ich muss demnächst mein FHEM von der Fritzbox werfen (also update einspielen), sonst funktioniert angeblich mein Internetzugang nicht mehr.
Auf dem RaspberryPi habe ich nach dem Booten 100% CPU durch Perl, wenn ich den den Prozess kille und FHEM neustarte scheint alles normal zu laufen.
Wie startest Du denn fhem automatisch?
Hallo,
jetzt kommt leider mein (noch) nicht vorhandenes Wissen auf dem RaspberryPi, auf der Fritzbox hat ja immer alles einfach funktioniert.
Auf dem Raspberry
gibt es in
etc/init.d/
fhem
Das ist wohl der Autostart ?
Wenn es ein Debian basiertes Linux ist kannst probieren:
update-rc.d fhm remove
Damit wird erstmal fhem aus dem Autostart rausgenommen.
Anschließend kannst Du probieren, ob ein manueller Start funktioniert, also in der Console:
/etc/init.d/fhem start
Bitte prüfe dabei parallel (z.B. in einem 2. Fenster) die CPU-Auslastung (am besten mit "top")
Wenn ich es aus dem Autostart rausnehme und mit /etc/init.d/fhem start von Hand starte läuft es.
In top ist dabei nichts auffällig.
Scheint ein Timing-Problem zu sein ?!
Ich habe jetzt in /etc/init.d/fhem
nach
echo "Starting fhem..."
folgendes eingefügt
sleep 20s
Jetzt bleibt er beim booten nicht mehr hängen und perl taucht in top nicht mehr auf.
Alternativ kannst Du probieren, die "Dependencies" zu ändern,
also folgende Zeile anpassen:
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
z.B. könntest Du probieren, es nach dem Netzwerk starten zu lassen
Alternativ, es per "/etc/rc.local" zu starten, habe es bei mir so gelöst.
Ahoi,
das Problem liegt meinen Erkenntnissen nach am Zeit per ntp setzen. Das steht auch glaub irgendwo in der Doku das man sicherstellen soll, das die Zeit VOR dem Start von fhem stimmt. Im normalfall wird aber wohl die Zeit "etwas" nach fhem korrekt gesetzt, dadurch dreht der Perl Prozess durch.
Der fuer mich sauberste Fix war das Startscript von fhem anzupassen und ins required-start noch $ntp mit rein zu nehmen. Damit wird sichergestellt das fhem erst nach dem NTP gestartet wird und das Problem war weg.
HTH,
Sven
Hallo,
ich habe jetzt $ntp bei required-start hinzugefügt, und meinen sleep auf 2 runtergesetzt.
Ich dachte ich hätte das schonmal ausprobiert und fhem hat dann nicht mehr gestartet.
So scheint es im Moment auf jeden Fall zu funktionieren.
Irgendwas muss ich mir noch bei meinen Tests zerschossen haben, meinen Pi erreiche ich jetzt nur noch über die IP-Adresse. Aber das ist jetzt wohl ne andere Baustelle.
(EDIT: Komisch Jetzt doch....)
Vielen Dank und Viele Grüße,
Mario
Zitat von: MarioR am 29 Dezember 2015, 17:08:39
Irgendwas muss ich mir noch bei meinen Tests zerschossen haben, meinen Pi erreiche ich jetzt nur noch über die IP-Adresse. Aber das ist jetzt wohl ne andere Baustelle.
(EDIT: Komisch Jetzt doch....)
Hast Du ne Fritzbox? Bei mir ist es so, dass die FB nach einem Neustart(der FB) die Raspberry's nicht per DNS auflöst. Erst wenn die Raspberry's neu gestartet wurden oder eben nach einiger Zeit. Obwohl in der Liste der Netzwerkgeräte alle Geräte als "grün" stehen.
Gruß Otto
Ja ist ne Fritzbox, wurde aber nicht neu gestartet. Jetzt funktioiert es aber, ohne das ich noch etwas geändert habe.
Etwas dubios der Pi, mit FHEM auf der Fritzbox hatte ich nie Probleme.
Ist quasi Off Topic:
Mir ist in der Vergangenheit aufgefallen, dass immer mal wenn ich was am Pi "gemacht" habe der anschließend eine Weile nicht per Name erreichbar war. Manchmal half name.fritz.box irgendwann ging es mal wieder.
Fakt ist aber, der DNS Server für intern ist die FB. Und Geräte wie "Android" machen DNS lookup.
Als ich jetzt meine FB durch ein Recovery (ich wollte die Alte Meldung von ehemals FHEM/Telnet auf der FB verschwinden lassen) neu gestartet habe und ein Pi eine neue Adresse bekommen hat (warum auch immer) war der Stundenlang vom Android per Name nicht erreichbar. Vom Windows ging alles. nslookup brachte das Problem zu Tage, der war quasi nur im DNS nicht registriert. Neustart vom Pi hat geholfen...
Gruß Otto
Wenn Ihr schon 24/7 einen Pi laufen lasst, könnt Ihr auch einen DNS-Server aufsetzen, dann habt Ihr genau die Probleme nicht ;o)
Und noch etwas: Server sollten eine Feste IP zugeordnet bekommen, dann kann sich diese nicht Ändern
Feste IP habe ich eingestellt, im Moment schmiert der Pi ständig ab. Keine Ahnung warum.
Meine Frau meint dazu: "hol Dir ne 2. Fritzbox, da hat ja alles funktioniert".
Über Nacht lief der Pi jetzt durch, kommt mir alles sehr unstabil vor.
Also instabile PIs gibt es bei mir nicht. Ist mir noch nie abgeschmiert.
@Werniemann Da hast Du voll Recht 8) und DHCP gleich mit!
Gesundes neues Jahr
Otto
Das mit dem Zeit-Server könnte hinkommen (dachte aber, ich hätte die Zeit immer direkt richtig gesetzt...)
Hier hat Thomas jedenfalls ein Word-Arround (http://www.computerhilfen.de/hilfen-64-426312-0.html#2214631), dass man vor FHEM ein "sleep 10" in die /etc/init.d/fhem setzen soll, das soll helfen (habe aber noch nicht probiert, noch läuft Weezy sehr stabil)...
Es gibt auch die Möglichkeit, FHEM erst NACH ntp zu starten .... gibt irgentwo im Forum dazu eine Doku
Mein Verständnis bisher war:
- ntp sorgt für die aktuelle Zeit während des Betriebes.
- fake-hwclock sorgt dafür, das nach dem Start nicht vor dem Shutdown ist.
Damit gibt es doch nur einen Stillstand während dem Neustart oder einer Betriebspause. Außer Tritt dürfte dabei nichts kommen.
Ansonsten müsste man im fhem.service Script im Abschnitt [Unit] nach After= festlegen (http://forum.fhem.de/index.php?topic=25706.0) das fhem erst nach ntp startet.
Ich habe bloss keine Ahnung wo fhem.service eigentlich liegt.
Gruß Otto
Wie bei allem mit systemd arbeitenden Ditris:
/etc/systemd/system/
Nur das da bei mir keine liegt :o
Aber ich habe die Erklärung gefunden (https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files) wo sie liegt wenn es gar keine gibt 8)
FHEM legt ja von selbst keine an. Sondern implementiert den /etc/init.d "Mechanismus"
Oder liege ich da falsch?
Jep .. was als "fall back" auch normalerweise genutzt wird
Wieder was gelernt! 8)
Zitat von: Otto123 am 04 Januar 2016, 00:26:41
Also instabile PIs gibt es bei mir nicht. Ist mir noch nie abgeschmiert.
@Werniemann Da hast Du voll Recht 8) und DHCP gleich mit!
Gesundes neues Jahr
Otto
Lag wohl am Wlan. Der PI war nicht mehr erreichbar, und ich dachte er wär abgeschmirt. Seit er am LAN hängt ist er stabil.
Hallo,
ich möchte kein neues Thema öffnen aber ich habe auf meinem Server auch zwischen 90 und 100% last des perl Prozesses. Apptime verrät mir aber nichts womit ich was anfangen könnte. Hat noch jemand eine Idee wie ich raus bekomme woran das liegt? Die Maschine sollte eigentlich so performant sein, dass das nicht passiert. Also ich nutze ein RPi oder sowas...
/Daniel
"attr global verbose 5" setzen, und log beobachten.
OK, habe ich auch schon geschaut, es kommt eine ganze Menge (Jeelink und SPSPM und so) aber ehrlich gesagt nicht in der Menge, dass ich sagen würde es sollte auch nur annähernd 1% CPU Last verursachen.
Ich werde es weiter beobachten, bzw. nach und nach mal die interface deaktivieren...
/Daniel
Also ich finde nichts, ich bin echt überfragt.
Werden bei Apptime nur Module gezeigt in denen bestimmte Bedingungen erfüllt sind oder alle, also auch die unsauber programmieren? Ich meine es sind keine 100% auf Anschlag, aber nahe dran, also irgend etwas scheint da tierisch zu ackern. Bei einem Intel(R) Core(TM) i3-4130 CPU @ 3.40GHz finde ich das ein wenig viel für FHEM.
Oder würdest du hier was auffälliges sehen:
name function max count total average maxDly
PanStick panStamp_Define 4567 1 4567 4567.00 0 HASH(PanStick); PanStick panStamp /dev/PanStamp@38400
KODI XBMC_Ready 3000 13889258 59988 0.00 0 HASH(KODI)
RFXTRX433 TRX_Define 2857 1 2857 2857.00 0 HASH(RFXTRX433); RFXTRX433 TRX /dev/RFXTRX433@38400
MP00202 OWX_ASYNC_Read 2422 12741 102441 8.04 0 HASH(MP00202)
Notify_Schluessel_Daniel notify_Exec 2245 2 2267 1133.50 0 HASH(Notify_Schluessel_Daniel); HASH(fl_iButton_blau)
az_OW_LCD1 OWLCD_Get 2213 1 2213 2213.00 0 HASH(az_OW_LCD1); az_OW_LCD1; gpio
wifiled01 WifiLight_Define 1008 1 1008 1008.00 0 HASH(wifiled01); wifiled01 WifiLight RGBW LD382A:192.168.0.91
JeeLink JeeLink_Define 1006 1 1006 1006.00 0 HASH(JeeLink); JeeLink JeeLink /dev/JeeLink@57600
JeeNode JeeLink_Define 1006 1 1006 1006.00 0 HASH(JeeNode); JeeNode JeeLink /dev/JeeNode@57600
Steckdose_Server SISPM_Define 901 1 901 901.00 0 HASH(Steckdose_Server); Steckdose_Server SISPM /usr/local/bin/sispmctl
tmr-at_Exec HASH(0x5a697a0) 810 4 3240 810.00 4 HASH(Timer_1Wire_ba_Temp_Steuereinheit)
ba_Temp_Steuereinheit ECMDDevice_Set 807 13 3228 248.31 0 HASH(ba_Temp_Steuereinheit); ba_Temp_Steuereinheit; messen
MP00202 OWX_ASYNC_Notify 717 17 717 42.18 0 HASH(MP00202); HASH(global)
PushNotify PushNotifier_Define 520 1 520 520.00 0 HASH(PushNotify); PushNotify PushNotifier EV468E7DBV468E7DV75BBV46BV466C3VEFTBFTFBFB net.homeip.itse ext23 gen6iNWG9bY .*
WEBtablet_192.168.0.15_41103 FW_Read 323 1 323 323.00 0 HASH(WEBtablet_192.168.0.15_41103)
Twilight Twilight_Define 295 1 295 295.00 0 HASH(Twilight); Twilight Twilight 52.539094 13.603869 3 638242
Callmonitor FB_CALLMONITOR_Notify 244 1722 244 0.14 0 HASH(Callmonitor); HASH(global)
DMXUniverse1 DMX4ALLUSB_Define 206 1 206 206.00 0 HASH(DMXUniverse1); DMXUniverse1 DMX4ALLUSB /dev/DMX@38400
WEB FW_Read 184 17 766 45.06 0 HASH(WEB)
tmr-OWX_ASYNC_RunTasks HASH(0x10f2fd70) 174 1581 42613 26.95 3225 HASH(MP00202)
CUL1 CUL_Define 143 1 143 143.00 0 HASH(CUL1); CUL1 CUL /dev/ttyACM0 1234
Das avg ist recht hoch mhhh, aber bei allen. Oder spinnt hier eventuell mein USB Bus.
/Daniel
ist es wirklich der haupt fhem prozess oder irgend ein child? beim mit spinnt manchmal der sonos prozess mit 100% cpu.
du kannst dich mit strace -p <pid> an den prozess hängen und schauen was er gerade macht.
gruss
andre
Hi,
naja ich denke es ist der Hauptprozess, also Perl. Der läuft aber auch nur jeweils auf einer der 4 Kerne die meine CPU hat.
strace liefert ein haufen Zeilen aller:
select(176, [5 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 29 30 54 55 71 72 73 95 146 153 155 171], NULL, NULL, {1, 353556}) = 1 (in [21], left {1, 353550})
select(176, [5 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 29 30 54 55 71 72 73 95 146 153 155 171], NULL, NULL, {1, 353451}) = 1 (in [21], left {1, 353444})
select(176, [5 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 29 30 54 55 71 72 73 95 146 153 155 171], NULL, NULL, {1, 353339}) = 1 (in [21], left {1, 353333})
select(176, [5 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 29 30 54 55 71 72 73 95 146 153 155 171], NULL, NULL, {1, 353231}) = 1 (in [21], left {1, 353225})
Das ist der Prozess:
fhem 9966 80.8 11.6 603656 456920 ? S 10:34 474:05 perl fhem.pl fhem.cfg
top:
PID BENUTZER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9966 fhem 20 0 604008 457308 5344 R 82,5 11,7 474:47.50 perl
Ich kann da kein Unterprozess erkennen auch nicht im Baum.
Gruß
Daniel
über /proc/<pid>/fd solltest du sehen wozu der filedescriptor 21 gehört der das select aufwachen lässt.
gruss
andre
irgendwo gibt es einen thread bei dem es auch um zu viel last beim lesen von einem usb device ging. kann aber sein das das nur in einer vm war. da gibt es auch einen patch vorschlag der zumindest dort geholfen hat.
Mhh das ist mein DMX Adapter, und das Modul habe ich selber geschrieben ;-) Heißt ich habe da irgendwo Misst gebaut in meinem Modul.
/Daniel
Ich hab jetzt mal ein paar Debug logs in meine Module eingebaut. Auffällig ist nur, dass die read Funktion Device Modul ständig aufgerufen wird. Die ist aber leer bei mir, ich nutze das nicht da der DMX Controller von sich aus keine Infos sendet sondern nur auf Anfragen antwortet. Kann das mein Problem sein?
Es heißt ja "called from the global loop, when the select for hash->{FD} reports data" Jetzt ist nur die Frage warum da Daten reported werden... Sonst dürfte er die Funktion ja gar nicht aufrufen wenn ich das richtig verstanden habe.
/Daniel
ZitatJetzt ist nur die Frage warum da Daten reported werden
Vmtl. weil FD in selectlist eingetragen ist.
Hast du die Datei mit DevIO geoeffnet? Dann passiert das automatisch.
Zitat von: rudolfkoenig am 11 Juni 2016, 17:18:05
Vmtl. weil FD in selectlist eingetragen ist.
Hast du die Datei mit DevIO geoeffnet? Dann passiert das automatisch.
Ich nutze DevIO ja. Heißt also das ist normal und vermutlich nicht Ursache für mein Verhalten.
ZitatHeißt also das ist normal und vermutlich nicht Ursache für mein Verhalten.
Aeh:
- Wenn man DevIO nutzt, ist normal, dass man nicht pollt, sondern ReadFn aufgerufen wird, wenn das zentrale select() feststellt, dass was zum Lesen gibt.
- Wenn das Geraet unaufgefordert Daten schickt, oder das Modul beim Pollen nicht alle Daten "weggelesen" hat, und ReadFn nichts tut, dann tritt genau das o.g. Verhalten auf: ReadFn wird in einer Endlosschleife aufgerufen.
Wenn du DevIO verwenden willst, und auf Pollen bestehst, dann solltest du
Zitatdelete($selectlist{"$name.$dev");
delete($readyfnlist{"$name.$dev");
nach DevIo_OpenDev aufrufen.
Zitat von: rudolfkoenig am 12 Juni 2016, 14:23:22
wenn das zentrale select() feststellt, dass was zum Lesen gibt.
Naja das macht es dann vermutlich, nur gibt es nichts zum Lesen weil, bzw. wenn dann die Antwort, aber die sollte ja eigentlich irgend wann mal "weggelesen" sein, ist nur 1 Byte was da als Antwort im UART Buffer liegt.
Zitat von: rudolfkoenig am 12 Juni 2016, 14:23:22
- Wenn das Geraet unaufgefordert Daten schickt, oder das Modul beim Pollen nicht alle Daten "weggelesen" hat, und ReadFn nichts tut, dann tritt genau das o.g. Verhalten auf: ReadFn wird in einer Endlosschleife aufgerufen.
Wenn du DevIO verwenden willst, und auf Pollen bestehst, dann solltest du nach DevIo_OpenDev aufrufen.
Naja Pollen möchte ich gerade nichts, also die Antwort vom DMX Controller interessiert mich garnicht um es mal krass zu sagen. Aber danke, ich schau mir das mal an was du schreibst. Ansonsten baue ich in die Lesefunktion noch was ein, das der Buffer leergelesen wird oder so. Aber jetzt habe ich zumindest verstanden was das Problem ist. Das ist mir nie aufgefallen das ich da misst drin habe. Schade das AppTime sowas nicht anzeigt. Ich versuche das zu ändern und werde berichten.
/Daniel
So ich hab ein
$buf = DevIo_TimeoutRead($hash, 0.1);
in die Read Funktion gepackt und schon sieht das ganze besser aus. Jetzt wird die Funktion nicht mehr aufgerufen, da war also noch irgend was im Buffer. Danke.
Endlich wird der Server wieder ruhiger und 10 Watt weniger verbraucht er auch ;-)
/Daniel
Zitatdie Antwort vom DMX Controller interessiert mich garnicht um es mal krass zu sagen
Aah. So geht es nicht, man muss hoeflich bleiben, und dem anderen auch zuhoeren.
Wenn du vom select aufgerufen wirst, reicht ein DevIo_SimpleRead, dass select sich meldet, ohne dass was zu lesen waere, habe ich noch nicht erlebt. Ok, Ausnahme: das Geraet wurde entfernt, aber DevIo_SimpleRead behandelt das auch.
Naja macht alles Sinn ja, hatte ich halt nicht aufm Schirm gehabt beim programmieren. Ich war froh, dass mein Modul macht es es soll :-) Ich war fest der Meinung das ich nach dem Senden an den Controller danach den Puffer leere wo die "unnütze" Antwort drin steht, war aber ein Trugschluss.
/Daniel
Hi MarioR,
dein Tip mit sleep(10) hat mir geholfen. Gerade fhem 5.9 auf raspi 4 und debian installiert.
100% cpu von user fhem mit perl.
Bei meiner installation habe ich in /etc/init.d allerdings kein fhem script gefunden. Dafür aber einen Definitionsfile in /etc/systemd/system. Da konnte man das sleep nicht einbauen.
Nun habe ich das Statement sleep(20); direkt in das Script /opt/fhem/fhem.pl ganz an den Anfang nach den Definitionen eingefügt. Nun läuft das prima nach Neustart.
Zitat von: wange2 am 05 Oktober 2019, 17:16:30
Nun habe ich das Statement sleep(20); direkt in das Script /opt/fhem/fhem.pl ganz an den Anfang nach den Definitionen eingefügt. Nun läuft das prima nach Neustart.
Das tut man nicht :(
Besser so: https://forum.fhem.de/index.php?topic=104132.0
Und etwas Linux Prosa lesen hilft auch :)
Gruß Otto