2017-01-09 6 views
0

J'ai wordpress avec des milliers de catgories/taxonomies personnalisées et des dizaines de milliers de messages. J'ai du mal à le garder en ligne sans cache, car le processeur atteint 100% (utilisé par le serveur mysql pas php).Wordpress mysqld est parti

J'ai isolé un problème, en raison de la mise à jour de MySQL, erreur de base de données WordPress: [serveur MySQL a disparu] MISE À JOUR wphn_options SET option_value = ........... 'Où option_name =' rewrite_rules ', ceci est exécuté à chaque chargement de page. Voici un exemple de cette option_value: `Erreur de base de données WordPress: [le serveur MySQL est parti] (ce n'est pas tous les 1% de la requête, juste un court aperçu). Tout le monde sait comment je peux arrêter l'exécution de cette requête?

UPDATE `wphn_options` SET `option_value` = 'a:7269:{s:18:\"sitemap_trolio.xml\";s:33:\"index.php?aiosp_sitemap_path=root\";s:29:\"sitemap_trolio_(.+)_(\\d+).xml\";s:71:\"index.php?aiosp_sitemap_path=$matches[1]&aiosp_sitemap_page=$matches[2]\";s:23:\"sitemap_trolio_(.+).xml\";s:40:\"index.php?aiosp_sitemap_path=$matches[1]\";s:34:\"sitemap(-+([a-zA-Z0-9_-]+))? 

Répondre

1

La lecture du contenu de cette mise à jour à la table options, vous pouvez le voir est lié au plan du site de votre site. Vous pouvez avoir un plugin sitemap. Ce plugin sitemap peut faire quelque chose sur chaque chargement de page. Essayez de le désactiver.

Si vous avez accès à phpmyadmin, faites d'abord une sauvegarde de votre installation et de votre base de données (si ce n'est pas déjà fait). Ensuite, émettez la commande SQL OPTIMIZE TABLE wphn_options; et voyez si cela aide. Si c'est le cas, génial. Essayez d'optimiser également certaines autres tables. OPTIMIZE TABLE wphn_posts; pourrait être un bon à essayer.

Mais regardez: Votre installation WordPress est sous-provisionnée. Vous avez besoin de meilleures ressources de serveur. Vous avez pris la peine de créer des dizaines de milliers de messages. En utilisant une configuration de serveur aussi faible, vous dissimulez intentionnellement ces messages à votre public, juste pour économiser quelques pièces. Et, vous courez le risque de corrompre votre site en utilisant un serveur faible. N'est-ce pas la définition même de "penny sage, livre stupide?"

Votre question est comme "La batterie de ma voiture est faible Je veux arrêter de gaspiller l'électricité sur mes feux de freinage S'il vous plaît dites-moi comment couper les fils aux feux de freinage." En toute déférence, la seule réponse rationnelle est "Es-tu folle? Tu risques de fracasser ta voiture pour éviter de réparer ta batterie?"

+0

Je comprends votre point de vue, mais il est pas comme ça du tout. J'ai un serveur dédié avec 4x Xeon (Sixcore chacun). 256 Go de RAM, et Samsung SSD hdds, il reste généralement à 10% ou moins, mais quand le cache n'est pas construit, il se bloque. J'ai supprimé AIOSP qui était ajouté à la requête de mise à jour longue mais la requête est toujours là, elle est juste plus courte, voici un exemple de la nouvelle requête après avoir supprimé la partie Sitemap: __u = 1 & name = $ matches [1] & page = $ correspond à [2] \ "; s: 10: \"^u/(. *)? /? \ "; s: 32: \" index.php? __ u = 1 & name = $ correspond à [1] \ "; s: 14: \ "^ acteur/(. *)? /? \"; S: 27: \ "index.php? Acteur = $ correspond [1] \"; s: 16: \ "^ regizor /(.*) ? –

0

J'ai trouvé la solution, il semble qu'en raison du grand nombre de publications et de catégories, la requête n'a pas pu être construite et le serveur mysql s'est écrasé pour se protéger.

J'ai résolu le problème en ajoutant max_allowed_packet = 256M dans le fichier de configuration MySQL