[vz-users] PPM - PHP maximum execution time exceeded

Andreas Goetz cpuidle at gmail.com
Sun Nov 24 10:41:41 CET 2019


Noch ein paar andere Ideen. Du hast:

/etc/php/7.3/cli/php.ini
max_execution_time => 0 => 0

Also *darf* das nicht passieren. Wo kommen also die 30 Sekunden her? Hast Du noch eine .ppm.json in der die drin stehen könnten? Siehe ConfigTrait.php wo die ausgelesen werden.

Ansonsten ändere mal bitte im ProcessManager das set_time_limit(0);
in var_dump(set_time_limit(0)); - ich würde gerne sehen ob das überhaupt erfolgreich ist.

Viele Grüße, Andreas

> On 24. Nov 2019, at 10:08, Andreas Goetz <cpuidle at gmail.com> wrote:
> 
> Passiert der Timeout auch wenn die Aggregation läuft? Sollte ja eigentlich da vom gleichen PHP Interpreter ausgeführt?
> 
> Viele Grüße, Andreas 
> 
>> Am 23.11.2019 um 23:45 schrieb joekokker at epios.eu:
>> 
>> Hallo,
>> 
>> danke für die Rückmeldungen! Mittlerweile bin ich etwas weitergekommen.
>> 
>> Ich habe die benötigten php-Pakete (laut Webseite) und zusätzlich php-cgi neu installiert. Dann konnte ich den ppm sowohl mit /usr/bin/php und auch /usr/bin/php-cgi ohne Fehler starten. Es hat aber keinen Unterschied gemacht. Kann das sein?
>> 
>> Die Middleware/Frontend verhält sich normal. Der Fehler ist aber immer noch vorhanden. Er tritt auch auf wenn ich viele Channels gleichzeitig lade.
>> 
>> @Frank: Ich habe aggregation nur auf einigen Channels:
>> php /var/www/volkszaehler.org/bin/aggregate run <UUID> -m full -l day -l hour -l minute
>> 
>> Aber das Timeout ist immer noch da. Es ist sehr komisch, da im File "vendor/bin/ppm", das man startet, gleich am Anfang das Timeout mit "set_time_limit(0);" ausgesetzt wird. Es scheint aber nicht angenommen zu werden. Bei mir steht nach dem Start php[9423]: | max-execution-time | 30
>> 
>> Was ist euer Output von /usr/bin/php-cgi vendor/bin/ppm [...]?
>> 
>> Beste Grüße
>> Joe
>> 
>> 
>> 
>> 
>> 
>> 
>>> On 11/23/19 8:36 PM, Andreas Goetz wrote:
>>> Ich glaube dass Du bzgl. Pcntl in die falsche INI schaust. Cli und Cgi haben m.W. getrennte Dateien. Sorg bitte erstmal dafür, dass PPM wie vorgesehen mit cgi läuft, dann schauen wir nach weiteren Optionen.
>>> Viele Grüße, Andreas
>>>>> Am 23.11.2019 um 19:40 schrieb joekokker at epios.eu:
>>>> 
>>>> Hallo,
>>>> 
>>>> vielen Dank für die Hilfe. Ich habe momentan nicht auf allen Kanälen aggregation aktiviert. Zudem lade ich sehr viel Daten aus der Datenbank. Bei "normaler" Nutzung tritt der Fehler nicht auf.
>>>> 
>>>> Mit umbiegen, meinst du die "url" in der options.js Datei auf "" zu ändern, oder? Kann man dann das Frontend direkt nutzen? Irgendwie klappt das nicht bei mir.
>>>> 
>>>> ls -l /usr/bin/php*:
>>>> /usr/bin/php -> /etc/alternatives/php
>>>> /usr/bin/php7.3
>>>> /usr/bin/php-cgi -> /etc/alternatives/php-cgi
>>>> /usr/bin/php-cgi7.3
>>>> 
>>>> ls -l /etc/alternatives/php*
>>>> /etc/alternatives/php -> /usr/bin/php7.3
>>>> /etc/alternatives/php.1.gz -> /usr/share/man/man1/php7.3.1.gz
>>>> /etc/alternatives/php-cgi -> /usr/bin/php-cgi7.3
>>>> /etc/alternatives/php-cgi.1.gz -> /usr/share/man/man1/php-cgi7.3.1.gz
>>>> /etc/alternatives/php-cgi-bin -> /usr/lib/cgi-bin/php7.3
>>>> 
>>>> php -r 'phpinfo();' | grep -i api:
>>>> Server API => Command Line Interface
>>>> PHP API => 20180731
>>>> Zend Extension Build => API320180731,NTS
>>>> PHP Extension Build => API20180731,NTS
>>>> GSSAPI => Yes
>>>> DOM/XML API Version => 20031129
>>>> MHASH API Version => Emulated Support
>>>> Client API library version => mysqlnd 5.0.12-dev - 20150407 - $Id: 7cc7cc96e675f6d72e5cf0f267f48e167c2abb23 $
>>>> API Extensions => mysqli,pdo_mysql
>>>> Client API version => mysqlnd 5.0.12-dev - 20150407 - $Id: 7cc7cc96e675f6d72e5cf0f267f48e167c2abb23 $
>>>> Phar API version => 1.1.1
>>>> opcache.restrict_api => no value => no value
>>>> 
>>>> Ich habe versucht die binary "/usr/bin/php /home/volkszaehler/volkszaehler/vendor/bin/ppm [...]" mit /usr/bin/php-cgi zu ersetzten. Das wirft aber den Fehler, dass "PCNTL is not enabled in the PHP installation at /usr/bin/php-cgi7.3.". Es ist aber in der Module Liste. Das gleiche, wenn ich nur den "--cgi-path" ändere.
>>>> 
>>>> Glaubst du, dass es eine Einstellung in der php.ini ist? Oder ein Problem der Installation? Oder vielleicht ein Rechteproblem? Oder könnte es von der Datenbank kommen?
>>>> 
>>>> Beste Grüße
>>>> Joe
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On 11/23/19 6:40 PM, Andreas Goetz wrote:
>>>>> Hi,
>>>>> Was tun… also erstmal Fehlerquellen reduzieren- also direkt auf den PPM gehen und Apache mal weglassen. Wenn Du das Frontend nicht umbiegen willst tuts ja auch curl.
>>>>> Dann wundert mich der Timeout bei “langen Zeitreihen”. Was meinst Du damit- hast Du Aggregation aktiviert? Damit sollte es egtl. keine langsamen Abfragen geben, es sei denn Du lädst Unmengen an Daten.
>>>>> Dann ist Dein ppm cgi-path /usr/bin/php. Bist Du sicher, dass das ein php-cgi ist? Was sagt
>>>>>   php -r 'phpinfo();' | grep -i api
>>>>> Viele Grüße,
>>>>> Andreas
>>>>>>> On 23. Nov 2019, at 17:46, joekokker at epios.eu wrote:
>>>>>> 
>>>>>> Hallo,
>>>>>> 
>>>>>> Der Fehler tritt auf wenn ich große Zeitreihen lade. Im Frontend kommt der Fehler "Gateway Timeout", zwischendurch auch "Service Temporarily Unavailable".
>>>>>> 
>>>>>> Die Konfiguration ist ein apache vor dem ppm mit rewrite. Sobald ich noch einmal die gleiche Zeitspanne lade, zeigt das Frontend die Daten an. Ich denke, dass das durch das Cachen des SQL Servers dann schneller geht.
>>>>>> 
>>>>>> Hier ist der Output des ppm processes während des Fehlers.
>>>>>> https://pastebin.com/MDRjagFJ
>>>>>> 
>>>>>> Die php version ist: PHP 7.3.11-1~deb10u1 (cli) (built: Oct 26 2019 14:14:18) ( NTS )
>>>>>> 
>>>>>> Der Output von php -m ist: https://pastebin.com/eJPCggAf
>>>>>> Der Output von php -i ist: https://pastebin.com/eVRG5Us4
>>>>>> 
>>>>>> Wo könnte ich am besten ansetzten?
>>>>>> 
>>>>>> Beste Grüße
>>>>>> Joe
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 11/23/19 3:28 PM, Andreas Goetz wrote:
>>>>>>> Mir kommt das sehr seltsam vor. Der Prozess ist ja longrunning, soll also nicht nach 30sec gekillt werden. Ausserdem sollte ein gekillter Worker automatisch durch einen neuen ersetzt werden- und nicht erst auf einen Fehler laufen.
>>>>>>> Long Story short: ein paar mehr Infos zu PHP Version, cli/cgi, ini, log etc könnten vielleicht helfen.
>>>>>>> Viele Grüße, Andreas
>>>>>>>> Am 23.11.2019 um 13:44 schrieb joekokker at epios.eu:
>>>>>>>> 
>>>>>>>> Hallo,
>>>>>>>> 
>>>>>>>> ich ziehe gerade meinen Volkszaehler auf die neueste git (master) Version. Dieses Mal möchte ich die Middleware als Stand Alone Version als ppm laufen lassen.
>>>>>>>> 
>>>>>>>> Leider erhalte ich dabei einen Gateway Timeout, der im Log folgende Fehler wirft:
>>>>>>>> 
>>>>>>>> php[21101]: Maximum execution time of 30 seconds exceeded. Closing worker.
>>>>>>>> 
>>>>>>>> Es scheint, dass php einfach die Worker killt. Das Standard Timeout is 30 Sekunden. Mir kommt es komisch vor einfach in der php.ini das Timeout global hochzusetzten. Ich habe leider keine Einstellungsmöglichkeit in der htdocs/js/options.js File oder im /etc/middleware.json gefunden.
>>>>>>>> 
>>>>>>>> Wie habt ihr das gelöst? Ich wäre um einen Hinweis sehr dankbar.
>>>>>>>> 
>>>>>>>> Gibt es andere besondere Einstellungen, die noch nötig/sinnvoll sind beim Betrieb mit PPM?
>>>>>>>> 
>>>>>>>> Beste Grüße
>>>>>>>> Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20191124/b7123f83/attachment-0001.html>


More information about the volkszaehler-users mailing list