Ich habe gestern IP-Symcon auf meinem Windows 7 Recher auf v4.00, 07.07.2016, 63324d97b597 upgedatet.
Jetzt braucht der IP-Symcon Dienst fast 1GB Speicher und ich kann keine COM Schnittstellen mehr öffnen!!!
Ich verwende schon über 1 Jahr einen Moxa 5610 Serial Devices Server. Bis jetzt ohne jeglichen Problemen.
Wenn ich einen COM Port öffnen will bekomme ich folgende Fehlermeldung:
„open: Nicht genügend Systemressourcen, um den angeforderten Dienst auszuführen“
siehe Screenshot …
Hast jemand eine Idee, wie ich das Problem eingrenzen kann???
Damit ich zum Beispiel eingrenzen kann wo so viel Speicher gehalten wird??
Hinweis: Ich habe meine IP-Symcon Scripte die letzten Tage nicht geändert und davor lief alles über 2 Jahre ganz stabil!
Hi, ich hatte ja was ähnliches letztens, bei mir war es das „Meldungsfenster“ bei dem ich den Autoscroll deaktiviert hatte und somit keine Beschränkung der Meldungen aktiv waren. Prüfe das mal …
Und zwar hat der hohe Speicherverbrauch nichts mit den COM Ports zu tun. Da hat sich ein ganz anderes Problem mit einem Windows Update ergeben. Irgenwie konnte mein IP-Symcon Rechner nach einem Windows Update nicht mehr mit dem Moxa Serial Device Server kommunizieren. Bin mir zu 99% sicher das dies das letzte Windows Defender Update war. Wiederherstellungspunkt vor diesem Windows Update hat auf alle Fälle dieses COM Port Problem gelöst.
ABER, der Speicherverbrauch meines IP Symcon Dienstes ist noch immer über 1GB.
Ich hab mir dies jetzt mal genauer angesehen und folgendes festgestellt:
Beim Start des IPS Dienstes habe ich im LogFile unzählige ‚Lese Variablen Aggregationsdaten … #xxxx‘ und ‚Update variable aggregation data… ’ und auch einige '… Skipped! Downtime gap is too big. Please reaggregate manually‘ …
Genau wenn beim Start diese Aggregationsdaten ‚gelesen/upgedated‘ werden steigt mein Speicher auf 1GB an und wird nie wieder weniger…
Wenn ich nach dem Starten von ISP in den Archiv Handler gegangen bin, sagte dieser das er über 800 Variablen ReAggregieren will.
Das habe ich gemacht. Wenn ich dann IPS stoppe und wieder starte will der Archiv Handler wieder 15 Variablen ReAggregieren. Und ich glaub diese 15 Variablen kriegt er nicht hin da er die immer wieder ReAggregieren will.
Auch im LogFile finde ich bei doch einigen Variablen so was in der Form:
‚Invalid data for aggregation hour for VariableID #35264. Expected: 1467302400, Found: 1467306000‘
Ich glaub somit das der riesige Speicherverbrauch mit dem Archiv Handler zu tun hat!!!
Also vielleicht ‚ReAggregation‘ -> Datenfehler > und der Speicher wird nicht mehr frei gegeben …
Anbei das LogFile von der StartSequenz meines IPS Servers!
@kronos: Nein. Aber ich vermute du hast deine „alten“ Daten der DB hinzugefügt, oder? Wir laden die Aggregation in den RAM rein. Das scheint aber bei sehr großen Installationen nicht so gut zu sein. Ich denke ich werde zur 4.1 etwas umbauen müssen.
Ja - ich habe die alten Daten angefügt und alles komplett neu reaggregiert.
Den Zusammenhang zur Größe der Datenbank kannte ich nicht.
Ich habe mit dem Speicherbedarf keinen Stress - der Server ist gut ausgestattet. Hauptsache es gibt kein Leak denn ich muss das System auch mal über längere Zeit „alleine“ lassen können ohne das es sich gegen die Wand fährt. Fragt sich nur ob der Effekt auch bei den ARM-Versionen auftritt. Da könnte es dann schon enger werden.
Das Problem ist auch für die kleinen Pi’s vorhanden. Und unter Windows hast du als 32 Bit Programm bisher eine 2 GB Grenze. Sobald du drüber kommst macht IPS einen Abgang oder Fehlermeldung Ich weiß nicht, ob mittlerweile alle auf 64 Bit umgestiegen sind, sodass wir eine reine 64 Bit Version anbieten können. Ich mag nämlich nicht zwei Windows Versionen pflegen
Ich bin für 64bit - eine Umfrage könnte die Mehrheitsmeinung ermitteln - unabhängig davon bin ich auch der Meinung, dass nicht alle historischen Daten in den RAM müssen, optimal wäre natürlich parametrierbar pro Variable, sonst würde ich 90 Tage für eine guten Wert im RAM halten ;-)))) - alles darüber hinaus muss durch IPS (natürlich automatisch nachgeladen werden).