Hallo
Ich habe seit mitte März das Problem das meine FHEM Installation einen erhöhten evtl. sogar unendlichen RAM Bedarf hat.
Zunächst hatte ich HMCCU in verdacht da ich ca. zu diesem Zeitpunkt mit der Umstellung von CUL_HM auf HMCCU angefangen habe.
Siehe hier: https://forum.fhem.de/index.php?topic=133875.0
Dies scheint sich jedoch nicht zu bestätigen. Daher stellt sich mir nun die Frage wie ich analysieren kann was den RAM belegt.
Ich betreibe FHEM in einer VM. Dieser habe ich aktuell 2 CPUs und 4,5 GB RAM zugewiesen.
Bis mitte März benötigte die VM lediglich 1 GB RAM wovon ca. 500MB benutzt wurden.
Ein frisch gestarteter Fhem belegt ca. 600MB.
Innerhalb von ca. 10 Tagen, in den der RAM-Bedarf linear um ca. 400MB pro Tag an wächst, wird der gesamte verfügbare RAM belegt. Das System beginnt zunächst zu swappen bis schließlich auch der swap voll ist und der Perl Prozess beendet und neu gestartet wird.
Seit März habe ich lediglich an drei Themen gearbeitet.
- von CUL_HM auf HMCCU umgestellt
- shelly durch mqtt2 ersetzt
- einige notify durch DOIF ersetzt
Ich hoffe ihr könnt mich bei der Ursachenforschung unterstützen!
Gruß und Danke im voraus.
Hast du mal mit top oder htop geschaut, was am meisten RAM belegt?
Evtl werden auch Prozesse mehrfach gestartet und kommen nicht zum Ende. Also mit ps -auxf mal schauen was da los ist.
Moin.
Den größten Teil belegt perl/fhem. Insgesamgt fünf Prozesse.
Einmal der Hauptprozess und vier Subprozesse (das sind die drei RPC Server für HMCCU und ich denke der vierte ist der MQTT Server).
Weitere Auffälligkeiten sehe ich nicht.
Schön zu sehen auch in der angehängten HTOP Übersicht.
root@fhem:~# ps -auxf
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 2 0.0 0.0 0 0 ? S Jul21 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [rcu_gp]
root 4 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [rcu_par_gp]
root 5 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [slub_flushwq]
root 6 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [netns]
root 10 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [mm_percpu_wq]
root 11 0.0 0.0 0 0 ? I Jul21 0:00 \_ [rcu_tasks_kthread]
root 12 0.0 0.0 0 0 ? I Jul21 0:00 \_ [rcu_tasks_rude_kthread]
root 13 0.0 0.0 0 0 ? I Jul21 0:00 \_ [rcu_tasks_trace_kthread]
root 14 0.0 0.0 0 0 ? S Jul21 0:02 \_ [ksoftirqd/0]
root 15 0.0 0.0 0 0 ? I Jul21 1:08 \_ [rcu_preempt]
root 16 0.0 0.0 0 0 ? S Jul21 0:02 \_ [migration/0]
root 18 0.0 0.0 0 0 ? S Jul21 0:00 \_ [cpuhp/0]
root 19 0.0 0.0 0 0 ? S Jul21 0:00 \_ [cpuhp/1]
root 20 0.0 0.0 0 0 ? S Jul21 0:02 \_ [migration/1]
root 21 0.0 0.0 0 0 ? S Jul21 0:01 \_ [ksoftirqd/1]
root 23 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [kworker/1:0H-events_highpri]
root 26 0.0 0.0 0 0 ? S Jul21 0:00 \_ [kdevtmpfs]
root 27 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [inet_frag_wq]
root 28 0.0 0.0 0 0 ? S Jul21 0:00 \_ [kauditd]
root 29 0.0 0.0 0 0 ? S Jul21 0:00 \_ [khungtaskd]
root 30 0.0 0.0 0 0 ? S Jul21 0:00 \_ [oom_reaper]
root 32 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [writeback]
root 33 0.0 0.0 0 0 ? S Jul21 0:12 \_ [kcompactd0]
root 34 0.0 0.0 0 0 ? SN Jul21 0:00 \_ [ksmd]
root 35 0.0 0.0 0 0 ? SN Jul21 1:09 \_ [khugepaged]
root 36 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [kintegrityd]
root 37 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [kblockd]
root 38 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [blkcg_punt_bio]
root 39 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [tpm_dev_wq]
root 40 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [edac-poller]
root 41 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [devfreq_wq]
root 43 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [kworker/0:1H-kblockd]
root 44 0.0 0.0 0 0 ? S Jul21 0:00 \_ [kswapd0]
root 50 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [kthrotld]
root 52 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [acpi_thermal_pm]
root 53 0.0 0.0 0 0 ? S Jul21 0:00 \_ [xenbus_probe]
root 54 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [mld]
root 55 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [kworker/1:1H-kblockd]
root 56 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [ipv6_addrconf]
root 61 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [kstrp]
root 66 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [zswap-shrink]
root 67 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [kworker/u5:0]
root 139 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [ata_sff]
root 140 0.0 0.0 0 0 ? S Jul21 0:00 \_ [scsi_eh_0]
root 141 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [scsi_tmf_0]
root 142 0.0 0.0 0 0 ? S Jul21 0:00 \_ [scsi_eh_1]
root 143 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [scsi_tmf_1]
root 145 0.0 0.0 0 0 ? S Jul21 0:00 \_ [scsi_eh_2]
root 146 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [scsi_tmf_2]
root 147 0.0 0.0 0 0 ? S Jul21 0:00 \_ [scsi_eh_3]
root 148 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [scsi_tmf_3]
root 149 0.0 0.0 0 0 ? S Jul21 0:00 \_ [scsi_eh_4]
root 150 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [scsi_tmf_4]
root 151 0.0 0.0 0 0 ? S Jul21 0:00 \_ [scsi_eh_5]
root 152 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [scsi_tmf_5]
root 153 0.0 0.0 0 0 ? S Jul21 0:00 \_ [scsi_eh_6]
root 154 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [scsi_tmf_6]
root 155 0.0 0.0 0 0 ? S Jul21 0:00 \_ [scsi_eh_7]
root 156 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [scsi_tmf_7]
root 165 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [kworker/0:2H-kblockd]
root 196 0.0 0.0 0 0 ? S Jul21 0:00 \_ [jbd2/vda1-8]
root 197 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [ext4-rsv-conver]
root 344 0.0 0.0 0 0 ? I< Jul21 0:00 \_ [cryptd]
root 157699 0.0 0.0 0 0 ? R 06:17 0:02 \_ [kworker/1:1+events]
root 157700 0.0 0.0 0 0 ? I 06:17 0:00 \_ [kworker/0:0]
root 158012 0.0 0.0 0 0 ? I 06:25 0:00 \_ [kworker/u4:1-flush-254:0]
root 158017 0.0 0.0 0 0 ? I 06:25 0:00 \_ [kworker/1:0]
root 162116 0.1 0.0 0 0 ? I 08:15 0:02 \_ [kworker/0:1-events]
root 162191 0.0 0.0 0 0 ? I 08:17 0:00 \_ [kworker/u4:2-events_unbound]
root 163012 0.0 0.0 0 0 ? I 08:38 0:00 \_ [kworker/u4:0-events_unbound]
root 163015 0.0 0.0 0 0 ? I 08:38 0:00 \_ [kworker/1:2-cgroup_destroy]
root 1 0.0 0.2 167620 12048 ? Ss Jul21 0:02 /sbin/init
root 234 0.0 0.2 32904 11408 ? Ss Jul21 0:01 /lib/systemd/systemd-journald
root 261 0.0 0.1 25332 5764 ? Ss Jul21 0:00 /lib/systemd/systemd-udevd
avahi 470 0.0 0.1 8624 4736 ? Ss Jul21 3:55 avahi-daemon: running [fhem.local]
avahi 488 0.0 0.0 8096 364 ? S Jul21 0:00 \_ avahi-daemon: chroot helper
root 471 0.0 0.0 6608 2628 ? Ss Jul21 0:00 /usr/sbin/cron -f
message+ 472 0.0 0.1 9124 4952 ? Ss Jul21 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidf
root 477 0.0 0.1 221772 6132 ? Ssl Jul21 0:00 /usr/sbin/rsyslogd -n -iNONE
Debian-+ 478 0.0 0.2 24172 13312 ? Ss Jul21 2:59 /usr/sbin/snmpd -LOw -u Debian-snmp -g Debian-snmp -I -smux mteTri
root 480 0.0 0.1 16952 8020 ? Ss Jul21 0:00 /lib/systemd/systemd-logind
ntpsec 487 0.0 0.2 11016 11000 ? SLs Jul21 0:25 /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u n
root 490 0.0 0.0 5872 1032 tty1 Ss+ Jul21 0:00 /sbin/agetty -o -p -- \u --noclear - linux
root 493 0.0 0.1 15400 8740 ? Ss Jul21 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root 163009 0.0 0.2 17956 11196 ? Ss 08:38 0:00 \_ sshd: root@pts/0
root 163036 0.0 0.1 8232 4968 pts/0 Ss 08:38 0:00 \_ -bash
root 163137 100 0.1 12388 5500 pts/0 R+ 08:40 0:00 \_ ps -auxf
fhem 506 6.3 15.0 686456 678504 ? S Jul21 273:17 /usr/bin/perl fhem.pl fhem.cfg
fhem 528 0.0 1.6 85340 73740 ? S Jul21 3:28 \_ /usr/bin/perl fhem.pl fhem.cfg
fhem 667 0.0 7.7 366220 349732 ? S Jul21 1:54 \_ /usr/bin/perl fhem.pl fhem.cfg
fhem 668 0.1 7.8 370144 353556 ? S Jul21 6:21 \_ /usr/bin/perl fhem.pl fhem.cfg
fhem 669 0.0 7.5 359768 343232 ? S Jul21 2:52 \_ /usr/bin/perl fhem.pl fhem.cfg
fhem 512 0.3 3.1 11834500 140576 ? Ssl Jul21 13:44 hb-service
fhem 568 0.1 3.3 1364068 149540 ? Sl Jul21 4:20 \_ homebridge
root 163013 0.0 0.2 18904 10672 ? Ss 08:38 0:00 /lib/systemd/systemd --user
root 163016 0.0 0.0 168676 3036 ? S 08:38 0:00 \_ (sd-pam)
Aber warum wurde fhem 5x gestartet?
Bei mir nur ein mal.
Hast du einen cronjob oder irgend etwas, was fhem immer wieder zusätzlich startet? Prüf das mal. Das schaukelt sich hoch...
Das hat er doch beantwortet:
ZitatEinmal der Hauptprozess und vier Subprozesse (das sind die drei RPC Server für HMCCU und ich denke der vierte ist der MQTT Server).
Das er bei Dir nur 1x bedeutet nur, das DU keine "non blocking" Module verwendest ...
#5 ist allerdings nicht MQTT2_SERVER, das Modul forkt afaik nicht. Andere Kandidaten: PRESENCE (!), DbLog, mpd, ....?!?
Ist aber im Detail nicht soooo wichtig (ausgenommen (nicht modifiziertes) PRESENCE, wenn man zu viele Pinger hat!)
Zitat von: Beta-User am 26 Juli 2023, 12:08:16#5 ist allerdings nicht MQTT2_SERVER, das Modul forkt afaik nicht. Andere Kandidaten: PRESENCE (!), DbLog, mpd, ....?!?
Ist aber im Detail nicht soooo wichtig (ausgenommen (nicht modifiziertes) PRESENCE, wenn man zu viele Pinger hat!)
Ja, Dblog benutze ich auch. Dann wird der vierte Fork das sein. Danke für den Hinweis. PRESENCE nutze ich ebenfalls aber diese Forks sind nur kurz da und wieder weg.
So ich bin wieder einen Schritt weiter aber verstehe das Verhalten dennoch nicht.
Was habe ich gamacht:
Ich habe Fhem beendet den Code etwas sortiert (nicht verändert sondern ledig die Reihenfolge verändert) und sämtliche nicht benötigten Bestandteile auskommentiert.
Beim ersten Start waren lediglich Fhem Basiskomponenten sowie DBLog und HMCCU aktiv.
-Der Fehler trat nicht auf.
Anschließend habe ich schrittweise alle Komponenten wieder aktiviert und immer wieder kontrolliert ob der Fehler auftritt.
Aktuell habe ich alle Komponenten wieder aktiv und der RAM Bedarf ist seit 16 Stunden konstant.
Ich verstehe nur nicht warum. Das einzige was mir aufgefallen ist, ist dass durch das entfernen und wieder einbinden der Komponenten deren Status nachvollziehbarerweise verloren ging.
Ich bin mir nicht sicher ob fehlerhafte Statusinformationen / Readings ein solches Verhalten verursachen können.
Gibt es eigentlich eine andere Möglichkeit den Status aller Komponenten zurück zu setzen ohne diese zu entfernen und wieder anzulegen?
Da fällt mir ein .. war nicht MQTT mit einer bestimmten Einstellung bekannt dafür, große Statusfiles zu schreiben?
Könntest Du uns ein List Deines MQTT geben?
Das war, mein ich, wenn beim <MQTT2_SERVER> das attr respectRetain auf 1 steht.
Dieses auf 0 setzten und dann noch ein "set <MQTT2_SERVER> clearRetain"
Gruß schwatter
hier das gewünschte list
Internals:
CFGFN /var/fhem/FHEM/mqtt.cfg
CONNECTS 13
Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF 1883 global
FD 11
FUUID 60c70a08-f33f-a5a6-14e8-40a9311d75552b74
NAME MQTT2_FHEM_Server
NR 277
PORT 1883
STATE Initialized
TYPE MQTT2_SERVER
eventCount 13
MatchList:
1:MQTT2_DEVICE ^.
2:MQTT_GENERIC_BRIDGE ^.
READINGS:
2023-08-14 21:33:58 nrclients 13
2023-08-14 21:33:53 state Initialized
clients:
MQTT2_FHEM_Server_192.168.6.138_26529 1
MQTT2_FHEM_Server_192.168.6.139_12900 1
MQTT2_FHEM_Server_192.168.6.140_17118 1
MQTT2_FHEM_Server_192.168.6.141_3167 1
MQTT2_FHEM_Server_192.168.6.142_2969 1
MQTT2_FHEM_Server_192.168.6.143_25246 1
MQTT2_FHEM_Server_192.168.6.145_29945 1
MQTT2_FHEM_Server_192.168.6.146_2824 1
MQTT2_FHEM_Server_192.168.6.147_12467 1
MQTT2_FHEM_Server_192.168.6.148_6819 1
MQTT2_FHEM_Server_192.168.6.149_32302 1
MQTT2_FHEM_Server_192.168.6.153_22818 1
MQTT2_FHEM_Server_192.168.6.154_10045 1
retain:
Attributes:
DbLogExclude .*
autocreate simple
icon mqtt_broker
room Zentralsysteme->Gateways
verbose 2
Aber wie gesagt aktuell ist das Problem weg und ich weis nicht wirklich warum da ich die Konfiguration nicht verändert habe.
Sondern lediglich alles auskommentiert und später wieder reingenommen habe.
ist nur ein Bsp.
aus dem anderen Beitrag von dir
Zitatfhem.pl 27498 2023-04-30 08:50:41Z rudolfkoenig
aktuell wäre
fhem.pl 27750 2023-07-11 18:30:38Z rudolfkoenighat das Gründe bei dir?
@LuckyDay
Leider weis ich spontan nicht aus welchem Betrag Du das hast aber zwischenzeitlich habe ich FHEM aktualisiert.
Ausgabe Version:
Latest Revision: 27833
File Rev Last Change
fhem.pl 27750 2023-07-11 18:30:38Z rudolfkoenig
60_allergy.pm 26833 2022-12-10 23:32:26Z moises
96_allowed.pm 26004 2022-04-29 19:06:05Z rudolfkoenig
90_at.pm 25248 2021-11-21 10:29:01Z rudolfkoenig
98_autocreate.pm 23727 2021-02-12 20:31:37Z rudolfkoenig
No Id found for 99_Batterycheck.pm
57_Calendar.pm 26344 2022-08-22 15:06:57Z neubert
93_DbLog.pm 27617 2023-05-25 19:56:44Z DS_Starter
93_DbRep.pm 27746 2023-07-10 22:18:10Z DS_Starter
98_DOIF.pm 27740 2023-07-10 09:31:11Z Damian
98_dummy.pm 25606 2022-02-01 10:43:57Z rudolfkoenig
70_ENIGMA2.pm 18995 2019-03-22 20:09:53Z loredo
91_eventTypes.pm 23471 2021-01-04 19:24:21Z rudolfkoenig
01_FHEMWEB.pm 27823 2023-08-07 15:28:24Z rudolfkoenig
92_FileLog.pm 27751 2023-07-11 18:43:36Z rudolfkoenig
89_FULLY.pm 25516 2022-01-20 16:00:19Z zap
98_help.pm 27491 2023-04-27 17:22:30Z betateilchen
88_HMCCU.pm 27641 2023-06-01 17:52:19Z zap
88_HMCCUCHN.pm 26565 2022-10-20 12:24:12Z zap
88_HMCCUDEV.pm 26565 2022-10-20 12:24:12Z zap
88_HMCCURPCPROC.pm 26565 2022-10-20 12:24:12Z zap
98_HTTPMOD.pm 27714 2023-06-29 15:30:07Z StefanStrobel
02_HTTPSRV.pm 20110 2019-09-05 17:30:20Z neubert
30_HUEBridge.pm 26438 2022-09-22 06:40:39Z justme1968
31_HUEDevice.pm 26730 2022-11-21 17:28:03Z justme1968
98_IF.pm 12944 2017-01-03 12:56:17Z Damian
36_JeeLink.pm 14707 2017-07-13 18:08:33Z justme1968
98_JsonList2.pm 26701 2022-11-14 09:51:02Z rudolfkoenig
36_LaCrosse.pm 25537 2022-01-21 17:54:29Z HCS
82_LGTV_WebOS.pm 27575 2023-05-16 02:31:41Z CoolTux
10_MQTT2_DEVICE.pm 27674 2023-06-12 08:33:06Z rudolfkoenig
00_MQTT2_SERVER.pm 27654 2023-06-04 15:20:06Z rudolfkoenig
75_msgConfig.pm 26965 2023-01-05 06:32:17Z CoolTux
91_notify.pm 25888 2022-03-27 10:22:58Z rudolfkoenig
73_PRESENCE.pm 20782 2019-12-19 10:51:06Z markusbloch
59_PROPLANTA.pm 23449 2021-01-01 09:56:49Z tupol
70_Pushover.pm 27466 2023-04-20 07:51:19Z rudolfkoenig
33_readingsGroup.pm 23844 2021-02-27 19:43:24Z justme1968
91_sequence.pm 27765 2023-07-14 15:28:29Z rudolfkoenig
98_serviced.pm 27227 2023-02-14 20:00:33Z DeeSPe
39_siri.pm 24071 2021-03-24 08:02:11Z justme1968
98_structure.pm 27209 2023-02-12 14:45:51Z rudolfkoenig
99_SUNRISE_EL.pm 24249 2021-04-14 05:45:49Z rudolfkoenig
98_SVG.pm 27261 2023-02-21 09:34:09Z rudolfkoenig
42_SYSMON.pm 26358 2022-08-29 21:11:26Z hexenmeister
32_SYSSTAT.pm 24779 2021-07-20 09:21:08Z justme1968
98_telnet.pm 25754 2022-02-27 16:49:52Z rudolfkoenig
74_Unifi.pm 23500 2021-01-09 15:14:50Z wuehler
74_UnifiClient.pm 19989 2019-08-12 18:25:21Z wuehler
99_Utils.pm 24128 2021-04-02 16:29:11Z rudolfkoenig
77_UWZ.pm 25306 2021-12-06 05:27:48Z CoolTux
98_version.pm 26611 2022-10-28 16:32:29Z betateilchen
91_watchdog.pm 26108 2022-06-01 08:25:03Z rudolfkoenig
98_WOL.pm 24102 2021-03-27 20:49:59Z KernSani
71_YAMAHA_AVR.pm 26846 2022-12-12 20:58:51Z Beta-User
AttrTemplate.pm 27145 2023-01-29 11:48:19Z rudolfkoenig
Blocking.pm 23268 2020-12-01 11:48:48Z rudolfkoenig
Color.pm 20813 2019-12-22 18:42:10Z justme1968
DevIo.pm 27247 2023-02-18 21:22:32Z rudolfkoenig
GPUtils.pm 19666 2019-06-20 11:17:29Z CoolTux
HMCCUConf.pm 26565 2022-10-20 12:24:12Z zap
HttpUtils.pm 27406 2023-04-07 16:52:19Z rudolfkoenig
Meta.pm 26889 2022-12-23 15:04:11Z CoolTux
msgSchema.pm 26965 2023-01-05 06:32:17Z CoolTux
myUtilsTemplate.pm 7570 2015-01-14 18:31:44Z rudolfkoenig
RTypes.pm 10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm 25286 2021-12-03 10:16:56Z rudolfkoenig
SubProcess.pm 14334 2017-05-20 23:11:06Z neubert
TcpServerUtils.pm 25866 2022-03-21 09:01:16Z rudolfkoenig
doif.js 24438 2021-05-14 18:08:18Z Ellert
fhemweb.js 27117 2023-01-25 09:13:32Z rudolfkoenig
fhemweb_readingsGroup.js 15189 2017-10-03 17:53:27Z justme1968
Gruß
Daniel
Zitat von: WhyTea am 15 August 2023, 12:56:47So ich bin wieder einen Schritt weiter aber verstehe das Verhalten dennoch nicht.
Was habe ich gamacht:
Ich habe Fhem beendet den Code etwas sortiert (nicht verändert sondern ledig die Reihenfolge verändert) und sämtliche nicht benötigten Bestandteile auskommentiert.
Beim ersten Start waren lediglich Fhem Basiskomponenten sowie DBLog und HMCCU aktiv.
-Der Fehler trat nicht auf.
Anschließend habe ich schrittweise alle Komponenten wieder aktiviert und immer wieder kontrolliert ob der Fehler auftritt.
Aktuell habe ich alle Komponenten wieder aktiv und der RAM Bedarf ist seit 16 Stunden konstant.
Ich verstehe nur nicht warum. Das einzige was mir aufgefallen ist, ist dass durch das entfernen und wieder einbinden der Komponenten deren Status nachvollziehbarerweise verloren ging.
Ich bin mir nicht sicher ob fehlerhafte Statusinformationen / Readings ein solches Verhalten verursachen können.
Gibt es eigentlich eine andere Möglichkeit den Status aller Komponenten zurück zu setzen ohne diese zu entfernen und wieder anzulegen?
Das System läuft inzischen seit 5 Tagen ohne Probleme. Der RAM-Bedarf bleibt konstant bei knapp 1 GB.
Da ich zuvor schon alle verfügbaren Updates installiert habe und die Konfiguration nicht verändert sondern lediglich größten Teils auskommentiert und schrittweise wieder hinzugefügt habe verstehe ich nach wie vor nicht was das Problem verursacht hat. Ich tippe immernoch auf fehlerhafte Daten einer Komponente.
Daher hoffe ich auf eine Antwort ob es eine Möglichkeit gibt alle gespeicherten Informationen / Zustände der Komponenten zurückzusetzen ohne die Komponenten zu entfernen?