Slow Query Back Office affichage Produits (11 minutes au lieu de qques secondes)

[elodie81]

Bonjour,

j'héberge pour un client un Prestashop depuis près d'un an sans aucun problème, il utilisait auparavant la version 1.7.2.4 avec 120 000 produits sans aucun problème.

Depuis qu'il tente de passer à la dernière version de Prestashop (1.7.6.5 ou 1.7.6.4), une page qui mettait quelques secondes à s'afficher avec l'ancienne version 1.7.2.4, prend maintenant exactement 10 minutes et 50 secondes avec ces deux nouvelles versions et ceci avec seulement 32 000 produits (table de 17M seulement). Il essaye depuis plus d'une semaine à effectuer cette installation/mise à jour.

Lorsque l'on se rend dans le Back Office pour afficher la liste des produits (Catalogue --> Produits), le chargement de la page met près de 11 minutes avec les 2 dernières versions au lieu de quelques secondes (avec la 1.7.2.4) en excluant tout cache. Ceci avec une installation Prestashop entièrement neuve et après une importation de ses produits via des fichiers CSV (des images).

J'ai identifié où se trouve ce temps de chargement extrêmement long : Une requête SQL est envoyée sur le serveur MySQL/MariaDB et celle-ci met exactement 10 minutes et 50 secondes à s'exécuter avant de redonner la main au serveur Web/PHP qui affiche ensuite correctement la page. (voir en pièce jointe la capture écran de la requête qui met 624 secondes (au moment de la capture écran) avant que la requête se termine.

D'après moi, il y a soit un problème dans la requête SQL ou la structure de ses tables (installation toute fraiche), ou autre chose que je n'ai pas encore identifié et dont j'accepterai volontiers votre aide.

Bien que je me dis que le problème n'est pas lié à ma configuration (Apache/PHP-FPM/MariaDB) car avec l'ancienne version Prestashop 1.7.2.4 la page s'affichait en quelques secondes (ce que le client me dit), je suis prête à entendre et à effectuer des vérifications mais sachez que j'héberge plusieurs centaines d'autres sites sans aucun problème. La configuration du serveur MariaDB n'a pas été modifiée depuis plus de 2 ans (hormis les mises à jour mais bien antérieures au problème de mon client qu'il rencontre depuis 1 semaine) et c'est une assez grosse machine (128 Go de RAM et 24 cores sans aucun problème sur celle-ci). La machine Apache/PHP n'a aucun problème non plus (aucune charge CPU, MEM ou IO anormale) lors de mes essais. Le réseau local entre ces deux machines est un réseau privé d'1Gbps.

Pour les tests, j'ai rehaussé les limitations systèmes afin d'avoir aucunes contraintes (pour rappel je suis la société d'hébergement) : 256 connections simultanées pour SQL et 1024M (et même 2048M) en memory_limit pour PHP (avec un usage de seulement 345M sur la machine PHP). La machine MariaDB (10.2.31) fonctionne parfaitement et est en très bonne santé (et délivre plusieurs centaines de sites parfaitement). Les 2 machines PHP/Web et SQL n'ont aucun problème de charge (CPU, Mem et IO tout est bon).

Avez-vous déjà rencontré ce genre de problème et auriez-vous une idée où je devrai chercher s'il vous plait ?

my.cnf de mon MariaDB 10.2.31 :

max_allowed_packet      = 16M
innodb_buffer_pool_size = 24G
innodb_buffer_pool_instances = 24
innodb_log_buffer_size  = 8M
innodb_file_per_table   = 1
innodb_open_files       = 1024
innodb_io_capacity      = 1024

max_allowed_packet      = 128M
thread_cache_size       = 128
sort_buffer_size        = 4M

Merci d'avance pour vos retours.

 

Edited May 7, 2020 by elodie81 (see edit history)

[elodie81]

Voilà la requete au complet qui prend près de 11 minutes à se terminer :

Quote

SELECT SQL_CALC_FOUND_ROWS p.`id_product` AS `id_product`, p.`reference` AS `reference`, sa.`price` AS `price`, p.`id_shop_default` AS `id_shop_default`, p.`is_virtual` AS `is_virtual`, pl.`name` AS `name`, pl.`link_rewrite` AS `link_rewrite`, sa.`active` AS `active`, shop.`name` AS `shopname`, image_shop.`id_image` AS `id_image`, cl.`name` AS `name_category`, 0 AS `price_final`, pd.`nb_downloadable` AS `nb_downloadable`, sav.`quantity` AS `sav_quantity`, IF(sav.`quantity`<=0, 1, 0) AS `badge_danger` FROM `ps_product` p LEFT JOIN `ps_product_lang` pl ON (pl.`id_product` = p.`id_product` AND pl.`id_lang` = 1 AND pl.`id_shop` = 1) LEFT JOIN `ps_stock_available` sav ON (sav.`id_product` = p.`id_product` AND sav.`id_product_attribute` = 0 AND sav.id_shop = 1 AND sav.id_shop_group = 0 ) JOIN `ps_product_shop` sa ON (p.`id_product` = sa.`id_product` AND sa.id_shop = 1) LEFT JOIN `ps_category_lang` cl ON (sa.`id_category_default` = cl.`id_category` AND cl.`id_lang` = 1 AND cl.id_shop = 1) LEFT JOIN `ps_category` c ON (c.`id_category` = cl.`id_category`) LEFT JOIN `ps_shop` shop ON (shop.id_shop = 1) LEFT JOIN `ps_image_shop` image_shop ON (image_shop.`id_product` = p.`id_product` AND image_shop.`cover` = 1 AND image_shop.id_shop = 1) LEFT JOIN `ps_image` i ON (i.`id_image` = image_shop.`id_image`) LEFT JOIN `ps_product_download` pd ON (pd.`id_product` = p.`id_product`) WHERE (1 AND state = 1) ORDER BY `id_product` desc LIMIT 0, 300

 

[doekia]

Bug natif pour les boutique ayant beaucoup de product_download

ALTER TABLE `ps_product_download`
ADD INDEX `id_product` (`id_product`);

 

[elodie81]

Exactement, merci encore @doekia ! C'est amusant de lancer une bouteille à la mer et de recevoir de l'aide de la part d'un ami sur son Skype