Discussion :

[Trebly]

Bonsoir,

A la suite d'un évènement inconnu (accident en édition de paramètres - improbable, attaque - comment ? + pas de virus identifié) :

- Chaque nouvelle requête http (quelconque) lance un process qui utilise 100% (99%) d'un cœur du processeur (une requête tourne dans un cœur, une nouvelle occupe le suivant... jusqu'à épuisement des ressources).

Avec un processeur 4 cœurs (qui peut donc traiter 4 requêtes simultanément) la quatrième bloque la machine totalement (sous windows XP sp3 - plus de gestionnaire de tâches).

Autre phénomène corrélé : croissance progressive du fichier d'échange jusqu'au maximum allouable (sans dépassement de limite de mémoire vive, reste limitée à l'allocation php+Apache noyau).

Le lancement du process intervient par une requête connue (après arrêt réseau sinon on ne sait pas contrôler) mais Apache utilisant 100% du cœur sur ? (tâche inconnue) ne répond pas (sauf exception - non dépassement exceptionnel de limite de temps - après x200 temps normal a produit une page...), mais le process ne s'arrête pas après le timeout de php ou la fin d'exécution du php. Apache s'occupe de ?

La fonction serveur est donc bloquée, la machine aussi (en fonction des requêtes > 3) si l'on a lancé Apache.

Quelqu'un a-t-il un plan de recherche-localisation d'incident ou une idée du problème ?

Merci d'avance.

Trebly

[Trebly]

Bonjour,

Le problème a été résolu sans avoir pu cerner toutes les questions.
Les temps observés étaient, en fait, de vrais temps de calcul (analyse par xDEBUG profiler).

En allongeant le temps maximum d'exécution dans des limites considérables ( 1200s.) la tâche principale finissait par s'exécuter en totalité.

Évidemment dans un environnement de développement, les logs étaient en mode "debug" et des traces étaient exécutées systématiquement, mais si l'augmentation des temps atteignait couramment 100% voire 200%, jamais 40.000% (400x, 1/4 d'heure plein pot de 3 ou 4 cœurs, au lieu de 2secondes sur un seul coeur pour avoir une page en mode production).

L'annulation progressive des logs et traces (et les changement des noms de fichiers de trace permanente, log Apache par exemple) n'ont eu aucune influence pendant longtemps. Puis d'un seul coup après un redémarrage de machine, tous les logs et traces de contrôle ayant été annulés, les temps sont redevenus normaux.

Si vous avez une expérience comparable merci de le signaler ici. On arrivera peut-être à comprendre tout (et donc l'éviter ou soigner à coup sur).

Ceci étant, le constat de cette brutale remise en ordre est quelque chose d'important pour la stratégie de résolution de tels problèmes.

Merci aux lecteurs pour vos réponses et commentaires à venir.

Trebly