Ajout Modification produit : NGINX Erreur 502 child die signal 11

[hugolin69]

Bonjour,

Je me bat depuis des semaines avec une 1.7.6.2.

J'ai désactivé la mise en cache, et j'ai seulement l'option "Never recompile" qui est active.

J'ai très peu de modules non natifs. J'ai plus de 300 articles.

Au bout d'un temps plus ou moins long (minutes/heures/jours), après un effacement total du cache et des compilations smarty, je rencontre des soucis quand je veux ajouter/modifier un produit. Soit le serveur Apache / NGINX renvoi un code 200 sur la page, avec un "Failed" ensuite, soit c'est des chargements ajax des sous-éléments (notamment prix spécifiques de la page produit) qui reviennent en 502.

Je n'arrive pas à débugger, je n'ai aucune information qui remonte nulle part. La seule information que j'ai c'est un "child die signal 11" sur NGINX, qui montre un problème de saturation de mémoire. Le problème, c'est que dès que je désactive un module (n'importe lequel), ou active mode Debug, j'ai l'impression qu'il vide une partie du cache Smarty ou autre, et ca résout à peu prêt le problème, sans que je puisse débugger.

La seule information intéressante que j'ai pu trouver, en activant le debug par le fichier PHP, en passant _PS_MODE_DEV_ à true, c'est que je vois que la valeur Symfony initialization explose à 1700ms voir plus au lieu de 100 à 200. Si je vide le cache dans Performance, OU désactive/active n'importe quel module, il revient à la normale. Je rappelle que le cache dans Performance est désactivé.

Je penche pour une génération excessive de cache smarty, mais je n'arrive pas à identifier.

Est ce que quelqu'un aurait rencontré ce problème ? ou pourrait me donner une piste pour débugger ?

Résolu : En dehors du fait qu'un module posait souci, il remonte que le fait de conserver toutes les taxes et règles de taxes par défaut lance un stress des tables taxes et group_taxes pour rien lors de l'édition de produits.

 

EDIT : Le problème est toujours là, même si le module que je pensais responsable a été totalement supprimé.

 

Edited May 6, 2020 by hugolin69 (see edit history)

[doekia]

Signal 11 c'est "Segmentation Fault" donc rien a voir avec PrestaShop.

Soit le "child" est un process nginx et il s'agit d'un bug de ta version nginx, soit le "child" est un php et pareil pour php

Segmentation fault signifie qu'un process système a tenté de lire une adresse mémoire qui ne lui est pas attribué.

Voir avec ton hébergeur, lui seul peut trouver une solution

[hugolin69]

Merci pour ta réponse.

J'ai déjà vu avec l'hébergeur, qui est plutot disponible et compétent, et qui me soutient que c'est généralement, quand on a une boucle infinie ou similaire, qui arrive sur ce résultat sur la mémoire, qui tente d'accéder à plus de mémoire et qui n'y arrive pas.

J'ai plusieurs PS sur cet hébergeur, et première fois que j'ai le problème.

Mon sentiment, est que pour une raison inconnue, Prestashop met en cache smarty ou autres une sorte de boucle, ou quelque chose de lourd par erreur. Quand tout va bien, Symfony a une initialisation de 120ms et monte à 4000 quand il y a un souci, donc le problème ne semble pas coté hébergeur, mais je n'arrive pas à trouver une solution pour débugger, car l'erreur semble venir de quelque chose en cache (même si je reste sans le cache PS), donc cache smarty, et j'ai beau faire des modifications sur les modules, il utilise les versions en cache, et si je vide le cache, je n'arrive pas à reproduire le bug, et dois attendre que ca revienne.

Juste un cauchemar.

Merci pour ta réponse.

J'ai déjà vu avec l'hébergeur, qui est plutot disponible et compétent, et qui me soutient que c'est généralement, quand on a une boucle infinie ou similaire, qui arrive sur ce résultat sur la mémoire, qui tente d'accéder à plus de mémoire et qui n'y arrive pas.

J'ai plusieurs PS sur cet hébergeur, et première fois que j'ai le problème.

Mon sentiment, est que pour une raison inconnue, Prestashop met en cache smarty ou autres une sorte de boucle, ou quelque chose de lourd par erreur. Quand tout va bien, Symfony a une initialisation de 120ms et monte à 4000 quand il y a un souci, donc le problème ne semble pas coté hébergeur, mais je n'arrive pas à trouver une solution pour débugger, car l'erreur semble venir de quelque chose en cache (même si je reste sans le cache PS), donc cache smarty, et j'ai beau faire des modifications sur les modules, il utilise les versions en cache, et si je vide le cache, je n'arrive pas à reproduire le bug, et dois attendre que ca revienne.

Juste un cauchemar.

[doekia]

Aucun boucle infini ne provoque de signal 11.

Signal 11 n'est pas une saturation mémoire .

Mais si tu préfères chercher dans des directions autre, libre a toi

[hugolin69]

Je te remercie, je me suis peut être mal exprimé ou mal compris l'explication de l'hébergeur.

Mais malgré tout, je vois que quand le problème est là, j'ai une init de Symfny de 4sec, ce qui semble montrer un problème de mon coté, avant d'être de leur coté non ?

[Janett]

Combien avez vous de catégorie ? Il y a parfois un soucis de circular reference : https://github.com/PrestaShop/PrestaShop/issues/13698

Faudrait vérifier dans votre base de données, dans les tables ps_category si vous n’avez pas une ou plusieurs lignes qui provoquent une circular reference.
 

Une autre possibilité pourrait être un soucis avec les déclinaisons ou les caractéristiques produit.

[hugolin69]

Merci Janett,

J'ai regardé l'issue dont tu parles, et qui pourrait s'en approcher.

Par contre, je n'ai que 23 catégories, sans grand nombre de sous niveaux, uniquement un sous niveau (Root Categorie "1" / Home "2" / Categories / Sub Categories)

Sur les 23 catégories, je n'ai pas de  lignes doublones type mélange père/fils dans la base.

J'ai 300 produits, qui ont pour 20% des déclinaisons, pas énorme, 3 ou 4 déclinaisons par produit quand il y en a.

Pour les caractéristiques, je l'utile  un peu plus, et j'en ai quelques unes. quand tu dis qu'une autre possibilité pourrait venir des déclinaisons/caractéristiques, tu penses à quoi ?

[Janett]

Ce doit être autre chose alors...

Pour les déclinaisons / caractéristiques, je pensais à des incohérences en base de données éventuellement.

Sinon vous avez des modules qui peuvent avoir un impact sur cette page ?

[doekia]

Le moteur est en feu mais vous contrôlez la pression des pneus... c'est quoi la logique?
https://serverfault.com/questions/410725/php-fpm-and-continuos-exited-on-signal-11

https://bugs.php.net/bug.php?id=75573

[hugolin69]

Un petit retour.

Première chose, je remarque en activant le Profiling sur le BO, que les tables tax_rules_group (60) et tax_rule (58) sont sujettes à plusieurs requêtes (Table stress).

J'avais toutes les taxes et toutes les règles de taxe par défaut encore dans la boutique. Je les ai toutes supprimées, sauf les TVA Françaises, ainsi que les règles de taxe, et ces deux tables passent nickel le table stress (dix fois moins de requêtes)

Je pense que ceci avait déjà pour objet de bouffer pas mal de ressources.

Ensuite, j'ai un module wkcombinationcustomize (Combinations activate/desativate). Bien que je le soupçonne depuis le début, je n'arrivai pas à le mettre en cause non plus, et je ne pouvais pas me permettre de le désactiver plusieurs jours. C'est un module qui stocke dans une table nouvelle la liste des déclinaisons désactivées avec une colonne id_produit et une colonne id_declinaison. Le souci, c'est que pour lister les déclinaisons autorisées, le dev avais utilisé un filtre "NOT IN (SELECT id FROM table_exclusion)" dans les requêtes natives de PS. Même si je n'ai que 40 exclusions, le fait de ne pas ajoute rle filtre id'_produit dans la requête du NOT IN met un filtre de 40 valeurs, et je pense que ceci, ajouté à 3 ou 4 executions à divers endroits, a tendance à également alourdir la facture des ressources. J'ai ajouté un "WHERE id_product = pa.id_product", qui ne peut pas faire de mal, et qui devrait être là.

A suivre, mais l'ajout de ce filtre, et la suppression des taxes et règles de taxes inutiles semble alléger la bête, et je n'ai pas encore observé la moindre 502.

En résumé, pensez à supprimer vos taxes et règles de taxe non utilisées, (je le fais toujours normalement) et si on voit de plus en plus de modules sur le store module, je regrette de voir que très peu de modules sont développés dans les règles de l'art sont rarement débuggé en profondeur, sur plusieurs cas de figures. (Charge, Multiboutique, Multi-devise....)

 

[hugolin69]

Fausse joie.

Le problème est toujours là, et NGINX me remonte toujours l'erreur suivante :

upstream prematurely closed connection while reading upstream
upstream prematurely closed connection while reading response header from upstream

Je suis entrain de devenir fou.

J'y ai passé pas mal d'heures.

Je viens de migrer tout le site vers la toute dernière version 1.7.5.6.

J'ai l'impression que le problème se créé quand j'ajoute un produit, et que ensuite je tente d'aller éditer un produit, mais je n'arrive pas à le reproduire de façon claire.

J'ai tenté les valeurs suivantes dans le HTACCESS, qui prennent bien effet, + realpath_cache_size 5M mais rien n'y fait.

J'ai même tenté de monter à 1500Mo de mémoire.

php_value max_input_vars 40000
php_value memory_limit 1048M
php_value max_input_time 300

Doekia, je ne comprends pas ton dernier post, selon toi, il faudrait que je cherche de quel coté ? L'hébergeur ne semble rien trouver.

Seule spécificité, j'ai 600 références, mais ce n'est pas si énorme. J'ai une petite liste de caractéristiques, mais pas si énorme. J'ai tenté de désactivé les caractéristiques, idem. J'ai tenté de désactivé tous les modules idem. Mon souci, est que je ne sais pas par où je peux tenter de commencer le debug, et dérouler la pelotte.