Banco de dados WordPress lento – devo mudar para o InnoDB?

Eu tenho um site WordPress com mais de 10k postagens, e as coisas começam a ficar muito lentas sempre que estou adicionando e editando postagens. O carregamento de páginas é agradável e rápido para os usuários, juntamente com as listas de postagens de administração, mas é quando as gravações ou atualizações ocorrem, o servidor passa a 100% da CPU e leva muito tempo (às vezes mais do que o tempo limite de 60s do PHP).

Estou pensando que isso provavelmente fará com o bloqueio no nível da mesa do MyISAM e estou pensando em mudar isso para o InnoDB. Quais são as implicações de fazer isso?

Algumas statistics:

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

Eu sei que há muitas outras otimizações que posso fazer, mas meus sentimentos são que isso pode ter o maior impacto.

obrigado

Edit : Eu encontrei um dos principais problemas que causam a lentidão, foi YARPP (Yet Another Related Posts Plugin) que estava regenerando a “relação” de cada vez, e isso parecia ser devido às tags de 2k + que temos. Desligue a opção “considerar tags” e acelerou consideravelmente.

Além disso, outros plugins que regeneram coisas podem causar esse tipo de problemas, como alguns plugins do sitemap XML.

Então, meu problema imediato está resolvido, embora eu ainda adorei ouvir uma boa resposta para o InnoDB vs MyISAM para WordPress!

Solutions Collecting From Web of "Banco de dados WordPress lento – devo mudar para o InnoDB?"

Eu realmente mudaria para o InnoDB. Bloqueio de mesa / bloqueio de linha tem sido discutido por muitos. Eu sempre escolheria InnoDB mãos para baixo. No entanto, há outra razão profunda para escolher InnoDB … CACHING .

Enquanto a maioria das pessoas se vangloria de que o MyISAM é mais rápido para as leituras, a maioria das pessoas esquece que o cache para MyISAM, que é chamado de cache de chave (definido por key_buffer_size), apenas armazena imagens de índice de arquivos .MYI. Nunca armazena em cache páginas de dados. Tem um máximo oficial de 4 GB em sistemas de 32 bits. 8GB é o melhor máximo para 64 bits.

O InnoDB Buffer Pool armazena em cache as páginas de dados e índices. Dependendo do servidor que você possui, você pode armazenar em cache até todo o dataset na RAM. Você pode sintonizar o InnoDB para até 80% de RAM e 10% para Conenções de DB e deixar 10% para o sistema operacional. Isso é verdade mesmo para diferentes sistemas operacionais .

Eu recomendei essas coisas para os clientes do Drupal com um sucesso maravilhoso. Aplica-se também à WordPress . Eu forneci suporte de database para clientes com o WordPress. As mesmas melhorias.

Você sempre pode configurar a memory para InnoDB de forma mais eficaz que você pode mais MyISAM. Sempre há uma maneira de Tweek InnoDB para atender às suas necessidades de desempenho . À medida que seus dados crescem, ele acabará por se tornar um requisito .

O InnoDB provavelmente não o ajudará – o bloqueio de nível de página / linha ajuda a mitigar a contenção, mas não parece que esse seja seu problema.

Há muitas coisas lá que sugerem que o MyISAM é mais lento do que o InnoDB no cenário médio do blog (muitas outras lê do que as gravações).

Antes de fazer um interruptor, você deve pelo menos fazer o seguinte

  • execute o mysqltuner que lhe dará alguns conselhos de configuração (não é infalível ou tudo sabe)
  • ativar o log de consultas lentas, deixá-lo por um dia ou mais e, em seguida, começar a peneirar o log e EXPLICANDO as consultas para ver o que está acontecendo

A partir da experiência pessoal, descobri que adicionar um índice a um campo sem indexação no wp_comments ajudou massivamente na minha situação particular (períodos de comentários explosivos, onde 10 ou mais pessoas poderiam estar tentando comentar ao mesmo tempo), e é possível descobrir Quais consultas estão funcionando devagar e por que você pode levá-lo a uma melhor compreensão do problema e uma solução REAL!