set_time_limit ausser gGefecht?

[BlueJay]

Hallo Leute,

habe mir gerade einen Anschiß vom Admin geholt.
Grund: ich habe php dazu mißbraucht, ein paar Random-Tabellen zu erstellen.

Erste Anweisung im Script ist zwar:

set_time_limit(30);

beim ersten Durchlauf bricht er auch brav ab, aber beim 2. Aufruf
scheint der Indianer das irgendwie zu ignorieren und rennt bis zu 5 Minuten weiter bei CPU-Vollast. (Screen-Output ist lang schon beendet)
Schön für meine Tabellen, schlecht für Stimmung vom Admin.

System:
php5 auf gentoo-amd64, diese Woche upgedatet (bleeding edge)
php.ini maximum execution time ist ungefähr 5 min.

Aber wieso ignoriert der Bursche mein time_limit?

so long,
BlueJay

[mehlvogel]

Hmm vielleicht das hier:

"Achtung: Wenn PHP im Safemode läuft, hat set_time_limit() keinen Effekt. Die einzige Möglichkeit, dies zu umgehen, ist den Safemode im configuration file auszuschalten."

Aber das würde natürlich nicht erklären warum es einmal ging und einmal nicht.

[BlueJay]

Hmm vielleicht das hier:

"Achtung: Wenn PHP im Safemode läuft, hat set_time_limit() keinen Effekt. Die einzige Möglichkeit, dies zu umgehen, ist den Safemode im configuration file auszuschalten."

Aber das würde natürlich nicht erklären warum es einmal ging und einmal nicht.

Safe mode ist off (Stand: heute morgen )

Beim (jeweils) erstenmal hat die Sicherheitsgrenze ja auch zugeschlagen, dann startet man (via Refresh) nochmal, um die nächsten Sätze zu bekommen, und da ist das Script die vollen 5 CPU-Minuten durchgelaufen.

[undefined]

Sorry aber deine Javascript Schreibweise ist in PHP Grauenvoll und Fehlerträchtig.
Zum Fehler - du hast ein Speicherloch in der while Schleife.
Und zwar deshalb weil die Funktion dublette() nach der Schleife kommt aber du setzt vor dublette() ein exit() Script Beenden.
Das heist der Compiler sucht nach der Funktion und findet sie auch daher Mäckert er auch nicht - das einlesen wird aber zuvor Beendet.
Setze die Funktion vor die Schleifen und Sehe noch mal was Passiert.
Mal als Tip: Der PHP Interpreter liest von Oben nach Unten von Rechts nach Links die Scripte durch.

[hds]

mal ne bloede zwischenfrage:
muss das ueberhaupt ueber den apache laufen?

es waere weitaus sinnvoller dieses script auf der commandline auszufuehren (per cron, 1mal taeglich, nachts).
waere das moeglich?

ich bin kein PHP freak, aber AFAIK habe ich das in erinnerung das man php scripte (genau wie python usw) natuerlich auch direkt auf der bash ausfuehren kann.

dieses haette den vorteil, die php.ini der bash anders zu gestalten als die welche ueber den indianer laeuft.

[Romanday]

mal ne bloede zwischenfrage:
muss das ueberhaupt ueber den apache laufen?

es waere weitaus sinnvoller dieses script auf der commandline auszufuehren (per cron, 1mal taeglich, nachts).
waere das moeglich?

ich bin kein PHP freak, aber AFAIK habe ich das in erinnerung das man php scripte (genau wie python usw) natuerlich auch direkt auf der bash ausfuehren kann.

dieses haette den vorteil, die php.ini der bash anders zu gestalten als die welche ueber den indianer laeuft.

Die Idee ist ja nicht schlecht, aber bei einem Account hat Sie meist keinen
Cron && || Shellzugriff.
Das entlastet zwar den Indianer + RAM aber Prozessor glüht trotzdem.
(Aber wie gesagt ich vermute nur, daß Sie nur einen Account hat.)

[Romanday]

Sorry aber deine Javascript Schreibweise ist in PHP Grauenvoll und Fehlerträchtig.

Sieht schon ziemlich heftig aus.
Aber trotzdem muß die Hardware soetwas abkönnen, ob da nun
Fehler im Script sind, oder nicht.
Dann muß der Admin eben mal 1-2 Speicherblocke auswechseln.
Außerdem eine Einstellung in der ini max_execution_time auf 5 Min.
zu setzen halte ich für vollkommen übertrieben.

Ich geh mal davon aus, das dies nicht dein eigener Server ist,
sondern du dir einen Account (nen Stück Festplatte) gemietet hast.
Da kann es natürlich sein, das noch andere Freaks den Rechner
knuten und knebeln. Dann wird es natürlich eng.

[BlueJay]

Sieht schon ziemlich heftig aus.

Statistiker kennen keine Gnade!

Außerdem eine Einstellung in der ini max_execution_time auf 5 Min.
zu setzen halte ich für vollkommen übertrieben.

Hat er mir zuliebe gemacht, weil ich aus den Logfiles Hitparaden erstellen wollte.
Kann ich natürlich auch wieder lokal machen und dann wöchentlich updaten.

[hds]

Aber trotzdem muß die Hardware soetwas abkönnen, ob da nun
Fehler im Script sind, oder nicht.

natuerlich kann die hardware "das ab", dennoch kanns ja wohl nicht sein, das sich ein php script ueber den indianer <=100% cpu last schnappt, sprich: alles was es an cpu power bekommen kann.

Ich geh mal davon aus, das dies nicht dein eigener Server ist,
sondern du dir einen Account (nen Stück Festplatte) gemietet hast.
Da kann es natürlich sein, das noch andere Freaks den Rechner
knuten und knebeln. Dann wird es natürlich eng.

noe, laeuft sonst nix drauf. ist mein server <g> und meine frau <g>

ansonsten wuerde ich die CPU last kaum sehen koennen, bei webspace, gell?

[BlueJay]

Sorry aber deine Javascript Schreibweise ist in PHP Grauenvoll und Fehlerträchtig.

Die ANSI-Schreibweise ist wohl nicht der Grund für den Fehler.

Eine do.. while-Schleife muss hier benutzt werden, weil
erst der Datensatz erstellt,
dann auf dublette geprüft wird.

Also genau dieses Konstrukt, was nun mal diese spezielle Syntax hat:
http://de.php.net/manual/en/control-...s.do.while.php

Zum Fehler - du hast ein Speicherloch in der while Schleife.
Und zwar deshalb weil die Funktion dublette() nach der Schleife kommt aber du setzt vor dublette() ein exit() Script Beenden.

Das wäre richtig, wenn vor dem while ein Semikolon stünde.
PHP arbeitet diese Schleife ja auch korrekt ab (nix Speicherloch), gemeckert wird nix, die Datenblöcke werden, wenn vollständig und ohne Dublette, korrekt geschrieben.

Setze die Funktion vor die Schleifen und Sehe noch mal was Passiert.

Eine 1a-Bauchlandung wegen fehlender Daten, schont natürlich die CPU

Nee, schon verstanden!
Geht nicht, weil die Daten erst in der do-while Schleife anfallen. Wieso soll ich eine Extra-Runde drehen und doppelten Code produzieren? DAS ist fehleranfällig!
Vgl. hierzu auch den Kommentar in obigem Link.

Der Knackpunkt vom Ganzen ist doch, dass er nach 30s nicht aufhört, zu rechnen, (ca. 17-30 Blöcke) sondern je nach max_execution_time bis zum bitteren Ende (40 - 100 Blöcke, sprich: bis zu 1800 Reihen) weitermacht und dabei die CPU anwärmt.

Die Datei ist natürlich mittlerweile recht heftig

Admin liest mit, da sage ich wohl besser nicht, dass ich so 18000 Zeilen anpeile

[BlueJay]

Beim (jeweils) erstenmal hat die Sicherheitsgrenze ja auch zugeschlagen, dann startet man (via Refresh) nochmal, um die nächsten Sätze zu bekommen, und da ist das Script die vollen 5 CPU-Minuten durchgelaufen.

Vorsicht, jetzt wird schwer geketzt!

Nachdem das Ganze ja ohne Indianer wie erwartet lief:
Kann es sein, dass durch irgend einen dummen Zufall beim Refresh-Button des Browsers, wenn das php-Script unter dem Indianer läuft, der "Countdown-Zähler" für die CPU nicht auf 0 zurückgestellt wird?
Weil vielleicht irgendwelche Flags wegen irgendwelchen "Abkürzungen", sprich:Optimierungen, nicht gesetzt und dadurch nix initialisiert wird?

Dass dann der cpu-Counter hinter dem Endwert weitermacht und bis ultimo (max_execution_time) läuft?

Nix gegen die php-Jungs, aber so was gab es auch schon in anderen Sprachen/Betriebssystemen.

[undefined]

Also wenn ich bei mir das Script Teste schiesst der Debugger ohne ende Fehler raus. Schalte mal dein error_reporting() auf E_STRICT
Und sage mir bitte wo du Array $f Definierst?
Sage mir bitte mal genau was du in die Datei Schreiben möchtest.
Das geht wenn ich es richtig sehe Wesentlich einfacher und Schneller.

[hds]

wie auch immer jetzt..
mir gehts eher darum, wie man sowas auf einem server vermeidet

wie macht das strato, puretec usw

selbst wenn das php script schlecht programiert ist, muss es doch eine moeglichkeit geben diesem die hohe serverlast zu verbieten - oder?

ist hier jetzt kein wirkliches problem, ist ja kein oeffentlicher hostingserver wo jeder hosten darf hier. dennoch interessiert mich, wie man sowas serverseitig unterbindet.

[BlueJay]

@undefinded:
Lass mal deine Bemühungen, das Script läuft (hier) FEHLERFREI und tut genau das, was es soll. Wenn Mr. Admin nicht auf meiner Maschine herumkompiliert (gentoo), sogar recht fix.

Was ihn stört, ist, dass sich php kackfrech 100% CPU-Last greift,
und was unser Zusammenleben stört, ist, dass sich php trotz angegebener php.ini-Einstellung bei set_time_limit() nicht immer an die angegebenen Grenzen hält.

[Romanday]

Hallo Leute,

habe mir gerade einen Anschiß vom Admin geholt.
Grund: ich habe php dazu mißbraucht, ein paar Random-Tabellen zu erstellen.

Erste Anweisung im Script ist zwar:

set_time_limit(30);

beim ersten Durchlauf bricht er auch brav ab, aber beim 2. Aufruf
scheint der Indianer das irgendwie zu ignorieren und rennt bis zu 5 Minuten weiter bei CPU-Vollast. (Screen-Output ist lang schon beendet)
Schön für meine Tabellen, schlecht für Stimmung vom Admin.

BlueJay

Bist Du dir sicher, das Du den Wert von set_time_limit innerhalb deiner
Schleife überschreibst? Poste doch mal den entsprechenden Teil deines
Scriptes.