Bonjour tout le monde,
Nous rencontrons le problème actuel :
Tous les jours entre 9h et 11h, tous nos sites en multisite sont inatteignables.
Ils utilisent la webcloud database commune.
Pour remédier au problème, il faut aller sur la config de la webcloud database, modifier un paramètre (n'importe lequel) : le serveur de la webcloud database est alors redémarré et tout rentre dans l'ordre.
OVH nous dit qu'il n'y a pas d'incident sur notre infrastructure , que nous devons faire appel à un prestataire externe.
Qui peut contrôler notre config ?
Pourquoi le problème est résolu quand on redémarre le serveur de la webcloud database ?
Où se situe le problème dans la cette webcloud database, sachant que nous avons aucun dépassement mémoire significatif ?
Pourquoi les problème surgissent entre 9h et 11h chaque matin, sachant que nous avons aucune tâche CRON qui tourne à ce moment là ?
A noter que tous les sites sur le multisite sont des Wordpress : serait-ce les mises à jour des plugins qui tourneraient entre 9h et 11h ?
Merci pour vos retours.
Tous les jours entre 9h et 11h, tous nos sites en multisite sont inatteignables.
Ils utilisent la Tous les jours entre 9h et 11h, tous nos sites en multisite sont inatteignables.
Ils utilisent la webcloud database commune.
Bonjour @EvelyneL2
Je n'ai pas très bien compris quel est l'intérêt de prendre une **_webcloud database_** plutôt que la base de données fournie avec l'hébergement mutualisé.
Bonjour,
Merci pour votre remarque.
Nous recherchons le pourquoi du pic de connexions qui sature la mémoire entre 9h et 11h chaque matin :
https://tinyurl.com/23o56mdf https://tinyurl.com/23o56mdf
Où retrouver les IP de ces connexion dans les logs ? WEB ? OUT ? ERROR ?
Nous n'avons pas de tâches CRON qui s'attaque à nos bases entre 9h et 11h.
Comment faire pour retrouver l'origine de ces pics de connexion ?
Merci pour vos idées.
Cordialement,
Bonjour @EvelyneL2
Quel domaine ?
Quel cms ?
Dans le cas de WordPress, pouvez-vous nous donner la liste des plugins utilisés ?
Bonjour,
Merci pour votre retour.
Nous avons environ 80 sites installés en wordpress 6.5.4
Php 7.4
VOici un site parmi ces 80 :
https://loiret.1mouvement.orgmouvement.org
Voici la liste des plugins installés :
https://tinyurl.com/2825eelo
La base est sur le webcloud database.
Voici la config de celle-ci :
https://tinyurl.com/23nd3lst
Ce matin, le blocage a recommencé à la même heure.
On enregistre à nouveau la config (en modifiant juste une info, exemple : le max_alowed_packed de 1M à 2M. Mais ce n'est particulièrement à cause de cette valeur, car le test a été fait depuis plusieurs jours -redémarrage du serveur qui remet tout en ordre-) : et la problème disparait : les connexions sont à nouveau possibles pour le site.
Le "Métriques" de la webcloud database retombe :
https://tinyurl.com/2cawx7yq
Merci pour votre retour.
Cordialement,
Bonjour @EvelyneL2
Êtes-vous sur un hébergement mutualisé et si oui lequel, un VPS, un dédié ?
Svp, la liste des plugins utilisés ?
Écrire ci-dessous la liste et non pas une image photo.
Êtes-vous sur un hébergement mutualisé
54.36.91.62: cluster027.hosting.ovh.net
90 domaines inclus dans le certificat SSL
Bonjour,
Merci pour votre message.
Voici la liste des extensions :
Advanced Access Manager
CAOS
Child Theme Configurator
Contact Form 7
Disable Gutenberg
Elementor
Essential Addons for Elementor
FileBird Lite
MapPress Google Maps and Leaflet Maps
MetaSlider
Ocean Extra
Print, PDF & Email by PrintFriendly
ReCaptcha v2 for Contact Form 7
Sucuri Security - Auditing, Malware Scanner and Hardening
UpdraftPlus - Sauvegarde/Restauration
Vision
Wordfence Security
WP Statistics
WP-Optimize - Nettoyer, compresser, mettre en cache.
WPS Hide Login
Yoast Duplicate Post
Yoast SEO
Bonjour,
Cette nuit, la surcharge mémoire est apparue vers 2h30 :
https://tinyurl.com/28easzzo
Est-ce un déclenchement d'extension ? Nous avons plus de 80 sites, donc il faut tout vérifier 1 par 1.
Est-ce une utilisation frauduleuse de notre machine : je suis en train de scruter les logs web de cette nuit.
Le max_alowed_packed était à 1M dans la config de la webcloud database et le tmpdir était sur le
dev/shm : Je l'ai repassé vers 9 h ce matin sur le /tmp
Bonjour @EvelyneL2
Vous devriez commencer par désactiver tous les plugins qui ne sont pas strictement nécessaires.
Je dis bien tous les plugins qui ne sont pas nécessaires
Bonjour,
Nous avons commencé à désactiver certains plugins : sans résultat pour le moment.
Pour désactiver en masse (nous avons plus de 80 sites), nous renommons via commande ssh les répertoires des plugins à désactiver.
Questions :
- Il y a t-il un autre moyen ? (via les tables wordpress : wp_options ?). Désoé, si c'est une question WP
- Avec les logs, nous devrions voir la surcharge au niveau mémoire ?
Pour info, encore un blocage ce matin. Nous avons donc modifié la config du serveur de la webcloud database et les problème d'accès ont disparu.
Question :
- par ssh, est-il possible d'envoyer une commande cron de redémarrage systématique de ce serveur (je suppose que non vu que nous sommes en mutualisé) ?
Merci pour vos retours.
Cordialement,
- Il y a t-il un autre moyen ?
Bonjour @EvelyneL2
Avec **_FILEZILLA_** en mode **_SSL_** tout simplement.
Voir dans mon guide le paragraphe :
**W - PLUGINS en erreur, dossier PLUGINS**
https://www.wordetweb.com/word-et-web/WORDPRESS-guide-installation-de-WordPress-premier-domaine-chez-OVH-FR.htm#_W_-_PLUGINS
**__________________________________________________________________________________**
Voici un petit guide que j'ai écrit et qui pourrait vous apporter des éclaircissements pour **une Installation complète et propre de votre Site**.
**************************************************************************************************
* **Guide - Comprendre la Relation Domaine > Zone DNS > Hébergement > Dossier du site** *
**************************************************************************************************
Voir --> **https://wordetweb.com/word-et-web/WORDPRESS-guide-installation-de-WordPress-premier-domaine-chez-OVH-FR.htm CMS - WordPress - Guide Installation chez OVH**
Contrôler votre situation en suivant **attentivement** les paragraphes : **A** à **J**
_N'hésitez pas à me faire un retour : positif ou négatif._
_C'est comme cela que je peaufine mon Guide._
_Si ce guide vous a bien aidé, n'hésitez pas à cliquer sur le bouton « j'aime »_
**__________________________________________________________________________________**
Penser à faire une sauvegarde **Hébergement et Base de données** sur votre PC une fois par mois.
Dans mon guide : **https://wordetweb.com/word-et-web/WORDPRESS-guide-installation-de-WordPress-premier-domaine-chez-OVH-FR.htm#_Ua_-_Sauvegarde Ua - Sauvegarde complète de votre site sur votre PC**
Bonjour,
Merci, c'est exactement ce que nous avons fait :
https://tinyurl.com/27pcda3z
Cordialement,
Au lieu d'écrire DESACTIVE, vous pourriez simplement ajouter 3 soulignés " ___ " au début des dossiers des plugins que vous souhaitez désactiver.
Cerise sur le gâteau : tous les plugins désactivés seront en début de liste.
Bonjour,
Cela risque de prendre énormément de temps de vérifier tous les plugins.
Il y aurait un plugin qui sature la mémoire du serveur dès 2 h du matin, chaque matin, et qui dépasse les capacités mémoire (6Go) de 9h à 11h tous les matins.
C'est bloquant de ne pas avoir de log concernant l'utilisation de la mémoire :
https://tinyurl.com/2dj9w5ax
Celle-ci est régulièrement saturée à partir de 2h du matin.
Il faut redémarrer le serveur de la webcloud database pour la saturation disparaisse et que l'on arrive à un taux d'utilisation correct qui ne pénalise pas les accès à nos différents sites.
La recherche des causes de cette saturation peut être très longue : plugin wordpress en internes qui se met en route à 2h du matin et qui sature la mémoire, avec pic d'utilisation de celle-ci à 6 Go tout les matins entre 9h et 11h.
Nous n'avons pas plus d'outils pour vérifier ce phénomène ? Pas de log supplémentaire dispo ?
Les seuls réponses d'OVH c'est : à vous de trouver, nous ne pouvons rien faire pour ce type de problème.
Très décevant surtout si on n'a aucun indice.
Il nous faudrait peut-être changer d'hébergeur.
Bonjour @EvelyneL2
Je ne suis pas du tout sûr que le changement d'hébergeur résultat votre problème.
Je reste persuadé que c'est quelque chose que vous avez mis sur votre site qui fiche la panique.
Bonjour,
Déjà avez-vous consulté les logs de votre base de données ?
Cordialement, janus57
Bonjour,
Merci pour votre réponse.
Nous scannons actuellement le fichier slow-query.log (28 méga)
Nous avons des requêtes de ce style vers 2h du matin et 9h du matin :
> # Query_time: 422.875330 Lock_time: 0.009829 Rows_sent: 0 Rows_examined: 0
> SET timestamp=1714726514;
> INSERT INTO `wpstg18_options` (`option_name`, `option_value`, `autoload`) VALUES ('_transient_doing_cron', '1714726514.4802849292755126953125', 'yes') ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`);
> # Time: 2024-05-03T09:02:17.366584Z
Une requête d'insert répétée quelques dizaines de fois : nous ne pensons pas que cela sature la mémoire, mais c'est peut-être une piste).
Nous scrutons également mysql.log (62 méga)
Nous avons en continu des :
> [Warning] [MY-013360] [Server] Plugin mysql_native_password reported: ''mysql_native_password' is deprecated and will be removed in a future release. Please use caching_sha2_password instead'
Merci pour vos retours.
Bonjour,
Une requête d'insert répétée quelques dizaines de fois : nous ne pensons pas que cela sature la mémoire, mais c'est peut-être une piste).
Heu la requête met + de 400secondes si je lis bien (soit plus de 6 minutes).
Donc je dirais quand même de vérifier le plugins lié à la requête.
Nous avons en continu des :
A ignorer pour le moment c'est lié à fait que votre instance soit en MySQL8.
Cordialement, janus57
wpstg18_options
Merci beaucoup pour le retour !
Effectivement :
> INSERT INTO `wpstg12_options` (`option_name`, `option_value`, `autoload`) VALUES ('_transient_doing_cron', '1714809242.2309510707855224609375', 'yes') ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`);
> # Time: 2024-05-04T09:09:00.036981Z
> # User@Host: departement[departement] @ [10.27.21.44] Id: 61760
> # Query_time: 4551.227131 Lock_time: 0.203144 Rows_sent: 0 Rows_examined: 0
ce genre de requête sur la table, nous en avons trouvé près de 400.
Mais c'est sur beaucoup de tables.
Donc il faut trouver l'origine du plugin.
wp-statistics, wp-fastest-cache, wp-wordpress-seo pas essentiels donc désactivés.
Nous verrons le résultat demain matin.