Lorama: Script-Abbruch trotz set_time_limit(0)

Hi

leider will auf einem hosteurope Server mein Script nicht durchlaufen.
Nach ca 3 min bricht es ab, ohne Fehlermeldung, ohne Hinweis :-(

Nun habe ich eigentlich alle Möglichkeiten ausgeschöpft, aber es bricht immernoch vorzeitig ab :-(

ini_set('DISPLAY_ERRORS', 'On');  
ini_set('DISPLAY_STARTUP_ERRORS', 'On');  
error_reporting(E_ALL);  
set_time_limit(0);  
ini_set('mysql.connect_timeout','-1');  
ini_set('memory_limit',512);  
ini_set('display_errors',1);  
ignore_user_abort(true); 

Alle paar Sekunden lasse ich memory_get_peak_usage(), gefolgt von Leerzeilen und flush() die ausgeben und die letzte Ausgabe ist: 251624

Laut phpinfo() werden die Angaben auch so übernommen für "local".
Wie könnte ich herausfinden, warum das Script abbricht?

Woran kann es denn noch liegen?
Thx

  1. Hi!

    leider will auf einem hosteurope Server mein Script nicht durchlaufen.
    Nach ca 3 min bricht es ab, ohne Fehlermeldung, ohne Hinweis :-(

    Man kann Prozesse auch von außen killen, wenn sie zu lange brauchen. In dem Fall erfolgt das meist hart, ohne das PHP hier noch eine Chance hätte, irgendwas zu erzählen.

    Wie könnte ich herausfinden, warum das Script abbricht?

    Mit dem Hoster sprechen oder in seiner Dokumentation nachlesen, ob er was zu den Laufzeiten schreibt.

    Woran kann es denn noch liegen?

    Der Möglichkeiten gibt es sicher noch einige. Aber erst einmal mit dem Hoster zu reden (oder seine Doku zu befragen) ist vermutlich effektiver von Erfolg gekrönt als Rätselraten und Ausprobieren.

    Lo!

    1. Hi

      In der Doku war ich schon einige Stunden unterwegs. Dort wird darauf hingewiesen, dass set_time_limit(0) das Script beliebig lang laufen lässt.

      Der Support am Telefon bestätigt dies. Daher sollte der Hund anderswo begraben sein :-/

      Nur wo? ... nachdem error_reporting(E_ALL) nichts liefert...

      1. Hi!

        In der Doku war ich schon einige Stunden unterwegs. Dort wird darauf hingewiesen, dass set_time_limit(0) das Script beliebig lang laufen lässt.
        Der Support am Telefon bestätigt dies. Daher sollte der Hund anderswo begraben sein :-/

        Wusste ich nicht, hattest du ja nicht erwähnt.

        Nur wo? ... nachdem error_reporting(E_ALL) nichts liefert...

        Die Frage sollte lauten: Wo finde ich Informationen? Das Error-Log des Apachen wäre eine Anlaufstelle, die allerdings nicht immer für das Fußfolk einsehbar ist. Da müsste man wieder einen Admin befragen, ob er da mal nachsehen kann. Eine konkrete Uhrzeit anzugeben hilft, die gewünschte Stelle schneller zu finden.

        Weiterhin könntest du versuchen, dem PHP ein error_log zu konfigurieren, in der Hoffnung, dass es da was interessantes reinschreibt.

        Lo!

        1. Hi,

          an diese Logs werd ich nicht rankommen.
          Einen konkreten Verdacht hab ich dank der memory_get_peak_usage() Ausgabe.
          Sobald über 250M überschritten werden, ist es AUS.

          Also prüfe ich gleich mal das Script, ob irgendwelche unnötigen Speicherplätze freigeräumt werden könnten. Sieht aber schon so aus, als würde alles ordentlich "bereinigt" werden, oder fällt dir auf Anhieb etwas auf?

          Die Stelle, an der es abbricht, habe ich durch eine Vielzahl an echo/flush herausgefunden, siehe Kommentar

            
          for($i=0;$i<$n;$i=$i+20)  
          {  
           echo("<p>MEM: ".memory_get_peak_usage()."</p>\r\n");flush();  
           $dapiidtabelle=mysql_query("SELECT dapiid FROM bo_places WHERE dcrit<4 LIMIT ".$i.",20");  
           while($row=mysql_fetch_object($dapiidtabelle))  
           {  
          	$dapiid=$row->dapiid;  
          	$api_request="http://externe-api/".$dapiid;  
          	unset($result);  
          	for($retry=0;$retry<3;$retry++)  
          	{  
          		//beim Download von $api_request kommt jeweils eine Datenmenge zwischen 0 und 850KB  
          		$result=file_get_contents($api_request);//HIER BRICHT DAS SCRIPT DANN AB  
          		if($result)  
          			break;  
          	}  
          	unset($response);  
          	$response=json_decode($result);  
          	if(!$result OR !$response OR !$response->blocks)  
          	{  
          		mysql_query("UPDATE bo_places SET dapiid_error=dapiid_error+1 WHERE dapiid=".($row->dapiid));  
          	}  
          	else  
          	{  
          		$response = json_decode($result);  
          		$blocks=$row->dapiid;  
          		mysql_query("UPDATE bo_places SET dapiid_error=0,blocks=".$blocks." WHERE dapiid=".($row->dapiid));  
          		echo "<p>$dapiid: $blocks</p>";  
          	}  
          	flush();  
           echo("<br>\r\n");flush();  
           }  
           echo("<p>MEM: ".memory_get_peak_usage()."</p>\r\n");flush();  
           mysql_free_result($dapiidtabelle);  
          }  
          
          

          Sieht dort jemand eine Speicherleiche?

          Thx

          1. Hi,

            Einen konkreten Verdacht hab ich dank der memory_get_peak_usage() Ausgabe.
            Sobald über 250M überschritten werden, ist es AUS.

            ini_set('memory_limit',512);

            Setzt die erlaubte Speichergröße auf 512 Bytes, nicht 512 Megabytes. Keine Ahnung, warum das ignoriert wird, aber du wirst wohl

            ini_set('memory_limit',"512M");

            schreiben.
            Siehe auch das Handbuch zu memory_limit.

            $response=json_decode($result);
            [...]
            Sieht dort jemand eine Speicherleiche?

            json_decode bläht den benötigten Speicher IMHO immer sehr stark auf.

            Bis die Tage,
            Matti

          2. Hallo Lorama,

            an diese Logs werd ich nicht rankommen.

            Doch: im KIS kannst du sowohl accesslog als auch errorlog einsehen, außerdem kannst du einstellen ob Fehlermeldungen im Browser ausgegeben werden oder ob sie im errorlog landen sollen.

            Also prüfe ich gleich mal das Script, ob irgendwelche unnötigen Speicherplätze freigeräumt werden könnten. Sieht aber schon so aus, als würde alles ordentlich "bereinigt" werden, oder fällt dir auf Anhieb etwas auf?

            Die das Löschen der zwei Variablen mit unset() ist eigentlich überflüssig da die Variablen ohnehin mit neuem Inhalt überschrieben werden. Selbst wenn json_decode() recht viel Speicher braucht wird es wohl kaum soviel sein dass 250MB voll laufen.

            $dapiidtabelle=mysql_query("SELECT dapiid FROM bo_places WHERE dcrit<4 LIMIT ".$i.",20");

            ein ORDER BY wäre vielleicht ganz hilfreich wenn du keine zufällige Reihenfolge haben möchtest ...

            while($row=mysql_fetch_object($dapiidtabelle))

            das werde ich nie verstehen was alle an mysql_fetch_object() so toll finden, ich finde das Ergebnis als Objekt eher unpraktisch ...

              ~~~php
            

            $response = json_decode($result);

              $blocks=$row->dapiid;  
              mysql_query("UPDATE bo_places SET dapiid_error=0,blocks=".$blocks." WHERE dapiid=".($row->dapiid));
            
              
            wofür nochmal ein json\_decode()? Das wird doch schon vor dem if gemacht und das Ergebnis verarbeitest du garnicht weiter. Auch hast du drei Variablen die das gleiche enthalten: $dapiid, $row->dapiid und $blocks enthalten jeweils den gleichen Wert warum verwendest du nicht einfach nur eine Variable?  
              
              
              
            Gruß,  
            Tobias
            
          3. ... die letzte Ausgabe ist: 251624
            Einen konkreten Verdacht hab ich dank der memory_get_peak_usage() Ausgabe.
            Sobald über 250M überschritten werden, ist es AUS.

            Memory_get_peak_usage() gibt doch Byte aus und nicht kByte?!