Temps d'exécution réel maximum d'un script avec set_time_limit(0)

bonjour

j'ai un script qui gere une mailinglist, hors si j'ai beaucoup de mail a envoyer, le script peut rester a tourner pendant plusieurs jours vu que je mets une tempo entre chaque mail ou chaque groupe de mail (afin d'éviter que certains mails reviennent noté comme spam :roll:)

vous avez compris le problème je pense, le script fini par planter au bout d'un temps X ...


est ce que cette limitation vient de PHP ?
j'ai pourtant changé le "max_execution_time" et "memory_limit"

d'apache ?
j'ai aussi modifié le timeout

MySQL ? (j'ouvre une connexion permanente)


des idées sur l'origine du problème ?
merci

Utilise un script en ligne de commande, qui tourne grâce à une tâche Cron, au lieu d'utiliser ton serveur web...

En effet, ton serveur web dispose d'un nombre limité de threads, et consomme plus de ressources qu'un simple script PHP exécuté en CLI.

Ensuite, tu peux utiliser les fonctions de file d'attente de ton serveur SMTP pour gérer l'envoi des emails.

Pear dispose d'une classe mail_queue pour gérer tout ça simplement et proprement...

la question était vraiment de connaitre la cause de ce plantage sans erreur : pourquoi le script se coupe aprés un temps X ?


je sais déjà comment contourner le problème, register_shutdown_function ou interface dynamique (flash) qui enverra les données une par une ou par groupe au script qui doit envoyer les mails, je pense utiliser cette soluce car elle permettra en plus d'avoir une idée précise de la progression.
je peux pas utiliser une CRON vu que le script doit pouvoir fonctionner sur un mutualisé.
concernant la file d'attente, c'est vraiment une bonne idée mais d'après ce que j'ai lu il faut la lancer a intervalle régulier et surtout elle est déjà prévu pour une classe d'envoi de mail qui n'est pas la mienne :?
j'aurais du penser avant a PEAR, j'ai pas encore ce réflexe :aie:


merci

Mea culpa pour le hors sujet :aie:

Pour ton plantage, il peut venir de beaucoup de choses :

- si tu es sur un mutualisé, il se peut que ton hébergeur ne prenne pas en compte certaines fonctions. Lorsque tu as modifié le temps d'exécution max, as-tu vu une différence ?

- ton hébergeur a aussi bien pu fixer au niveau de l'OS des limites de temps d'exécution pour les scripts (je ne suis pas expert en OS, mais on doit pouvoir indiquer à l'OS qui si tel processus fils d'apache dure plus de X minute, on le kill). Dans ce cas, les erreurs seront dans les logs de l'OS.

Au niveau de la gestion des erreurs, comment est configuré ton PHP ? les erreurs s'affichent-elles normalement ?

si tu affiches le résultat de ini_get("max_execution_time"), quelle est la valeur ?

Pour le timeout d'apache, attention : si la valeur est définie dans le fichier de conf de ton vhost, la modifier dans la configuration générale n'a aucun effet. Où as-tu modifié la valeur du time out ?

non non, ya pas de hors sujet :)

j'essaye chez moi et sur un 90plan de OVH, évidemment sur mon PC j'ai le contrôle total du serveur + config et même comme ca le script fini par planter aprés avoir tourner pendant X heures et tout ceci sans la moindre erreur dans les logs :calim2: comme s'il était arrivé a la fin ... j'aimerais bien comprendre pourquoi :aie:



le temps d'activité du script avant plantage n'est pas toujours la même, je pense pas que "max_execution_time" a rallongé la durée de vie mais pas évident de faire plein de tests vu que je dois laisser le script lancé pendant 8 a 15heures avant le plantage (silencieux) et surtout je dois réellement avoir une maillinglist/newsletter a envoyer pour ne pas avoir de problème avec les abonnés ...


ini_get("max_execution_time") == 0 mais de toute facon le set_time_limit(0) est censé outrepasser le "max_execution_time" dans tous les cas ?? (sauf safe mode)


j'ai activé dans le php.ini le log des erreurs :
error_reporting = E_ALL
log_errors = On
et sur OVH j'ai une classe qui capture toutes les erreurs pour les écrire dans un TXT


si la limitation est au niveau de l'OS alors il n'y a rien a faire ... mais je vois pas l'OS décider seul de tuer un processus :aie:


concernant la directive TimeOut de apache, j'ai fait le test dans le conf de mon serveur en la définissant a 0 (pas autorisé dans un .htaccess) mais vu qu'on a déja fait des chat en PHP + Socket en utilisant apache ceci ne devrait pas être la source du problème ?

Je vois mal également le système killer tout seul un processus, en tout cas sur ton PC.

Sinon, il se peut simplement que PHP sature et s'arrête de répondre tout seul (ce serait réellement étonnant, mais on ne sait jamais). Lorsque ton script tourne pendant plusieurs heures, as-tu un aperçu de sa conso RAM ou CPU ? L'idéal serait de trouver un indicateur clair de l'état du script au bout d'un certain temps : mémoire pleine, CPU à 100%, etc.

Après, une autre idée me vient à l'esprit (mais c'est chaud) :
- dans un premier temps, profiler ton script avec xdebug pour déterminer quelle est la partie du script exécutée en dernier

- dans un second, profiler directement PHP avec valgrind pour voir ce qu'il lui arrive.


Le risque, c'est d'avoir un log de profilage de plusieurs dizaines (centaines) de Mo, et qui serait impossible à ouvrir sans une machine de guerre...

L'autre problème, c'est que ton script va être beaucoup, mais alors beaucoup plus lent.


En tout cas, si ça fonctionne, on pourra voir exactement à quel moment ça plante (il y aura forcément une fonction qui sera exécutée une fois de moins que les autres).

j'ai pas pensé a vérifier l'utilisation mémoire que ce soit avec getrusage ou le gestionnaire :aie:

je connais ni xdebug ni valgrind, je viens de les trouver sur le net, je vais tester xdebug histoire de voir comment le faire fonctionner et surtout comment il doit fonctionner, il a l'air bien complet : http://www.xdebug.org/index.php


merci