Arbeitsspeicher nimmt kontinuierlich ab

Hallo Leidensgenossen,

habe heute wieder einiges an Zeit verbracht Webfront auf den aktuellsten Stand zu bringen und habe hierzu intensiv mit den Webserverinstanzen gearbeitet.

Quelltext bearbeitet, in Webfront Seite aktualisiert u.s.w.

In dieser Zeit ist mir in IPS 3x der Speicher mit dem o.g. Fehler vollgelaufen.

Vielleicht hilft es ja ein wenig.

Mein Skript hat natürlich seine Dienste geleistet, IPS-Prozess hart abgeschossen und anschließend wurde der Dienst wieder gestartet. Bin gepannt wie lange das noch gut geht.

Hallo paresy,

ich habe jetzt mal sämtliche Webserverinstanzen deaktiviert (wiips, webfront extern, sontige Webserver) sowie die Timer die Daten sammeln (wipps alle Module bzgl. RRD, DUG-Tools die Graphenerstellung). Im Moment läuft nur die erstellte Webfront-Instanz auf Port 82.

Seit 11 Stunden läuft mein System sauber mit 57MB Speicher, zuvor hatte es nach einigen Minuten bereits 70MB.

Falls es bei dieser Konfiguration sauber laufen sollte kann ich die Fehlersuche auf Webserver, RRD oder diverser Datenbankabfragen fest machen.

Hoffen wir das Beste.

P.S. Kann immer noch mit einem Logfile und meiner settings.xml dienen bei der der Fehler aufgetreten ist.

Hallo Zusammen,

ich beobachte bei meinem System das der Speicherverbrauch für das Dashboard von Anfangs ca.40MB nach einer Nacht auf ca. 120-150MB ansteigt.

IPS steigt von ca. 45MB über Nacht auf ca. 70MB.

Werte aus dem Windows Taskmanager.

Grüße
Andrge

hi,

Diese Probleme hatte ich auch gehabt. Deswegen hab ich mit dem Webfront aufgehört rumzuspielen und bin bei meinem Designer geblieben und zudem hab ich wipps nicht mehr drauf sondern mach die Diagramme über Mysql. Seit dem hatte ich gar keine Problem mehr.
Bei mir stieg der Designer/Dashboard auch über Nacht von ca. 60MB auf 500MB und mehr … Aber das passierte auch Tagsüber wenn IPS einige Stunden lief.
Das ganze ging auch soweit das der Dienst von IPS bei 1,5GB beendet wurde.

Gruß
Boris

Hallo Boris,

Diese Probleme hatte ich auch gehabt. … bin bei meinem Designer geblieben … Seit dem hatte ich gar keine Problem mehr.
Bei mir stieg der Designer/Dashboard auch über Nacht von ca. 60MB auf 500MB und mehr …

Wie, verwendest du nun das Dashboard oder nicht? Deine Aussage ist widersprüchlich. Sprichst du nur von der V2 oder Vergleich V1 zu V2??

Ich verwende kein Webfront, nur Dashboard ohne WIIPS, und sehe das beschriebene Verhalten.

Möglicherweise kommt die Problematik nur bei größeren Projekten?
Im Taskmanager kann ich auch eine Systemauslastung zwischen 30 - 100% bei IPS und Dashboard sehen. Der Durchschnitt liegt bei ca. 70%. Ohne Dashboard 10-40%, Durchschnitt ~20%.

Grüße
Andrge

Hi,

also ich hatte vorher WIIPS installiert für die Diagramme sowie den Designer für meine Visualisierung. Nebenbei hatte ich mit Webfront ein wenig rumgespielt und Seite eingefügt zum testen. Da hatte ich bemerkt, dass die Designerconsole als erstes einen stetigen Anstieg des Speichers aufwies … aber erst nach einigen Stunden. Der Dienst IPS hat von (gestartetem Zustand) 48MB bis max. 60MB gereicht. Die Designerconsole lief diesbezüglich nach max. 2 Tagen komplett aus dem ruder - 1,4GB und mehr!
Da ich aber im gleichen Zeitraum ein Update von WIIPS installiert habe, hab ich mir gedacht, das ich dann WIIPS runterschmeiße und auf Mysql umsteige was ich eh vorhatte und Webfront gefiel mir eh nicht so, deswegen hab ich das benutzen auch sein gelassen.
Nach diesen zwei Tätigkeiten lief IPS sowie die Designerconsole stabil und gleichmäßig.

Gruß
Boris

Hallo Boris,

danke für die Klarstellung. Wie würdest du die Umfang deines System + Dashboard beschreiben?

Grüße
Andrge

mmh …
wie soll ich sowas beschreiben. Ich hab noch kein IPS eines anderen Users gesehen um zu vergleichen. Kann dir mal meine Dateigrößen schreiben anhand von denen kann man ja ein wenig den Umfang abschätzen. Meine Designer *.bin hat eine reine größe von 350kb. Die settings.xml hat genau so viel. Im Gesamten habe ich ca. 200 Skripte in IPS und eine Logfile von 24h ist 50MB groß.

Gruß
Boris

Hi,

ich benutze weder WIIPS, Webfront, noch das Dashboard. Dennoch nimmt bei mir der Speicherbedarf auch kontinuierlich zu. Wahrscheinlich ist der Fehler in mehreren Instanzen zu finden.

Ich wünsche einen schönen Abend.

Christoph.

@paresy: Bist Du ratlos oder willst Du uns du… sterben lassen?:mad:

bei mir hat die IPS.exe nach 3 tagen so 32 Mb. benutze FHZ, WebFront und WIIPS.

Hallo xxxchris,

stellt sich folgendes Szenario

Hattest Du jemals ein Problem:

[ul]
[li]JA: Was hast Du gemacht damit es weg ist. :confused:[/li][li]NEIN: Dann hilft mir dein Feedback auch nicht:([/li][/ul]

Ich weiss auch nicht wo ich noch suchen soll.

Nach Dienst Start, dieser fängt schon bei 38 MB an und nach 1 Minute schon über 43 MB.

Das habe ich gerade gefunden im Log.

Fehler beim Laden der Bibliothek: xComfort.dll, Fehler: Fehler beim Laden des Moduls: C:\IP-Symcon\modules\xComfort.dll, Fehler: Abstract Error

das auch noch.

Fehler beim entladen der Module: LibraryCount != 0 (C:\Projects\IP-SYMCON\IPSMain\~kernel\UIPSModuleLoader.pas, line 209)

und das.

Fehler beim entladen der Bibliothek (Zensys Z-Wave): Access violation at address 0059237E in module 'ips.exe'. Read of address 03FCFF60

Ich habe leider nicht wirklich eine Idee warum es bei einigen Usern passiert und bei anderen nicht. Die genutzten Systeme ergeben auch keinen direkten Zusammenhang.

Habt ihr vielleicht Skripte, die irgendwelche Datenbank, Dateihandles offen lassen? Das wäre recht individuell und würde den konstanten abstieg, der öfters gezeigt wurde erklären?

paresy

Hi,

ich speichere nur ein paar Klimadaten in eine Access-DB. Hier mal der Code:

$sensor=array(
array("Temp","Feuchte"),
array(25760 /*[Garten\Termometer\TEMPERATURE]*/ ,49138 ),
array(32309 /*[Wintergarten\Heizung\Temp Feuchte IST\TEMPERATURE]*/ ,11188 ),
array(14319 /*[Küche\Heizung\Temp Feuchte IST\TEMPERATURE]*/ ,15387 ),
array(58498 /*[Wohnzimmer\Heizung\Temp Feuchte IST\TEMPERATURE]*/ ,37216  ),
array(22649 /*[Schlafzimmer\Heizung\Temp Feuchte IST\TEMPERATURE]*/ ,45303 ),
array(14859 /*[Bad\Heizung\Temp Feuchte IST\TEMPERATURE]*/ ,23329 ));

$datum=strftime("%Y%m%d");
$zeit=strftime("9%H%M");
$date2=strftime("%y%m%d%H%M");
$temp=0;
$feuchte=0;

$dbname="DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=C:/Programme/IP-SYMCON/web/test/IPS.mdb;FIL=MS Access;";
$dbh = odbc_connect($dbname, '','');

for($i=1;$i<count($sensor);$i++)
 {
 $temp=GetValueFloat($sensor[$i][0]);
 if($sensor[$i][1]!="")
  { $feuchte=GetValueInteger($sensor[$i][1]);
  if ($feuchte>90 && $temp>25)
   { //feuchte zu hoch, dann korrigieren.
   $feuchte=3;
   }
  }
 odbc_exec ($dbh, sprintf("insert into klima (datum, zeit, sensor, messwert1,messwert2, date2,zz) VALUES(%s,%s,%d,%.2f,%.2f,%s,%d)",$datum,$zeit,$i,$temp,$feuchte,$date2,time()));
 }

odbc_close_all();

Müsste nicht odbc_close_all() wieder alles korrekt freigeben?

Davon abgesehen verstehe ich nicht, warum das Öffnen der Verwaltungskonsole Speicher belegt, der nach dem Schließen nicht mehr freigegeben wird. Hier protokolliere ich nichts.

Ich wünsche einen schönen Abend.

Christoph.

Hallo paresy,

leider kann ich in meinem System nicht anfangen alles abzuschalten, wüßte im Moment nicht einmal wo ich anfangen sollte.

Die Vermutung auf meine Seite liegt auch bei datenbankintensiven Anwendungen. Da ich ein Verfechter von wiips und dem kürzlich erschienen DUG-Tool bin lag hier meine erste Vermutung, also habe ich wiips und DUG erst einmal deaktiviert was aber auch nicht wirklich Besserung brachte.

Nun habe ich im Moment nur die DUG-Tools am laufen (sorry Torro) aber auch hier sind bei exsesiven Arbeiten am System immer wieder Speicherüberläufe zu entdecken.

Ich habe zig Tools getestet um auf den Auslöser des Problems zu kommen aber bis auf des MS-Tool der SysInternals-Reihe VMMap hat mir keines beim eingrenzen des Fehler geholfen. VMMap analysiert den kompletten Prozess nebst aller Speicherbereiche.

Langsam aber sicher kann ich auch ein Leck in einem Modul ausschliessen da das Image des Prozesses nicht wirklich ansteigt. Was im Fehlerfall ansteigt ist der PRIVATE-Bereich, was immer der auch zu sagen hat.

Habe Dir einmal ein paar Screenshots des Tools angehängt. Vielleicht hilft auch noch das der Speicherbereich der voll läuft immer mit 1280Bytes gefüllt wird und anschließend nicht mehr freigebene wird.

Ach ja. Mein System läuft seit zwei Änderungen stabil.

[ol]
[li]aktuelle beta vim 27.04.2009[/li][li]Update der DUG-Tools auf 1.4[/li][/ol]Speicherbelegung des Prozesses beim Start 54MB und nach 2 Tagen 62-63MB. Beim generieren der Graphen des DUG-Tools mittels jpGraphs-Bibliothek und natürlich der GD2-Lib steigt der Prozesses kurzfristig auf 75MB wird aber eigentlich wieder freigegeben.

:DHallo paresy,

ich bin am verzweifeln. Kaum arbeite ich ein wenig am System, schmiert es ab.

Kaum hatte ich den vorherigen Beitrag fertiggeschrieben war es wieder so weit.

SPEICHERÜBERLAUF.:mad:

Wie vorhin erwähnt steigt nicht das Image mit den Modulen sondern der PRIVATE-Bereich, was immer das auch zu bedeuten hat.

Hier nocheinmal ein paar Graphen wärend des Speicherüberlaufes.

Das Angebot das ich Dir ein Logfile und die settings sende steht immer noch. Skripte wäre wohl ein wenig oversized, dann kommst Du nicht mehr zum Arbeiten

Hallo Leidensgenossen,
ich möchte das Thema nochmals hochbringen, da auch ich weiterhin Probleme habe.
Nach meinen Beobachtungen tritt bei mir das Problem nur auf wenn ich das Dashboard auf dem Server laufen lasse. Wenn das Dashboard auf einem anderen Rechner läuft zeigen sich bei mir keine Fehler (über 2-3Tage).

Nur mal ein Gedanke, kann es sein das Teile von IPS Empfindlich auf hohe CPU Auslastung geagieren, also das es bei zu langen Antwortzeiten zu den Problemen führt?
IPS (Server) und Dahboard erzeugen eine sehr hohe Windowsauslastung.

Gern kannst du dich auf mein System einloggen.

Grüße
Andrge

Hi,

Nur mal ein Gedanke, kann es sein das Teile von IPS Empfindlich auf hohe CPU Auslastung geagieren, also das es bei zu langen Antwortzeiten zu den Problemen führt?
IPS (Server) und Dahboard erzeugen eine sehr hohe Windowsauslastung.

das ist genau das Verhalten welches ich vor einiger Zeit schon beschrieben habe in Bezug auf die Console. Solange die Console nicht auf den IPS Server connectet, läuft soweit alles. Sobald man mit der Console arbeitet, kommen Zeitüberschreitungen ohne Ende (mal schneller, mal dauert es eine ganze Weile). Diese fangen sich auch nicht mehr, das Logfile explodiert und es hilft nur noch den Dienst zu beenden (was dann auch nicht immer funktioniert, aber meistens). Solange man kleine Projekte oder sehr schnelle Rechner hat, gibt es diese Probleme nicht. Mit wachsender Anzahl an Scripten und Variablen wird das immer schlimmer. Irgendwann ist der Punkt erreicht wo man die Console eigentlich nicht mehr vernünftig nutzen kann. Will man Fehler suchen kann man die Werteanzeige im Objektbaum vergessen, denn bis die sich aktualisieren ist alles vorbei. Schneller geht dann die Console zu beenden und eine neue Verbindung aufzubauen (was aber sehr nervig ist und eine Fehlersuche fast unmöglich macht). Auch das Anlegen von Variablen oder das einfache umbennen sind dann nur mit sehr langen Wartezeiten möglich bis man die Änderung im Objektbaum sieht (wir reden hier von mehreren Minuten).

Kleine Projekte wie gesagt kein Problem, große Projekte, großes Problem. Ich hatte eigentlich vor ein bisschen was mit dem Dashboard zu machen, aber der ist auf sparsamen Rechnern mit VIA C7 CPU’s nicht zu gebrauchen, daher mache ich jetzt auch die Touchscreens mit Webseiten und gut ist.

Ich hatte nach Umstellung auf V2 auch kein Problem mehr mit überlaufenden Speicher (das hatte ich in V1), aber seit einiger Zeit läuft der auch wieder hoch, wenn auch nur langsam (seit wann kann ich aber nicht sagen). Geändert habe ich aber kaum noch was, eher verschlankt. Ich muss das aber noch beobachten, den ich hatte da eigentlich nicht mehr drauf geschaut nachdem bei Beginn mit V2 der Speicher gestanden ist, ausser man hat sich mit der Console auf den Server verbunden.

Gruß
Thomas

Sorry für den Kommentar

Was nicht passt, wird passend gemacht :slight_smile:

Nicht immer und überall :mad:

Konnte ich mir bei meiner derzeitigen IPS-Laune:mad: nicht verkneifen.