gemacht ?
Wenn es ca. alle 48 h passiert, mal den Task-Manager mitlaufen lassen und nach 46/47 schauen, welche Task soviel Speicher verbraucht, ggf. schrittweise mehr und mehr anfordert ....
Druecke im htop bitte mal den Buchstaben M (gross). Dann sollte die Sortierung nach Speicherverbrauch erfolgen.
Dann laesst Du diese htop-Sesion einfach offen und pruefst immer mal wieder, ob sich in den Top-3 etwas aendert.
Idealerweise auch 47-48 Stunden nach dem CMX-Neustart ...
BTW: Ich habe hier genau EINEN task namens mono ...
Waechst bei Dir die Anzahl an mono-Instanzen?
Mach mal bitte ein
Hast Du denn in den Settings den Start einer 2. CMX Instanz unterdrückt ?
Settings --> Program Setting --> General Options ---> stop second instance
Es sieht ja so aus, als ob Du mehrere um nicht zu sagen viele CMX Instanzen parallel laufen hast, jede mit einer eigenen mono Instanz - da läuft sicher früher oder später der Hauptspeicher zu/voll
Wie sieht denn Deine Aug23log.txt aus - da müssten dann pro Speicherintervall mehrere Einträge sein, was sicher nicht gewünscht ist ....
Gyvate hat geschrieben: 18 Aug 2023, 20:01
Hast Du denn in den Settings den Start einer 2. CMX Instanz unterdrückt ?
Settings --> Program Setting --> General Options ---> stop second instance
habe ich.
Gyvate hat geschrieben: 18 Aug 2023, 20:01
Es sieht ja so aus, als ob Du mehrere um nicht zu sagen viele CMX Instanzen parallel laufen hast, jede mit einer eigenen mono Instanz - da läuft sicher früher oder später der Hauptspeicher zu/voll
Wie sieht denn Deine Aug23log.txt aus - da müssten dann pro Speicherintervall mehrere Einträge sein, was sicher nicht gewünscht ist ....
ich will jetzt nicht die Fehlersuche mit Ratschlägen torpedieren ...
Aber was ich machen würde wäre:
täglich irgendwann nach Mitternacht sowohl den Cumulus Service als auch den Mono-Service zu beenden (auch wenn er im Regelfall zusammen mit CMX beendet werden sollte) und danach (nur) den Cumulus-Service wieder neu zu starten. Da Du eh nur ein 5 Minuten Aufzeichnungsintervall hast, kannst Du ja den Servicestop z.B. um 00:16 und den Neustart um 00:18 machen.
Unabhängig davon solltest Du vielleicht erst mal @olicats Vorschläge umsetzen ...
Aber, mehr als eine mono Instanz ist auf jeden Fall zu viel ....
ich sehe gerade, dass wohl nur eine Instanz am Laufen ist - dann mal vielleicht meinen obigen Vorschlag umsetzen und explizit zusätzlich mono beenden, auch wenn das eine Fehlermeldung produziert.
In Deinem beigefuegten Bild zaehle ich aber 15 (!) Instanzen von mono/CMX. Wenn tatsaechlich die Anzahl der Instanzen mit der Zeit waechst ist das Verhalten (Speichermangel) nachvollziehbar.
Dann musst Du "nur noch" herauskriegen, wie und warum der Dienst immer wieder zusaetzlich gestartet wird, obwohl er doch schon laeuft ...
Eine moegliche Abhilfe habe ich hier gefunden.
Mit einer zusaetzlichen Zeile in der Dienste-Konfiguration wird (wohl) der Dienst nur gestartet, wenn der Dienst nicht schon laeuft.
Aber das erklaert nicht das aktuelle Verhalten.
Vielleicht findest Du eine Gesetzmaessigkeit, wann (wenn) es eine neue Instanz gibt?
Vielleicht wird der Dienst per cron alle paar Stunden gestartet?
olicat hat geschrieben: 19 Aug 2023, 01:13
Mit einer zusaetzlichen Zeile in der Dienste-Konfiguration wird (wohl) der Dienst nur gestartet, wenn der Dienst nicht schon laeuft.
offenbar sind die im htop angezeigten mono's nicht wirklich Instanzen, sondern Threads. Aber die Anzahl wächst. Im letzten Bild zähle ich schon 22 (oder so) - auf jeden Fall mehr als die 15 im Bild von gestern Abend.
Das heißt dann aber auch, dass die zusätzliche Zeile (die müsste unter Service eingetragen werden) nichts bringen dürfte.
Die Zeile mit dem wc -l gibt weiterhin 1 aus?
Eine wachsende Anzahl von Threads bedeutet, dass CMX irgendwelche Aufgaben turnusmäßig ausführt, die aber nicht fertig werden.
Fällt Dir in diesem Zusammenhang etwas ein?
Auf Github gab es im Maerz eine aehnliche Anfrage. Ich gehe bei Dir aber davon aus, dass CMX aktuell ist?