[Résolu] Erreur MySQL : Site très lent voire erreur 503 pendant plusieurs heures
Ce sujet est résolu. Voici une description du problème et de la solution.
Problème : Le client a signalé des problèmes de lenteur et des erreurs 503 sur son site WordPress lors de l'utilisation de WPML sur un hébergement partagé. Le problème disparaissait lors de la désactivation de WPML et réapparaissait lors de sa réactivation. La base de données était très volumineuse pour un hébergement partagé. Solution : Nous avons suggéré plusieurs étapes pour améliorer les performances : 1. Mise à jour de WordPress et de WPML ainsi que tous les add-ons de WPML. 2. Désactivation de WPML Media si la traduction d'images différentes par langue n'est pas nécessaire. 3. Changement du moteur de stockage des tables de la base de données de MyISAM à innoDB pour améliorer les performances. Voici les requêtes SQL pour effectuer ce changement :
SET sql_mode = '';
ALTER TABLE wpbtk_posts ENGINE = INNODB;
ALTER TABLE wpbtk_postmeta ENGINE = INNODB;
ALTER TABLE wpbtk_icl_strings ENGINE = INNODB;
ALTER TABLE wpbtk_icl_string_packages ENGINE = INNODB;
ALTER TABLE wpbtk_icl_string_translations ENGINE = INNODB;
ALTER TABLE wpbtk_icl_translate ENGINE = INNODB;
ALTER TABLE wpbtk_icl_translate_job ENGINE = INNODB;
ALTER TABLE wpbtk_icl_translations ENGINE = INNODB;
ALTER TABLE wpbtk_icl_translation_batches ENGINE = INNODB;
ALTER TABLE wpbtk_icl_translation_status ENGINE = INNODB;
ALTER TABLE wpbtk_icl_background_task ENGINE = INNODB;
ALTER TABLE wpbtk_icl_flags ENGINE = INNODB;
ALTER TABLE wpbtk_icl_languages ENGINE = INNODB;
ALTER TABLE wpbtk_icl_languages_translations ENGINE = INNODB;
ALTER TABLE wpbtk_icl_locale_map ENGINE = INNODB;
ALTER TABLE wpbtk_icl_message_status ENGINE = INNODB;
ALTER TABLE wpbtk_icl_mo_files_domains ENGINE = INNODB;
ALTER TABLE wpbtk_icl_node ENGINE = INNODB;
ALTER TABLE wpbtk_icl_reminders ENGINE = INNODB;
ALTER TABLE wpbtk_icl_string_batches ENGINE = INNODB;
Ces modifications ont permis de réduire significativement le temps de chargement des pages. Nous recommandons de changer toutes les tables en innoDB pour de meilleurs résultats.
Si vous rencontrez toujours des problèmes après avoir suivi ces étapes, ou si cette solution ne semble pas pertinente à votre cas, nous vous invitons à ouvrir un nouveau ticket de support. Nous vous recommandons également de consulter la page des problèmes connus, de vérifier la version de la correction permanente et de vous assurer que vous avez installé les dernières versions des thèmes et plugins. Pour toute assistance supplémentaire, veuillez contacter notre forum de support.
Il s'agit du forum d'assistance technique de WPML, le plug-in multilingue pour WordPress.
Il est accessible à tous, toutefois seuls les clients de WPML peuvent y publier leurs messages. L'équipe du WPML répond sur le forum 6 jours par semaine, 22 heures par jour.
Suite à ce problème du vendredi 2 février sur mon site maisondudrone.com, les erreurs sont réapparues de temps en temps, mais pas tous les jours (parfois rien pendant 7-10 jours) et généralement uniquement quelques secondes ou quelques minutes.
Cependant, il est réapparu 2 longues fois pendant plusieurs heures :
- le vendredi 29 mars pendant 5h30 environ (de 17h à 22h30 heure française environ)
- hier samedi 6 avril pendant 8 heures (de 15h à 23h heure française environ, avec 6343 occurrences du message d’erreur MySQL)
A chaque fois, les requêtes pour charger une page sont très lentes (environ 20 à 30s) ou finissent en erreur 503.
J’ai pu constater que le problème disparaît totalement si je désactive WPML (extension WPML Multilingual CMS) et réapparait lorsque je la réactive.
J’ai utilisé la fonction WP_ALLOW_REPAIR pour effectuer une réparation + optimisation de la base mais cela n’a rien changé.
Bizarrement, le problème s’est jusqu’à présent produit uniquement les vendredi et samedi soir, de l’après-midi à 23h environ. L’activité sur mon site n’est pas inhabituellement haute à ces moments-là, ce qui me pousse à m'interroger : étant donné que nous sommes sur un hébergement mutualisé, est-ce que le problème pourrait être lié à une activité globale sur le serveur soit plus élevée pendant ces périodes ? J’ai posé la question à mon hébergeur (o2switch) mais ils n’ont pas su me répondre.
Vous aviez précédemment suggéré une migration de notre site vers vos serveurs Cloudways pour s'assurer que les problèmes rencontrés soient liés au serveur. Si vous n’avez pas d’autre alternative, je suis prêt à faire ce qu’il faut pour comprendre les origines de ce problème et trouver une solution, car il a un gros impact sur mon activité.
Vous pouvez télécharger le debug.log complet au lien suivant : lien caché
Les langues: Anglais (English )Français (Français )
Fuseau horaire: America/Lima (GMT-05:00)
Bonjour,
Je suis désolé d'apprendre que le problème est de retour. WordPress 6.5 a apporté pas mal de changements et il faut utiliser les dernières versions de WPML et String Translation. Je vois que c'est votre cas ici.
Question: le problème est-il survenu avant la mise à jour de WPML et String Translation ou après?
En regardant les logs, je vois que cela concerne _wcml_average_rating qui sont les reviews WooCommerce. Le problème semble se passer sur les templates de votre thème ou les notes/review de produit sont affichées (stars) comme "taxonomy-product-tag.php" ou "single-product.php"
Dans "WooCommerce > WooCommerce Multilingual > Paramètres > Product reviews" est-ce que vous avez l'option "By default, show reviews in all languages" activée?
1) Installez ce plugin sur votre site: Cloudways WordPress Migrator (https://wordpress.org/plugins/bv-cloudways-automated-migration/)
2) Après l'avoir activé, vous serez redirigé vers le formulaire de migration
3) Remplissez-le avec ces informations :
- E-mail (Votre propre e-mail, car vous serez informé de la progression de la migration.)
- URL du site de destination : lien caché
- Adresse IP publique du serveur : 198.199.78.128
- Nom de la base de données: eynqjjyvdn
- Utilisateur de la base de données : eynqjjyvdn
- Mot de passe de la base de données : N2ysrz6rC3
- Utilisateur SFTP : user-474875
- Mot de passe SFTP : User-474875
4) Acceptez les conditions d'utilisation et cliquez sur "Migrer"
Plus d'information: lien caché
5) Vous recevrez un e-mail au début et un à la fin de la migration.
6) Dites moi quand la migration est prête et je vérifierai le problème sur ce site de test.
La copie de votre site sera en ligne, mais les moteurs de recherche ne l'indexeront pas (la copie) afin que vous n'ayez pas de soucis de contenu dupliqué.
Les deux dernières grosses occurrences qui ont duré plusieurs heures sont survenues après les dernières mises à jour de WPML et String Translation.
L’option "By default, show reviews in all languages » est bien cochée dans les paramètres WooCommerce Multilingual.
J'ai commencé la migration vers Cloudways, cependant j'obtiens le message d'erreur en pièce jointe. Est-ce que j'ai bien coché/rempli tous les champs ? Ceux-ci sont légèrement différents de ceux que vous avez mentionné (pas de champ pour le mot de passe base de données et quelques cases à cocher en plus).
Les langues: Anglais (English )Français (Français )
Fuseau horaire: America/Lima (GMT-05:00)
Bonjour,
Essayons encore une fois. Je viens d'éliminer le site et d'en créer un autre identique:
- URL du site de destination : lien caché
- Adresse IP publique du serveur : 198.199.78.128
- Nom de la base de données: jsvxveymak
- Utilisateur de la base de données : jsvxveymak
- Mot de passe de la base de données : XFqX8wv6bN
- Utilisateur SFTP : user-474875
- Mot de passe SFTP : User-474875
Je rencontre à nouveau le même problème (erreur "Your source site lien caché is redirecting to .").
Dois-je bien choisir "Cloudways Flexible" ? (j'ai quand même essayé "Cloudways Autonomous", même résultat)
Il n'y a pas de champ "Mot de passe de la base de données", est-ce normal ?
Ai-je bien tout coché pour "HTTP Auth enabled?" et "Source site information" ?
Les langues: Anglais (English )Français (Français )
Fuseau horaire: America/Lima (GMT-05:00)
Bonjour,
Oui, Cloudways a modifié son plugin et demande moins d'informations. Essayons alors une autre approche.
Pour cela, vous devez installer temporairement l'extension "Duplicator". Elle vous permettra de faire une copie complète de votre site et de son contenu.
J'ai activé un champ privé pour votre prochaine réponse pour partager les fichiers (package + installer).
- Vous devez exclure /wp-content/uploads et /wp-content/cache pour réduire le poids de la copie (voir capture)
- Une fois le package est prêt, si les fichiers sont trop lourds, vous pouvez partager un lien Google Drive, Dropbox, WeTransfer ou autre.
Les langues: Anglais (English )Français (Français )
Fuseau horaire: America/Lima (GMT-05:00)
Bonjour Adrien,
J'ai essayé d'installer la copie 3 fois aujourd'hui sans succès. À chaque fois l'installation de la base de données prend énormément de temps et termine par une erreur timeout.
Pensez-vous qu'il serait possible d'accéder au site afin d'essayer de prendre une copie avec:
- Cloudways Migration
- Duplicator PRO
- All In One Migration
Pouvez-vous également essayer la solution #1 de cet article: lien caché
Passez même de 300 à 600
Merci pour votre réponse et pour vos suggestions. Effectivement, ma base de données est très volumineuse, ce qui pose problème. Je ne peux même pas restaurer normalement un backup de mon site avec BlogVault, cela nécessiterait de modifier un paramètre de timeout que je ne peux pas ajuster sur mon hébergement mutualisé.
Je viens de mettre en œuvre la solution recommandée dans l'article de Kinsta en augmentant le paramètre à 600. Je vais surveiller attentivement le fichier debug.log pour voir si cela résout le problème.
Concernant l'accès au site, je préfère éviter de donner un accès administratif externe. Cela dit, je peux essayer d'utiliser All In One Migration si le problème persiste.
Les langues: Anglais (English )Français (Français )
Fuseau horaire: America/Lima (GMT-05:00)
Bonjour Adrien,
UN membre de l'équipe de deuxième niveau va essayer de reproduire le problème en local avec la copie de votre site mais nous aurions besoin de connaitre les valeurs suivantes afin d'avoir exactement la même configuration que votre serveur:
- max_allowed_packet
(c'est la valeur que je vous avais demandé d'augmenter dans le premier ticket mais que votre hosting refuse de toucher - ils peuvent au moins vous donner la valeur)
- PHP timeout
"Le max_allowed_packet est à 1G coté serveur et la valeur du timeout php est à définir de votre coté depuis l'outil sélectionner une version php de votre cpanel."
Pour le PHP timeout, il y a plusieurs valeurs, je vous met une capture d'écran en pièce jointe.
Sinon, depuis l'ajout de la ligne « $this->query("set session wait_timeout=600 », je n'ai pas eu l'erreur habituelle dans debug.log, mais celle-ci à la place :
[14-Apr-2024 21:51:10 UTC] WordPress database error MySQL server has gone away for query set session wait_timeout=600 made by require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('/themes/flatsome/woocommerce/single-product.php'), get_footer, locate_template, load_template, require_once('/themes/flatsome/footer.php'), do_action('flatsome_footer'), WP_Hook->do_action, WP_Hook->apply_filters, flatsome_page_footer, get_template_part, locate_template, load_template, require('/themes/flatsome/template-parts/footer/footer.php'), dynamic_sidebar, WP_Widget->display_callback, WC_Widget_Products->widget, WC_Widget_Products->get_products, WP_Query->__construct, WP_Query->query, WP_Query->get_posts
Les langues: Anglais (English )Français (Français )
Fuseau horaire: America/Lima (GMT-05:00)
Bonjour,
Supprimez cette query pour le moment.
$this->query("set session wait_timeout=600");
Le ticket a été remonté à un niveau supérieur pour recréer les mêmes conditions et essayer de reproduire le problème. Notez que ce ne sera pas exactement la même chose car ce n'est pas un serveur mutualisé et il y a de forte chances que le problème soit lié au serveur.
