[Erledigt] Objekte Rekursiv zerstören - Seite 2

mermshaus · 07.07.2011, 02:28

Zitat:

Zitat von mquadrat

Ist auch in neueren Delphis so.

Es gibt also doch noch „echte“ Programmiersprachen.

(Okay, okay.)

Zitat:

Ein unset kann Sinn machen, wenn man den Speicher braucht bevor der Request fertig abgearbeitet ist.

Ja, vielleicht mit der Einschränkung, dass das unset den „reference counter“ des entsprechenden Objekts auf 0 reduzieren und es damit für Garbage Collection interessant machen müsste. Wenn du zwei Variablen hast, die auf ein Objekt zeigen, löscht es sonst nur eine der Variablen aus der Symboltabelle. (afaik)

Edit:

Unter dem Vorbehalt, dass ich nie in den C-Quellcode von PHP geschaut habe:

PHP-Code:

  <?php

 
function memdump($label)

{

    echo $label . ' ' . memory_get_usage() . "\n";

}

 
class Foo

{

    protected $stuff;

 
    public function __construct()

    {

        $this->stuff = str_repeat('x', 1024 * 1024);

    }

}

 
memdump('1');

 
$f = new Foo();

 
memdump('2');

 
unset($f);

 
memdump('3');

 
$g = new Foo();

$h = $g;             # Zweite Variable, die auf die Foo-Instanz zeigt

 
memdump('4');

 
unset($g);

 
memdump('5');

 
unset($h);

 
memdump('6');

Code:

Fragensteller · 07.07.2011, 09:09

Zitat:

Zitat von eagle275

die Frage wäre eher - DARF dein PHP überhaupt die 2gbyte nutzen ?.. ME steht doch laut phpinfo() meist nur 256 mb - oder sogar nur 128 mb für PHP"Daten" zur Verfügung ....

vielleicht hilft dir ja in deinem Fall neben dem Upgrade auf 5.3 auch eine Änderung dieser php.ini- Einstellung

Code:

memory_limit	128M      128M

Das limit und ausführungszeit ist auf unbegrenzt.
Das Script zieht über eine API für jeden Kunden Berichte von einem anderen Anbieter.
Zur Zeit liegt die Anzahl über 2000 Kunden.

Das Original hat so gearbeitet:

Alle Kunden dir uns zu geordnert sind werden als array über api geholt.
Dann wird für jeden Kunden der komplette Zeitraum festgelegt.
In jedem Durchlauf werden nun die Berichte gezogen, immer in Monatshappen.
In dieser Schleifen wurden immer Objekte für den Kunden, Zeitraum, und Client erstellt.
Ebenso wird jeder Download als Objekt zwischengespeichert.

Das ganze dauerte nun ca 2 bis 3 Stunden. Dann war das Script zuende.
Hatte aber auch ca 2000+(Zeitraum/Monate)+anzahl objekte zuviel an Objekten.

Ich habe das ganze nun schon so ausgelagert, das die Objekte nur einmal erstellt werden und in jedem Durchlauf nur die nötigen Variablen neu gesetzt werden.
Den Download habe ich in ein extra Script gepackt, das druch curl aufgerufen wird und statt die Daten in ein Objekt zwischenspeichert und am Ende per foreach in Dateien speichert, gleich in die nötigen Dateien Speichert.
Somit wird am ende des Scripts auf jedenfall schon mal hier alles an Verbrauch aufgeräumt, und die anderen Objekte die zuviel waren werden auch nur einmal erzeugt. also statt einige tausend, nur ca 3 Objekte.

Ich setzte jede Variable und jedes Objekt das ich erzeuge nachdem ich es nicht mehr benötige auf NULL und dann ein unset().

Leider gibt es aber noch viele andere Stellen an denen Klassen verwendet werden in denen das nicht gemacht wird.

Zur Zeit läuft PHP5.2.6, machen aber gerade wegen dem GC ein Upgrade auf 5.3., mal sehen ob der mit dem Aufräumen hinterher kommt.

Und ich schau mal wo ich noch mehr aufräumen kann, damit das ding wenigsten läuft, wenn auch unsauber... der neuaufbau ist ja geplant.

tr0y · 07.07.2011, 09:48

Ich denke am gesündesten wäre es wenn du den Update-Progress auf 2 Scripte auslagerst, eins das als Carrier dient und die abzuarbeitenden Jobs erzeugt und ein Script das die Jobs abarbeitet. Funktioniert natürlich nur solange, solang die APIs erlauben entsprechende Daten explizit anzufordern ohne gleich mit den eigentlichen "Berichten" der Kunden beworfen zu werden ( die Generierungszeit der APIs also auch so klein wie Möglich gehalten werden ).

Die "Grenzen" der Scripte auf System-Maximum ( unendlich ) zu stellen, halte ich für Murks³. Du solltest genau wissen wie groß der Speicherverbrauch werden kann, den der Prozess benötigt um alle Abfragen durchzuführen. Aus dem Grund muss deine gesamte Processing-Logik auch auf die minimal nötigsten Limits aufgebaut werden.

Kurz zusammengefasst: Das Carrier-Script erzeugt alle Jobs in ein ( temporäres ) Datenbank-Table, erstellt einen Prozess das den ersten unerledigten Job aus der Tabelle nimmt und abarbeitet, der Carrier "wartet" hier sogar bis das Script fertig ist und spawnt erst dann eine neue Instanz des Scripts. Ist der Carrier-Prozess verschwunden ist das Update erledigt und die Job-Tabelle leer / nur noch mit Fehlerhaften Jobs bestückt ( als quasi monitoring ). Thats all, die Speicherhungrigen Updates "räumen" sich in dem Fall selbst weg, kein Aufräumen nötig.

Aber das wird wohl "zukünftig" erst interessant, beim Rebuild des Crons.

Fragensteller · 07.07.2011, 12:15

so, für den den es interessiert... ich konnte den Verbrauch nun auf 9 MB reduzieren.

Danke an Euch

nikosch · 07.07.2011, 14:49

mquadrat · 07.07.2011, 14:56

Von 2GB auf 9MB? Das Ding muss ursprünglich ein wahrer PHP Gott geschrieben haben

lstegelitz · 07.07.2011, 15:02

Und da behaupte nochmal jemand, korrektes Resourcenhandling (MYSQL Klasse) wäre nicht wichtig.

(sorry, der musste einfach raus - nix für Ungut

)

nikosch · 07.07.2011, 15:19

Woran es lag, wurde ja nicht beschrieben. Und ein Bunch of Objects ist sicher eine andere Baustelle, als 2 nicht geschlossene Datenbankhandles.

lstegelitz · 07.07.2011, 15:28

jaja, bin ja schon still

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Array aus SQL Abfrage zusammenbauen um es rekursiv abzuarbeiten	litterauspirna	PHP Einsteiger	7	01.02.2011 18:44
Objekte mit Attributen variabler Anzahl und variablen Typs speichern	Bergtroll	Datenbanken	9	29.01.2011 14:54
[Erledigt] Zerstörung der Objekte am Ende eines Scripts	ByStones	PHP Tipps 2010	8	03.05.2010 14:01
[Erledigt] Browsergame : Objekte auf einer Karte	BlackScorp	Software-Design	10	01.04.2010 09:59
Verschachtelte Objekte und Vererbung	GELight	PHP-Fortgeschrittene	1	11.12.2009 09:09
Was bringt OOP wenn Objekte nach jeder Seite sterben?	majorbenks	PHP Tipps 2009	9	18.11.2009 14:11
[Erledigt] Referenzen auf Objekte innerhalb eines Arrays		PHP-Fortgeschrittene	6	31.08.2009 17:06
[Erledigt] Wo liegen bei OOP die Objekte?	Jafix	PHP Tipps 2009	2	12.06.2009 18:14
[Erledigt] Objekte übergeben	Felix	PHP Tipps 2008	23	18.06.2008 12:21
Objekte zerstören	galaxyshadow	PHP Tipps 2008	4	12.05.2008 10:29
Objekte zur Laufzeit Vererbung anhängen	Zergling-new	PHP-Fortgeschrittene	8	17.11.2007 17:31
[Erledigt] Objekte vergleichen		PHP-Fortgeschrittene	4	08.12.2005 16:20
Ganze Objekte an Script weitergeben	dreamingof8a	PHP Tipps 2004-2	6	23.11.2004 12:17
[Erledigt] Referenzen auf Objekte		PHP-Fortgeschrittene	2	17.08.2004 11:08
Anonyme Objekte?		PHP-Fortgeschrittene	18	25.07.2004 22:19


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

07.07.2011, 09:48
tr0y Erfahrener Benutzer Registriert seit: 26.07.2010 Beiträge: 4.874 PHP-Kenntnisse: Fortgeschritten	Ich denke am gesündesten wäre es wenn du den Update-Progress auf 2 Scripte auslagerst, eins das als Carrier dient und die abzuarbeitenden Jobs erzeugt und ein Script das die Jobs abarbeitet. Funktioniert natürlich nur solange, solang die APIs erlauben entsprechende Daten explizit anzufordern ohne gleich mit den eigentlichen "Berichten" der Kunden beworfen zu werden ( die Generierungszeit der APIs also auch so klein wie Möglich gehalten werden ). Die "Grenzen" der Scripte auf System-Maximum ( unendlich ) zu stellen, halte ich für Murks³. Du solltest genau wissen wie groß der Speicherverbrauch werden kann, den der Prozess benötigt um alle Abfragen durchzuführen. Aus dem Grund muss deine gesamte Processing-Logik auch auf die minimal nötigsten Limits aufgebaut werden. Kurz zusammengefasst: Das Carrier-Script erzeugt alle Jobs in ein ( temporäres ) Datenbank-Table, erstellt einen Prozess das den ersten unerledigten Job aus der Tabelle nimmt und abarbeitet, der Carrier "wartet" hier sogar bis das Script fertig ist und spawnt erst dann eine neue Instanz des Scripts. Ist der Carrier-Prozess verschwunden ist das Update erledigt und die Job-Tabelle leer / nur noch mit Fehlerhaften Jobs bestückt ( als quasi monitoring ). Thats all, die Speicherhungrigen Updates "räumen" sich in dem Fall selbst weg, kein Aufräumen nötig. Aber das wird wohl "zukünftig" erst interessant, beim Rebuild des Crons. __________________ Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

07.07.2011, 12:15
Fragensteller Neuer Benutzer Registriert seit: 05.07.2011 Beiträge: 6 PHP-Kenntnisse: Fortgeschritten	so, für den den es interessiert... ich konnte den Verbrauch nun auf 9 MB reduzieren. Danke an Euch

07.07.2011, 14:49
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Lol __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

07.07.2011, 14:56
mquadrat Erfahrener Benutzer Registriert seit: 02.09.2009 Beiträge: 1.019 PHP-Kenntnisse: Fortgeschritten	Von 2GB auf 9MB? Das Ding muss ursprünglich ein wahrer PHP Gott geschrieben haben __________________ Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de

07.07.2011, 15:02
lstegelitz Erfahrener Benutzer Registriert seit: 07.09.2009 Beiträge: 4.005 PHP-Kenntnisse: Fortgeschritten	Und da behaupte nochmal jemand, korrektes Resourcenhandling (MYSQL Klasse) wäre nicht wichtig. (sorry, der musste einfach raus - nix für Ungut ) __________________ Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

07.07.2011, 15:19
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Woran es lag, wurde ja nicht beschrieben. Und ein Bunch of Objects ist sicher eine andere Baustelle, als 2 nicht geschlossene Datenbankhandles. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

07.07.2011, 15:28
lstegelitz Erfahrener Benutzer Registriert seit: 07.09.2009 Beiträge: 4.005 PHP-Kenntnisse: Fortgeschritten	jaja, bin ja schon still __________________ Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.