Also, die älteren unter uns werden sich daran erinnern, daß ich bisweilen ein Schattengefechte mit dem Linux OOM-Killer ausfechtender gewesen bin. Am Dec 1 17:10:46 war es wieder soweit. Ich hatte inzwischen eine von mir mit Traces gespickte Version von linux/mm/oom_kill.c eingespielt gehabt - wer will, kann sich das Archiv mal runterladen von http://p-nand-q.com/python/zeug.tar.bz2 - enthält orginal-oom_kill.c, mein-oom_kill.c und 1 x Auszug aus /var/log/messages. Was soll ich sagen - es scheint wirklich, daß mein schnuckeliger Python-Prozess den ganzen Speicher frisst. Fragen: 1) Weiss jemand auswendig, in welcher Einheit struct task_struct *p ... points = p->mm->total_vm; verfasst ist? Ich bin grade unter Win beschäftigt und kann deshalb nicht direkt nachsehen. Ich guck derweil auch ganz beschämt auf den Boden, ehrlich. 2) Auf jeden Fall ist ein einzelner Python-Prozess "mehr als zwei MySQLs", was mich schon mal bedenklich stimmt - mysql ist nicht gerade ein gertenschlankes Abführmittelmodel. Wie kann man denn - am besten regelmäßig zur Runtime - rausfinden, welches Python-Objekt wieviel Speicher verbrät? Selberbasteln, Speicherverwaltung hooken, oder was? Andererseits - ich kann trotz allem nicht glauben, das über 700 mb physikalischen Speichers immer noch nicht für ein paar lumpige Skripten ausreichen sollen. Deshalb 3) Gibt es ein Linux-Cache-Tweak-Howto? Ciao, Gerson _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
Wie kann man denn - am besten regelmäßig zur Runtime - rausfinden, welches Python-Objekt wieviel Speicher verbrät? Selberbasteln, Speicherverwaltung hooken, oder was?
Ein einzelnes Python-Objekt verbrauch i.d.R. nicht mehr als 200 Byte oder so, wenn es sich nicht gerade um einen String, eine Liste oder ein Dictionary handelt. Wahrscheinlicher ist, dass der Speicher dadurch verbraucht wird, dass es immer mehr Objekte werden. Mit gc.get_objects() bekommt man eine Liste aller "Container"-Objekte (also aller vom GC verwalteten Objekte), da kann man mal schaun, ob die Liste nicht vielleicht immer länger wird. Als nächstes kann man sie dann nach Typen sortieren, und schaun, von welchem Typ die hinzukommenden Objekte sind. Dabei nicht erfasst werden nicht-Container; die Liste *aller* Objekte kann man nur in der Debug-Version von Python erhalten. Da wären dann auch Strings dabei - große Strings verbrauchen viel Speicher. Vielleicht gibt es ja sowas wie log_data += new_data in Deinem Programm, damit würde der verbrauchte Speicher immer größer werden. Wenn es nicht immer mehr Objekte werden, kannst Du auf die Größe der Objekte schaun. Bei Objekten Variabler Größe liefert len() immer einen guten Wert, den man mit einer kleinen ganzen Zahl multiplizieren muss, um den Speicherverbrauch zu bekommen. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
participants (2)
-
Gerson.Kurz@t-online.de -
Martin v. L�wis