[Kioob]

Bonjour,

pour de la prod, se tourner vers des outils type NewRelic peut également être intéressant (bien plus pratique qu'X-Debug pour le coup).

Pour ce qui est d'APC, sympa d'avoir remonté le problème. J'ai effectivement constaté des problèmes avec APC par le passé : par exemple un client y stockait de gros volumes de données (genre des tableaux ou objets, occupant 1Mo une fois sérialisés), ce qui plombait terriblement les performances.
Comme suggéré par janus57, xCache est plus «stable» à ce niveau, mais un peu plus complexe à tuner. Et oui, Zend OpCache est très prometteur, normalement disponible dans la prochaine Debian.

[janus57]

Bonjour,

Désolé pour l'incrust, mais vous avez essayé xCache (dernière MAJ le 2014-09-18 ) à la place de APC ou même "Zend Opcache" (nécessite une re-compilation de PHP il me semble) ?

EDIT :
Le remplaçant ou du moins la nouvelle version de APC se nomme APCu (APC User Cache)
Cf : http://pecl.php.net/package/APCu + https://packages.debian.org/source/jessie/php-apcu

Cordialement, janus57

[palumbus]

Merci à ceux qui nous ont répondu.
Comme d'hab et cela depuis quelques années, lorsque nous venons demander un conseil ici, c'est parce qu'on a un pb.
Et si on trouve ... bein on revient pour en faire profiter tout le monde...

Là, nous n'avons pas répondu de suite car on était un peu la tête dans le guidon à essayer de comprendre pourquoi nos ressources (CPU et load average) étaient bien parties pour se fracasser dans quelques semaines à ce rythme. Il fallait que l'on trouve car on était à une utilisation qu'on estimait à X4 par rapport à ce qu'on devait consommer : en gros on devait avoir 0.6 à 1 de load-average, et on était entre 4 et 6. En CPU on était à 60% mais on estimait qu'on devait être 15% ... et d'après nos sondes munin, en croissance exponentielle donc crash dans quelques semaines sur et certain.

On voyait bien que c'était les process php-fpm consommateurs de ressources. Comment savoir de quelle partie de code ça venait ?

1. d'abord on a debuggé grave !!! à la main, regarder ce que fait chaque script, vor si on a pas des boucles à la con, des trucs bizarres, etc...
2. On a installé Xdebug : en effet en prod c'est très consommateur de ressources. Des pistes mais on voit bien qu'il passe son temps à faire du MySQL... logique... mais c'est pas les process MySQL qui pédalent et bouffent des ressource, mais bel et bien les process php-fpm.
3. grosse période de doute sur le code.
MAIS
en bidouillant les conf de php-fpm, à chaque fois qu'on reloadait le service, le cpu re-tombait pendant quelques minutes... et ça remontait. inexorablement à un niveau qu'on ne voulait pas et qu'on savait illogique
4. la piste : on reloade et ça marche bien pendant quelques temps... bizarre !! la mémoire ??
5. on regarde de plus près APC, puisqu'on tourne avec APC.
... et ...
C'était LUI le coupable !
et on n'avait pas de sondes munin sur lui ... Grrrrr !
et on pensait que c'était bien codé .... Grrrrr !!!

A cause de notre gestion de cache de pages (on a beaucoup de pages sur le site, vraiment beaucoup) on preca beaucoup de trucs dans des petits fichiers php. On a pas mal de visites, et donc par seconde, beaucoup de ces fichiers sont chargés ... et à cause de certaines actions utilisateurs, certains de ces fichiers changent.
Mais APC, on ne sait pas bien pourquoi, conserve en mémoire des anciennes versions de ces fichiers ! Il ne les "garbage collecte" pas bien quand il a besoin de place, et fragmente sa mémoire
ET
au bout d'un moment il passe plus de temps à nettoyer son cache pour savoir ce qu'il va y mettre et comment l'y mettre !! C'est d'ailleurs assez hallucinant comme effet produit. Et on aurait pas trouvé avec Xdebug car c'est pas vraiment dans notre code que ça pédalait mais bien dans l'algo de nettoyage d'APC.

Là, nous avons tuné un peu mieux APC : on a retrouvé le niveau que l'on pense "normal" . COOOL !!! TOP !

Mais c'est encore instable. Instable ça veut dire que finalement il finit tout de même par remplir son espace mémoire, et parfois il nettoie bien pour continuer sans prendre de ressource, mais souvent il nettoie pas bien et il se remet à pédaler. Au lieu de quelques minutes, c'est au bout de quelques jours maintenant.
On va changer de système de cache opcode, APC n'est à priori plus maintenu, et son algo de gargbage collecting est vraiment codé avec les pieds.
Pas facile sur un système en prod sans arrêter le service.

Voilà notre expérience, si ça peut servir à quelqu'un !
comme quoi ça vient pas toujours de ce qu'on croit.
Olivier

[Nowwhat]

Munin pourrait aussi être un allié - pas sur des petites périodes, mais sur des heures, jours voir plus.
Voila ce que j'ai: http://www.test-domaine.fr/munin/pap...org/index.html
Il n'y pas de limite ce qu'on peut visualiser avec Munin.

Sache aussi que quasiment toutes les "programmes" comme 'nginx' ont leur outils de analyse pour des raisons de debug, etc.
Par contre, faut pas rêver: demander au "système" de débiter (un max) de l'info concernant ces activités, ça demande encore plus de 'power', ça va donc ralentir le serveur.

[nopnop]

Xdebug permet de profiler le code PHP et de voir ou passe le temps d’exécution. http://www.xdebug.org/docs/profiler

Par contre c'est pas spécialement utilisable sur un site en prod.... Mais pour analyser au cas par cas c'est nickel.

[palumbus]

Salut les gourous.
Nous aimerions optimiser un peu mieux le code de notre site.
En effet, tout n'a pas été écrit par nous, et on voudrait un peu mieux voir si il y a des goulets d'étranglements. On voit qu'on a parfois du CPU consommé, à priori par du php et pas par la bdd. On trouve cela bizarre et anticiper en trouvant les petites merdouilles pas optimisées.
Evidemment, on voudrait voir ça sur un site qui est en prod... donc ça veut dire qu'on ne veut pas que cela nuise aux perfs !
On est sur Debian, Nginx, php.

Vous nous conseilleriez quel outil ?
Par avance Merci
Olivier