ich schreibe seit einiger Zeit den verfügbaren Speicher der OpenWB mit. Seit ein paar Monaten fällt auf, daß der Prozess lt-armv7l_ELF (der Support-Client) nach einigen Tagen zunehmend Speicher belegt. Im Bild zu sehen ist der verfügbare Speicher. Die Zacken, die alle 48h auftauchen ist der Neustart des Display-Chromiums, der ein Speicher-Leck hat. Etwa 12 Tage nach Neustart nimmt der Speicherbedarf massiv zu. Top, sortiert nach Speicher sieht so aus:
Code: Alles auswählen
Linux openwb-2 6.1.21-v7+ #1642 SMP Mon Apr 3 17:20:52 BST 2023 armv7l
top - 23:15:25 up 15 days, 8:38, 2 users, load average: 1,04, 1,73, 1,64
Tasks: 170 total, 2 running, 167 sleeping, 0 stopped, 1 zombie
%CPU(s): 24,8 us, 3,8 sy, 0,0 ni, 71,2 id, 0,0 wa, 0,0 hi, 0,2 si, 0,0 st
MiB Spch: 922,3 total, 39,3 free, 595,3 used, 287,7 buff/cache
MiB Swap: 100,0 total, 0,0 free, 100,0 used. 230,2 avail Spch
PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL
5589 openwb 20 0 781780 303596 2044 S 0,0 32,1 71:31.85 lt-armv7l_ELF
1354 openwb 20 0 457720 99544 28604 S 5,6 10,5 1490:33 chromium
1916 openwb 20 0 257552 76844 7852 S 10,3 8,1 4040:43 python3
813 openwb 20 0 694600 71156 26800 S 0,3 7,5 76:16.60 chromium
1251 openwb 20 0 528892 25824 17684 S 21,2 2,7 5740:30 chromium
1261 openwb 20 0 299580 19464 16260 S 0,3 2,1 84:07.17 chromium
22057 pi 20 0 21112 12620 7272 S 0,0 1,3 1:02.82 python3
543 root 20 0 211432 11072 6744 S 0,0 1,2 6:51.13 apache2
132 root 20 0 70364 10844 10400 S 0,0 1,1 0:30.24 systemd-journal
1210 openwb 20 0 224384 9976 7936 S 0,0 1,1 0:00.20 chromium
525 openwb 20 0 36944 9764 7212 S 0,0 1,0 5:55.13 python3
1323 openwb 20 0 277184 8960 6400 S 0,0 0,9 0:06.62 chromium
1209 openwb 20 0 224388 8856 8004 S 0,0 0,9 0:00.20 chromium
515 root 20 0 262944 8832 5604 S 0,3 0,9 130:09.01 Xorg
2222 www-data 20 0 211884 7976 3376 S 0,0 0,8 0:00.03 apache2
2841 www-data 20 0 211884 7976 3376 S 0,0 0,8 0:00.02 apache2
5269 www-data 20 0 211884 7968 3376 S 0,0 0,8 0:00.01 apache2
6379 www-data 20 0 211884 7968 3376 S 0,0 0,8 0:00.01 apache2
6923 www-data 20 0 211884 7968 3376 S 0,0 0,8 0:00.01 apache2
6380 www-data 20 0 211884 7960 3376 S 0,0 0,8 0:00.00 apache2
6929 www-data 20 0 211884 7960 3376 S 0,0 0,8 0:00.00 apache2
7590 www-data 20 0 211884 7960 3376 S 0,0 0,8 0:00.00 apache2
7591 www-data 20 0 211884 7960 3376 S 0,0 0,8 0:00.00 apache2
819 openwb 20 0 45208 7272 7272 S 0,0 0,8 0:01.11 applet.py
7501 www-data 20 0 211576 7216 2808 S 0,0 0,8 0:00.00 apache2
3553 root 20 0 14628 7196 6240 S 0,0 0,8 0:00.27 sshd
489 zabbix 20 0 902328 7016 4308 S 0,0 0,7 14:52.15 zabbix_agent2
Hat das OpenWB-Team möglicherweise eine Idee, wie das behoben werden könnte?
Darüber hinaus möchte ich anregen, daß ein Zweig im MQTT-Client, in dem wichtige Systemgrößen von der Wallbox abgelegt werden, helfen könnte.
Zum Abschluß noch mein Skript, mit dem ich die Daten aus der Wallbox ausleite:
Code: Alles auswählen
pi@openwb-2:~$ cat wbwatch.py
#!/usr/bin/env python3
"""
frage periodisch den freien Speicherplatz und die CPU-Last der Wallbox ab und schreibe die Ergebnisse an den lokalen moquitto-broker
"""
import sys
import time
import os
import paho.mqtt.publish as publish
while True:
stat = os.popen('cat /proc/loadavg').read()
list = stat.split()
publish.single('others/wbwatch/load5', list[1])
time.sleep(1)
stat = os.popen('free').read()
list = stat.split()
publish.single('others/wbwatch/memavail', list[12])
time.sleep(299)