Python - Speicherleck

8

Ich arbeite an einem Speicherleck in meiner Python-Anwendung zu lösen.

Hier ist die Sache - es scheint wirklich nur auf Windows Server 2008 (nicht R2), aber nicht früheren Versionen von Windows zu geschehen, und es sieht auch nicht aus wie es unter Linux passiert (obwohl ich nicht fast so viel getan habe Testen unter Linux).

Zur Problembehandlung richte ich das Debugging auf dem Garbage Collector ein:

%Vor%

Dann protokolliere ich regelmäßig den Inhalt von gc.garbage.

Die Sache ist, gc.garbage ist immer leer, aber meine Speicherauslastung steigt und sinkt.

Sehr rätselhaft.

    
Dave 20.04.2010, 21:47
quelle

3 Antworten

2

Besser spät als nie. Hat das ziemlich schnell gelöst, aber vergessen, die Antwort zu posten. Am Ende haben wir den Twisted-Code herausgerissen und stattdessen CherryPy verwendet. Es ist viel leichter, einfacher zu benutzen und scheint nicht mehr zu passieren. Es ist wahrscheinlich, dass es unser Fehler war, dass es passiert ist und NICHT Twisted, aber der Code war so schlecht, dass wir einfach beschlossen haben, das zu schreiben, wäre am einfachsten.

    
Dave 02.02.2011, 15:01
quelle
26

Wenn es in gc.garbage keinen Müll gibt, bin ich mir nicht sicher, was Sie tun möchten, indem Sie das GC-Debuggen aktivieren. Sicher, es wird Ihnen sagen, welche Objekte für die Bereinigung in Betracht gezogen werden, aber das ist nicht besonders interessant, wenn Sie keine kreisförmigen Referenzen haben, die nicht bereinigt werden können.

Wenn Ihr Programm je nach Betriebssystem mehr und mehr Speicher verwendet, kann es im Allgemeinen vier verschiedene Fälle geben:

  1. Ihre Anwendung speichert mehr und mehr Dinge und behält Verweise auf diese, damit sie nicht gesammelt werden.
  2. Ihre Anwendung erstellt zirkuläre Referenzen zwischen Objekten, die vom Modul gc nicht bereinigt werden können (normalerweise, weil einer von ihnen eine __del__ -Methode hat.)
  3. Ihre Anwendung wird Speicher freigeben (und wiederverwenden), aber das Betriebssystem möchte nicht, dass der Speicher erneut verwendet wird, sodass immer neue Speicherblöcke zugewiesen werden.
  4. Das Leck ist ein echtes Speicherleck, aber in einem C / C ++ - Erweiterungsmodul, das Ihr Code verwendet.

Aus Ihrer Beschreibung klingt es, als ob es unwahrscheinlich ist, dass es # 1 ist (da es sich auf jedem Betriebssystem gleich verhält) und anscheinend auch nicht # 2 (da gc.garbage nichts enthält.) In Anbetracht von # 3, Windows (allgemein ) hat einen Speicherzuordner, der notorisch schlecht mit fragmentierten Zuordnungen ist, aber Python arbeitet mit seinem obmalloc frontend für malloc() . In Windows Server 2008-Systembibliotheken kann es sich jedoch weiterhin um ein Problem handeln, das dafür sorgt, dass Ihre Anwendung mehr und mehr Arbeitsspeicher verwendet. Oder es kann ein Fall von # 4 sein, ein C / C ++ - Erweiterungsmodul oder eine DLL, die von Python oder einem Erweiterungsmodul mit einem Speicherleck verwendet wird.

    
Thomas Wouters 20.04.2010 22:28
quelle
3

Im Allgemeinen ist der erste Schuldige für Speicherlecks in Python in C-Erweiterungen zu finden.
Benutzt du irgendwelche von ihnen?

Außerdem sagen Sie, dass das Problem erst 2008 passiert; Ich würde dann Erweiterungen auf Inkompatibilität überprüfen, weil es mit Vista und 2008 ziemlich viele kleine Änderungen gab, die Probleme in diesem Bereich verursachten.
Als Alternative versuchen Sie, Ihre Anwendung im Windows-Kompatibilitätsmodus auszuführen, indem Sie Windows XP wählen. Dies könnte helfen, das Problem zu lösen, insbesondere wenn es sich um Änderungen in der Sicherheit handelt.

    
Roberto Liffredo 20.04.2010 22:33
quelle

Tags und Links