The Industrial Raspberry Pi Forum


https://revolutionpi.com/forum/

Arbeitsspeicher läuft voll, Prozess python3 steigt auf über 70%

https://revolutionpi.com/forum/viewtopic.php?t=2966

Page 1 of 1

Arbeitsspeicher läuft voll, Prozess python3 steigt auf über 70%

Posted: 12 Jul 2021, 12:58
by Lars P.
Hallo zusammen,

wir wollen verschiedene Kombinationen aus RevPi und DI, DIO-Modulen nutzen, um etwa 150 unbemannte Standorte zu überwachen. Aktuell sind wir im PoC und haben, dass Problem, das python3 im laufe von ca. 30 Stunden zunehmend bis zu 70% des Arbeitsspeichers benötigt und schließlich den RevPi zum Absturz bringt. Das aktuelle Seznario sieht wie folgt aus:

Am Standort:

1 Stk. RevPi Connect+ mit 32 GB
1 Stk. DIO Modul
3 Stk. DI Module

Aktuell nutzen wir maximal 25 DIs pro Standort. Der Rest ist noch nicht in Betrieb.

Auf dem RevPi läuft ein aktuelles RevPi-Image. Wir haben alle Pakete wie in der Anleitung beschrieben per apt-get auf den neuesten Stand gebracht und anschließend einen Zabbix-Proxy mit sqlite3 DB und einen Zabbix-Agent installiert.
Im Pictory haben wir die Module konfiguriert. Außerdem nutzen wir Node-Red um alle 55 Sekunden die verscheidenen DIs per RevPi-getpin-Node und RevPi-multiple-input-Node abzufragen und via zabbix-sender-Node über den lokalen Proxy an unseren Zabbix-Server weiterzu geben. Außerdem wird im Node-Red via RevPi-getpin-Node und revpi-output-Node der Watchdog getogglet.

Das funktioniert alles bis zum Arbeitsspeicher überlauf problemlos.

Einziger laufender python3 Prozess ist scheinbar revpi-server.py. Dazu hier die Ausgabe von top und ps nach einem Reboot. Der MEM-Wert für python3 steigt jetzt über 30 Stunden bis auf 70% an. Das Problem besteht auf allen drei Testgeräten, die sich nur in Hostname, IP und genutzten DIs unterschieden.

Code: Select all

top - 12:28:35 up 50 min,  1 user,  load average: 4.08, 3.32, 2.99
Tasks: 182 total,   1 running, 181 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.9 us,  9.2 sy,  0.0 ni, 89.5 id,  0.0 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :    925.4 total,    519.0 free,    155.2 used,    251.2 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.    704.3 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                      
  160 root     -51   0       0      0      0 I  25.0   0.0  12:31.27 pl011_pio_tx                                 
  161 root     -40   0       0      0      0 S   3.6   0.0   1:38.47 piControl Uart                               
 1859 root      20   0   85272  31004   8472 S   2.6   3.3   1:13.04 python3                                      
  143 root      20   0       0      0      0 I   1.6   0.0   0:19.03 kworker/u8:2-events_unbound                  
  158 root     -51   0       0      0      0 S   1.3   0.0   0:42.56 irq/81-uart-pl0                              
  162 root     -39   0       0      0      0 D   1.3   0.0   0:40.10 piControl I/O                                
   82 root     -51   0       0      0      0 S   1.0   0.0   0:28.36 irq/56-dwc_otg_                              
  159 root     -51   0       0      0      0 I   1.0   0.0   0:34.34 pl011_pio_rx                                 
 2693 pi        20   0   10468   3068   2568 R   1.0   0.3   0:01.30 top                                          
   80 root     -51   0       0      0      0 S   0.7   0.0   0:25.22 irq/56-dwc_otg                               
   81 root     -51   0       0      0      0 S   0.7   0.0   0:16.19 irq/56-dwc_otg_                              
    9 root      20   0       0      0      0 S   0.3   0.0   0:03.45 ksoftirqd/0                                  
   10 root      -2   0       0      0      0 S   0.3   0.0   0:06.59 ktimersoftd/0                                
   24 root      20   0       0      0      0 S   0.3   0.0   0:02.36 ksoftirqd/1                                  
   40 root      20   0       0      0      0 S   0.3   0.0   0:01.46 ksoftirqd/3                                  
pi@RevPi:~ $ ps -ef | grep python
root      1859     1  2 11:38 ?        00:01:13 /usr/bin/python3 -u revpi-server.py
pi        2702  2681  0 12:29 pts/0    00:00:00 grep --color=auto python
pi@RevPi:~ $

Ich wäre dankbar für jeden Tipp wo ich mich auf Fehlersuche begeben kann.

Danke,
Lars

Re: Arbeitsspeicher läuft voll, Prozess python3 steigt auf über 70%

Posted: 28 Jul 2021, 21:53
by Steven
Wenn ich das richtig sehe ist der server revpi-server.py dafür zuständig die Daten für die NodeRED Nodes zur Verfügung zu stellen.
Sieht so aus als gäbe es einen Bug in dem Server.

Als Workaround könnte man https://revpimodio.org/revpipyplc/revpipyload/ benutzen um die Inputs z.B. über einen lokalen MQTT in das NodeRED zu schicken.
Die Software ist soweit ich weiß immer beim revpi mit drauf und kann in der Management Oberfläche aktiviert werden.
Mit MQTT Retain und QoS 2 wäre jedenfalls alles safe und die Daten kommen auch hier über push in das System.

Re: Arbeitsspeicher läuft voll, Prozess python3 steigt auf über 70%

Posted: 08 Sep 2021, 18:19
by Steven
Ein Kunde von uns klagt über ständige System freezes.
Da habe ich mich an diesen Thread erinnert und ebenfalls festgestellt das der Prozess über 47% Memory braucht und weiter wächst.
Das macht der Prozess dann so lange bis das System sich aufhängt und nichtmal mehr über SSH zu erreichen geht.

Gibt es dafür ein Update?

https://github.com/erminas/noderedrevpi ... r/issues/5

Re: Arbeitsspeicher läuft voll, Prozess python3 steigt auf über 70%

Posted: 29 Jan 2022, 16:16
by Rapanui
Bin froh, daß ich auf diesen Thread gestossen bin!
Auf unserem Laborsystem mit RevPi Core 3+ habe ich mich mit einem Kollegen durch das dist-upgrade von stretch auf buster gekämpft. Als endlich auch der Port 8000 des noderedrevpinodes-server 1.0.2-2 wieder in Betrieb war, konnte ich den RevPi am nächsten Tag nicht mehr per SSH erreichen, nur ping antwortete noch.

Nach einem Reboot lief er dann wieder, aber ich konnte auch beobachten, wie über Stunden der verfügbare Arbeitspeicher abnahm. Nur mal ein Beispiel, wie es nach etwa 12 h aussah:

Code: Select all

top - 00:00:52 up 12:08,  1 user,  load average: 2,58, 2,32, 2,22
Tasks: 161 total,   1 running, 160 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,6 us,  1,9 sy,  0,0 ni, 97,5 id,  0,0 wa,  0,0 hi,  0,1 si,  0,0 st
MiB Mem :    925,4 total,     29,1 free,    731,1 used,    165,3 buff/cache
MiB Swap:    100,0 total,     86,0 free,     14,0 used.    124,9 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                          
  162 root     -40   0       0      0      0 S   2,6   0,0  21:00.98 piControl Uart                                   
 1228 root      20   0  587096 528728   7120 S   2,6  55,8  21:55.22 python3                                          
  159 root     -51   0       0      0      0 S   1,3   0,0   8:50.45 irq/81-uart-pl0                                  
  163 root     -39   0       0      0      0 D   1,3   0,0  10:27.73 piControl I/O
Einen ersten Fix fand ich in https://github.com/nbuchwitz/noderedrev ... -server.py und gemäß der dortigen Anleitung habe ich das ursächliche Python-Script revpi-server.py erneuert.

Ich kann bestätigen, daß der Memory Leak bei uns damit gestoppt ist, vielen Dank!
Beispiel aktuell:

Code: Select all

top - 10:29:15 up 22:37,  1 user,  load average: 2,21, 2,16, 2,15
Tasks: 157 total,   1 running, 156 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,1 us,  2,3 sy,  0,0 ni, 97,5 id,  0,0 wa,  0,0 hi,  0,2 si,  0,0 st
MiB Mem :    925,4 total,    246,7 free,    228,9 used,    449,8 buff/cache
MiB Swap:    100,0 total,     88,5 free,     11,5 used.    622,7 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  162 root     -40   0       0      0      0 S   2,6   0,0  38:51.29 piControl Uart
  159 root     -51   0       0      0      0 S   1,3   0,0  16:20.38 irq/81-uart-pl0
  163 root     -39   0       0      0      0 D   1,3   0,0  19:16.98 piControl I/O
  160 root     -51   0       0      0      0 I   1,0   0,0  13:08.78 pl011_pio_rx
 9683 root      20   0       0      0      0 I   1,0   0,0   0:05.89 kworker/u8:2-events_unbound
   10 root      -2   0       0      0      0 S   0,7   0,0   4:14.46 ktimersoftd/0
   78 root     -51   0       0      0      0 S   0,7   0,0   5:27.57 irq/56-dwc_otg
 7396 root      20   0   77844  22608   8620 S   0,7   2,4   4:10.80 python3
Ob mit dem Bugfix bei uns Nebenwirkungen verbunden sind, kann ich derzeit noch nicht sagen. Frage mich nur, warum dieser Fix noch nicht im normalen Buster-Paket noderedrevpinodes-server angekommen ist, wenn er doch funktioniert.

@Kunbus Finde es übrigens klasse, daß nodered in Buster im Gegensatz zu Stretch endlich sauber und aktuell eingebunden werden kann. Wird unseren Aktivitäten rund um den RevPi wieder neuen Schub geben!

Freundliche Grüsse
All times are UTC+01:00
Page 1 of 1

Powered by phpBB® Forum Software © phpBB Limited