Base de données Wordpress lente - dois-je passer à InnoDB?


12

J'ai un site WordPress avec plus de 10 000 publications, et les choses commencent à devenir très lentes chaque fois que j'ajoute et modifie des publications. Les pages se chargent bien et rapidement pour les utilisateurs, ainsi que les listes d'administration des publications, mais c'est lorsque des écritures ou des mises à jour se produisent que le serveur passe à 100% du processeur et prend beaucoup de temps (parfois plus long que le délai d'expiration de PHP des années 60).

Je pense que cela est probablement lié au verrouillage au niveau de la table de MyISAM, et je pense à passer à InnoDB. Quelles sont les implications de cela?

Quelques statistiques:

select  - per hour ~22k
update  - per hour ~7.6k
set option  - per hour ~7k

Je sais qu'il y a beaucoup d'autres optimisations que je peux faire, mais je pense que cela pourrait avoir le plus grand impact.

Merci

Edit : J'ai trouvé l'un des problèmes majeurs à l'origine de la lenteur, c'est YARPP (Yet Another Related Posts Plugin) qui régénérait la "parenté" à chaque fois, et cela semblait être dû aux balises 2k + que nous avons. J'ai désactivé l'option "considérer les balises" et elle s'est considérablement accélérée.

En outre, d'autres plugins qui régénèrent les choses peuvent provoquer ce type de problèmes, tels que certains plugins de sitemap XML.

Donc, mon problème immédiat est résolu, même si j'aimerais toujours entendre une bonne réponse à InnoDB vs MyISAM for Wordpress!

Réponses:


11

Je passerais en effet à InnoDB. Le verrouillage de table / verrouillage de ligne a longtemps été discuté par beaucoup. Je choisirais toujours InnoDB haut la main. Cependant, il existe une autre raison profonde de choisir InnoDB ... CACHING .

Alors que la plupart des gens se vantent que MyISAM est plus rapide pour les lectures, la plupart des gens oublient que les nombreux cache pour MyISAM, qui est appelé le cache de clés (défini par key_buffer_size), ne mettent en cache que les pages d'index des fichiers .MYI. Il ne met jamais en cache les pages de données. Il a un maximum officiel de 4 Go dans les systèmes 32 bits. 8 Go est le meilleur maximum pour 64 bits.

Le pool de tampons InnoDB met en cache les pages de données et d'index. En fonction du serveur dont vous disposez, vous pouvez mettre en cache l'ensemble de données dans la RAM. Vous pouvez régler InnoDB jusqu'à 80% de RAM et 10% pour les connexions DB, et laisser 10% pour le système d'exploitation. Cela est vrai même pour différents systèmes d'exploitation .

J'ai recommandé ces choses aux clients Drupal avec un merveilleux succès. Cela s'applique également à Wordpress . J'ai fourni un support DB pour les clients avec WordPress. Mêmes améliorations.

Vous pouvez toujours configurer la mémoire pour InnoDB plus efficacement que vous ne pouvez plus MyISAM. Il existe toujours un moyen d' ajuster InnoDB pour répondre à vos besoins de performances . Au fur et à mesure que vos données augmentent, cela deviendra éventuellement une exigence .


6

InnoDB ne vous aidera probablement pas - le verrouillage au niveau des pages / lignes aide à atténuer les conflits, mais il ne semble pas que ce soit votre problème.

Il y a beaucoup de choses qui suggèrent que MyISAM est plus lent qu'InnoDB dans le scénario de blog moyen (beaucoup plus de lectures que d'écritures).

Avant d'effectuer un changement, vous devez au moins effectuer les opérations suivantes

  • lancez mysqltuner qui vous donnera quelques conseils de configuration (ce n'est pas infaillible ou tout savoir cependant)
  • activez la journalisation lente des requêtes, laissez-la pendant un jour environ, puis commencez à parcourir le journal et à EXPLIQUER les requêtes pour voir ce qui se passe

Par expérience personnelle, j'ai trouvé que l'ajout d'un index à un champ non indexé sur wp_comments m'a aidé massivement dans ma situation particulière (périodes de commentaires brusques, où une dizaine de personnes pourraient essayer de commenter en même temps), et il est possible que quelles requêtes s'exécutent lentement et pourquoi peuvent vous conduire à une meilleure compréhension du problème, et une VRAIE solution!

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.