Gestern gegen 21:00 Uhr den Dienst neugestartet mit 55MB und jetzt gegen 19:00 Uhr bei 185MB. Aktuelle Version #1840.
Leider muss ich das einfach so darstellen, weil weder etwas sinnvolles im Log dazu steht, noch ich irgendeinen anderen Hinweis zur Problemlösung beitragen kann. Mir ist das jedoch erst ab Version #1838 aufgefallen, kann aber schon vorher gewesen sein. Nur habe ich das so nicht beobachtet, weil ich zeitgleich mit IPS auf einen anderen „Server“ umgezogen bin.
Meine „waghalsige“ Vermutung geht in Richtung des neuen Datenbankhandlings, denn vorher konnte ich absolut keine Memoryleaks beobachten.
Ich habe keine Idee… denn an den Scripts resp. IPS wurden seither keine Veränderungen vorgenommen:confused:
Vielleicht hat irgendjemand eine Idee, wo man ansetzen könnte?!
Eine Schleife in einem Script kann ich aber ausschließen, denn wie geschrieben, wurde an der Programmierung nichts verändert, sondern nur neue Updates eingespielt und konnte bis „irgendwann“ keinen überproportional steigenden Speicherbedarf ausmachen.
Ich bin ratlos!
Edit:
Festgestellt habe ich das eigentlich erst, dass Webfront kaum noch bedienbar war und mehr als träge bei der Bedienung an den „Terminals“ reagierte. Nach Überprüfung mit Taskmanager stellte ich eine Speichernutzung von 465 MB durch IPS fest.
Nur ein Dienstneustart schaffte Abhilfe.
Bei mir ist es immer die Console (Dashboard), welche pro Tag ein paar hundert MB frisst.
Nächtliches neustarten ist ein muss.
Beim Dienst habe ich es noch nicht festgestellt, benutze allerdings auch keine Datenbanken.
habe gerade ganz plötzlich ein ähnliches Phänomen. Habe folgendes festgestellt:
ich habe gestern probehalber eine HMS-FTK-Instanz installiert. Das hatte zur Folge das automatisch ein FTDI-IO-Instanz erstellt wurde und eine FHZ1X00PC-Splitter Instanz. Letzters war mir nicht aufgefallen, führte aber heute zu reichlich Fehlern im IPS, brachte vermutlich auch die Geräteliste im Server durcheinander
Im Auswertescript gibt es einige Variablen, deren Bedeutung mir zu dem Zeitpunkt nicht klar war, also habe ich dieser unverändert stehen lassen (sind die letzten Codezeilen im Script):
die Folge war, das der IPS-Task im Speicherverbrauch von 68 MB auf über 500MB anstieg,die IPS-Konsole extrem langsam wurde und das WFE ständig Verbindungsfehler meldete. Ebenso drehte das Ereignisprotokoll vom IPS durch. Ich hab dann die betroffenen Zeilen erstmal auskommentiert, innerhalb von 5 Minuten hat sich das System beruhigt, der Speicherverbrauch ging langsam runter auf 69MB.
War auch das erste Mal, das ich so ein heftiges Problem hatte (ganz klarer Anwenderfehler!), habs aber durch die Logmeldungen sehr schnell eingrenzen und beheben können. Evtl. hilft Euch das weiter.
Ich habe auf meinem neuen System aber nur 1GB phys. Speicher zur Verfügung und hätte gern, wenn ich mal für’n 14tägigen Urlaub das Haus verlasse, dass sich das System nicht selbst „aufgegeben“ hat. So lange man es täglich überprüfen kann, ist das ja kein Ding… immer mal den Dienst neuzustarten, aber selbst das sollte es nicht sein:rolleyes:
Ist schon klar, wer will das schon.
Vielleicht gibt es da ja wirklich ein Problem.
Da ich in der Vergangenheit immer wieder je nach Version mit Problemen dieser Art zu tun hatte, habe ich mir mal ein Script gebastelt, welches bei längerfristiger Prozessor oder Speicherbelastung Nachts um 3 den Rechner sicherheithalber neu startet.
Das läuft bei mir immer im Hintergrund mit, egal ob es gerade mit IPS Probleme gibt oder nicht. Nur so zur Sicherheit.
Die Konsole wird aber sowieso immer nachts neu gestartet.
Habe ich auch… normal 5% bis zu Peaks von über 40%. Das ist aber normal, je nach Auslastung des Systems, wenn man Scripts im Sekundenbereich ausführen lässt.
Speicher müsste ich mal mitloggen lassen, habe auch nur 1GB.
Klar kan man sich solche „Hilfs-Krücken“ bauen, aber das will ich einfach nicht, obwohl ich daran auch schon dachte:rolleyes:
Die Ursache herauszufinden und evtl. Abhilfe zu schaffen finde ich aber allgemein interessanter… deshalb bin ich aus der Deckung, als eigentlich erfahrener IPS-Anwender, mit meinem Problem ausgetreten und hoffe auch ohne konkreten Hinweis eine Lösung zu erfahren. In die Tiefen des Sytems zu blicken und daraus meine Erkenntnisse zu gewinnen, ist mir bei dem Problem nicht gelungen.
Im allgemeinen ist „Brain“ eingeschalten, aber hier gebe ich auf!
ist ganz simpel.
Ich messe z. B. einfach die CPU Auslastung eimal die Stunde. Wenn drei mal nacheinander die Last >95% auf einem Kern ist, wird für Nachts der Neustart vorgemerkt.
Wir bis dahin mal eine geringere Last gemessen, wird der Merker wieder zurück gesetzt und nichts passiert.
So ist sichergestellt, das auch bei Problemen mit externen Programmen die mit auf dem Server laufen wie Squeezserver usw. keinen Stillstand von IPS verursachen können.
Sind nur ein paar Zeilen, bin jedoch gerade nicht am IPS Rechner.
Bei mir traten vergleichbare Probleme konkret unter zwei Voraussetzungen auf.
Tagelanges offen lassen der Konsole (= Faulheit).
Überlaufen der PHP-Queue (= Tabelle alles rot).
Punkt 1 habe ich durch Selbstdisziplin erledigt, Punkt 2 war eigentlich immer auf ein fehlerhaftes Skript oder eine nicht sauber abgefangene Fehlersituation in einem Skript oder einer Instanz zurückzuführen.
Ansonsten muß ich seit #1838 echt eine Lanze für IPS brechen. Ab dieser Version läuft das System bei mir so stabil wie ich es mir immer gewünscht hatte. IPSWatchdog hatte sonst immer alle 1-2 Tage eingegriffen - nun ist er seit erscheinen der #1838 arbeitslos.
Beides kann ich ausschließen.
Wie geschrieben… eigentlich bin ich mir keiner eigenen Schuld bewusst, aber man weiss ja nie… keine Ahnung warum sich das System, auf dem IPS läuft, nun so verhält, sonst hätte ich einen etwaigen Ansatz zur Problemlösung gerne beigetragen… komme mir vor, als wenn ich IPS erst seit 2 Wochen „probiere“ und eine Lösung scheint weit, weil ich nicht irgendeinen Ansatz finden kann…
zunächst muss ich sagen, das bei mir IPS derzeit absolut stabil läuft (neuste Version). Von daher würde ich einmal anfangen, Skripte und Module stilllegen
um festzustellen wo es schieflaeuft denn es scheint ja nicht den Kern zu
betreffen.
Probleme bei mir sind bisher meist entstanden, weil in Scripten Webtimeouts, falsche Schleifen, sonstige PHP-Fehlermeldungen, … waren.
Auch IP-Schnittstellen führen mal zu Problemen, wenn die Gegenseite nicht mehr oder nicht mehr richtig funktioniert.
Auch mein IPS läuft stabil, nur leidet das System an permanenten Speicherschwund:rolleyes:
Wie ich auch bereits schon schrieb, kann ich Fehler in den Scripten ebenfalls ausschließen, da ich mit Sicherheit sagen kann, dass IPS „früher“ (vor 1-1,5 Monaten) noch mit normaler Speicherlast lief und das wochenlang.
Probleme bei mir sind bisher meist entstanden, weil in Scripten Webtimeouts, falsche Schleifen, sonstige PHP-Fehlermeldungen, … waren.
Wenn es jetzt nur einfach wäre, einzelne Punkte der Webfront-Konfiguration zu deaktivieren, könnte man schnell mal überprüfen, ob das Problem dadurch verschwindet. So bleibt einem ja nur diese „Punkte“ komplett zu löschen.
Und man muss sich alles notieren, wie’s eingerichtet war, das man es wieder herstellen kann, wenns keinen Erfolg brachte…