Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 18 von 18

Thema: zklisches dc.execReadRequest(multireadPDU01, rs) reserviert !zunehmends! Speicher

  1. #11
    bool ist offline Benutzer
    Themenstarter
    Registriert seit
    26.03.2010
    Beiträge
    94
    Danke
    3
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Habe eben mal den GC Aufruf vor den zyklischen Poll gesetzt. Es scheint als würde ein einmaliger GC Aufruf schon ausreichen, dass die "abgemeldeten Daten" sauber entsorgt werden. Kann das jemand bestätigen, dass es so richtig ist, dass der GC.Collect() ab dessen ersten und eizigen Aufruf aktiv ist und nach einer gewissen Zeit NICHT erneut aufgerufen werden muss?

    Danke und Gruss,

    bool

  2. #12
    Registriert seit
    17.06.2004
    Ort
    Offenau
    Beiträge
    3.758
    Danke
    209
    Erhielt 421 Danke für 338 Beiträge

    Standard

    Zitat Zitat von bool Beitrag anzeigen
    Hallo Jochen,
    danke für das Feedback.

    Dass der Speicher deratig starg anwächst (Innerhalb von keinen vier Stunden auf >50MB) möchte/darf ich jedoch nicht zulassen, vor allem nicht auf einem Produktivsystem in der Fertigung wo ettliche andere Programme parallel auf dem System laufen und nicht in Bedrängnis geraten dürfen.

    Alternativen zum zyklischen Aufruf der GC.Collect() vor jedem readRequest()welche ich da so sehen würde:
    a) Aufruf eines zweiten Timer im z.B. 10 oder 60 Minutentakt um den GC.Collect() dort kontrolliert aufzurufen um keine grössere Perfomanceeinbußen zu riskieren. Der "assynchrone" Aufruf in einem zweiten Timer könnte dann höchstens ein Problem darstellen wenn der Destruktor von rs vor der Auswertung aufgerufen wird. Weisst Du ggf. wann der Destruktor von rs bei libnodave.net ausgeführt wird?

    b) Hochzählen eines Zählers innerhalb des ersten Timers und Ausführen des GC.Collect alle x Aufrufe (z.B 1000 oder mehr, je nachdem wieviel MB man +/- tollerieren kann/möchte/darf -> wäre doch ein schönes Parameter fürs Ini-File)

    Ich denke (b)) wäre ein Kompromiss mit dem ich auch leben könnte.

    Gruss,

    bool
    Also Ich denke immer noch nicht das du das tun musst, da wenn vom System Speicher gebraucht wird der Garbage Collector aufgerufen wird!

    siehe auch http://dotnetbase.de/faq-was-garbage...torb-t583.html
    ---------------------------------------------
    Jochen Kühner
    https://github.com/jogibear9988/DotN...ToolBoxLibrary - Bibliothek zur Kommunikation mit PLCs und zum öffnen von Step 5/7 Projekten

  3. #13
    bool ist offline Benutzer
    Themenstarter
    Registriert seit
    26.03.2010
    Beiträge
    94
    Danke
    3
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Zitat Zitat von Jochen Kühner Beitrag anzeigen
    Also Ich denke immer noch nicht das du das tun musst, da wenn vom System Speicher gebraucht wird der Garbage Collector aufgerufen wird!

    siehe auch http://dotnetbase.de/faq-was-garbage...torb-t583.html
    Danke für den Link.
    Da wir in der Vergangenheit auf Produktivsystemen bereits Probleme mit Speicherfressern (im speziellen ein simpler Druckertreiber eines renomierten Herstellers) hatten welche zunehmends Speicher alloziiert aber nicht wieder freigegeben haben.
    Auf diese Weise war bereits einmal das gesamte Produktivsystem zum Absturz gekommen. Seitdem werden die Resourcen von Programmen und Diensten stets beäugt und ist es nicht gern gesehen, wenn die Resourcen eines Programmes stetig zunehmen.
    Wenn man nun Programme einsetzt bei denen es sozusagen in Ordnung ist, wenn diese zunehmend Speicher beanspruchen, da dieser erst freigegeben wird wenn dieser benötigt wird, geht eine einfach und doch wichtige Kontrollfunktion per einfachen Blick in den Task-Manager verloren.

    Gruss,

    bool

  4. #14
    Registriert seit
    17.06.2004
    Ort
    Offenau
    Beiträge
    3.758
    Danke
    209
    Erhielt 421 Danke für 338 Beiträge

    Standard

    Zitat Zitat von bool Beitrag anzeigen
    Danke für den Link.
    Da wir in der Vergangenheit auf Produktivsystemen bereits Probleme mit Speicherfressern (im speziellen ein simpler Druckertreiber eines renomierten Herstellers) hatten welche zunehmends Speicher alloziiert aber nicht wieder freigegeben haben.
    Auf diese Weise war bereits einmal das gesamte Produktivsystem zum Absturz gekommen. Seitdem werden die Resourcen von Programmen und Diensten stets beäugt und ist es nicht gern gesehen, wenn die Resourcen eines Programmes stetig zunehmen.
    Wenn man nun Programme einsetzt bei denen es sozusagen in Ordnung ist, wenn diese zunehmend Speicher beanspruchen, da dieser erst freigegeben wird wenn dieser benötigt wird, geht eine einfach und doch wichtige Kontrollfunktion per einfachen Blick in den Task-Manager verloren.

    Gruss,

    bool
    Man kann ja das GC.collect automatisch aufrufen, Ich wollte nur erläutern das man es normal nicht macht und nicht nötig ist. Und wenn dein programm mal ein paar Wochen läuft ohne das die Speicherauslastung weiter steigt, dann kannst du ja das GC.collect entfernen.

    Also wenn du den GC ständig aufrufst sollte auf jeden Fall der Speicherbedarf nicht immer steigen! Es gilt ja rauszufinden ob es ein Problem in LibNoDave, oder eines deines CSharp programmes ist!
    ---------------------------------------------
    Jochen Kühner
    https://github.com/jogibear9988/DotN...ToolBoxLibrary - Bibliothek zur Kommunikation mit PLCs und zum öffnen von Step 5/7 Projekten

  5. #15
    Registriert seit
    28.10.2005
    Ort
    Ottweiler, Saar
    Beiträge
    940
    Danke
    259
    Erhielt 124 Danke für 109 Beiträge

    Standard

    Gerade bei Produktivsystemen achte ich auch darauf, dass meine Anwendung keinen Speicher frisst. Ob das jetzt die Anwendung selber ist oder das tolle Framework drumrum ist mir dabei völlig egal. Kann man das ständige Allozieren von Speicher nicht tolerieren, so bleibt leider nichts anderes übrig, als etwas anderes zu verwenden. LibNoDave zB funktioniert auch sehr gut mit ANSI-C.

    Der Grund ist natürlich, dass das Verhalten der Müllsammlung (Garbage Collection) nicht sicher vorhersagbar ist.
    Bei PCs, die täglich neu hochfahren oder einen riesigen SWAP haben, ist das kein wesentliches Problem. Aber das ist auch eine andere Liga.

  6. #16
    Registriert seit
    07.07.2004
    Beiträge
    3.285
    Danke
    38
    Erhielt 584 Danke für 382 Beiträge

    Idee

    Hallo,

    Zitat Zitat von argv_user
    Der Grund ist natürlich, dass das Verhalten der Müllsammlung (Garbage Collection) nicht sicher vorhersagbar ist.
    Völlig richtig. Aber grundsätzlich gilt : Keine Panik, wenn nach ein paar Stunden Laufzeit die Speicherauslastung ansteigt, ein vernünftiger Speichermanager räumt den Garbage nicht alle paar Sekunden auf. Sondern nur, wenn weiterer Bedarf an Speicher anfällt.
    Insofern macht es absolut keinen Sinn, den Garbage Collector immer wieder aus dem Programm aufzurufen, das regelt der schon alleine. Unser User "bool" ist da wohl angesichts des steigenden Speicherbedarfs in Panik geraten, aber keine Angst. Ein vernünftiger Speichermanager regelt das schon im Hintergrund.

    @bool : Nimm einfach den Rat von Jochen Kühner an, es besteht kein Grund zur Panik ...
    Um das zu verifizieren, starte einfach Deine Applikation und dann noch einige andere Programme, die intensiv Arbeitsspeicher verbrauchen. Und lasse das nicht nur eine Stunde, sondern auch mal einen Tag laufen. Du wirst sehen, alles regelt sich von selbst. Das Verhalten kann man auch in gewissen Grenzen über die Größe der Auslagerungsdatei von Windows steuern.
    Anderer Vorschlag : Beobachte die Speicherauslastung und starte Deine Applikation (und nichts anderes). Lass das ganze einen Tag laufen und schließe das Programm. Danach sollte die Speicherauslastung wieder auf dem gleichen Stand wie vor dem Start der Applikation sein. Wenn nicht, hast Du wirklich einen Speicherfresser in Deinem Programm. Aber zum Aufspüren von Speicherleaks gibt es gute s. Bei Delphi gibt es da zum Beispiel den FastMM oder EurekaLog, die zeigen Dir direkt im Quelltext die Zeile des Ursprungs von Speicherleaks an. Ich selber verwende kein VB (und ich weiss auch genau warum), aber grundsätzlich lässt sich das auch auf VB übertragen.

    Also keine Panik, Jochen Kühner liegt da schon richtig mit seiner Vermutung.
    Jedenfalls ist es seit Windows XP möglich, Programme zu schreiben, die jahrelang im 24/7 Betrieb ohne Probleme stabil durchlaufen
    Aber um das zu erreichen, muss man schon etwas Erfahrung haben, um Fehlersituationen ohne sichtbare MessageBoxen wie General Protection Fault abzufangen.

    Gruß

    Question_mark
    Zitieren Zitieren Keine Panik auf der Titanic  

  7. Folgender Benutzer sagt Danke zu Question_mark für den nützlichen Beitrag:

    argv_user (17.05.2010)

  8. #17
    Registriert seit
    07.07.2004
    Beiträge
    3.285
    Danke
    38
    Erhielt 584 Danke für 382 Beiträge

    Daumen hoch

    Hallo,

    Zitat Zitat von bool
    doch wichtige Kontrollfunktion per einfachen Blick in den Task-Manager verloren.
    Ähemm, da möchte ich doch gerne mal anmerken : Wer zum Teufel kann denn die Angaben der Speicherauslastung des Systems im TaskManager qualifiziert und sinnvoll auswerten ?

    Ich kann das nicht ! Du etwa, dann herzlichen Glückwunsch, ich ernenne Dich damit zum Experten

    Gruß

    Question_mark
    Zitieren Zitieren ???  

  9. #18
    Registriert seit
    07.07.2004
    Beiträge
    3.285
    Danke
    38
    Erhielt 584 Danke für 382 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo,

    Zitat Zitat von bool
    etwa alle zwei bis drei Sekunden 4kB zusätzlichen Speicher reserviert und diesen erst mit Programmende wieder freigibt
    Und selbst wenn Du nur ein popeliges Byte in Deinem Programm allozierst, wird der Speichermanager immer 4kB beim System (also Windows) anfordern und belegen.

    Wie das ganze dann verwaltet wird, also überlasse das ganz einfach Deinem Compiler und dem OS.

    Gruß

    Question_mark
    Zitieren Zitieren ???  

Ähnliche Themen

  1. zu kleiner Speicher? S5-95u
    Von Szina im Forum Simatic
    Antworten: 7
    Letzter Beitrag: 23.02.2010, 05:26
  2. Pc Speicher
    Von waldy im Forum Stammtisch
    Antworten: 23
    Letzter Beitrag: 23.02.2010, 00:21
  3. Speicher der SIMATIC
    Von alphatier im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 03.04.2009, 13:03
  4. DB in CSV Speicher
    Von Anonymous im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 17.12.2005, 13:27
  5. Speicher Karte
    Von heiko im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 11.04.2004, 10:24

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •