Suporte » Ajustando o WordPress » Banco de dados com alto consumo – auxílio na identificação da origem do problema

  • Galera, possuo um site que tem 5 mil pageviews/dia.

    O site está estruturado da seguinte maneira: um VPS para o servidor WEB (ngnix, php-fpm e apache – serverpilot) e outro VPS somente para dados (roda somente MySQL, sem apache e etc).

    o servidor de dados sempre oscilou seu processamento entre 2% e 20% (média). De uns tempos para cá, o servidor de dados começou a ficar atolado de processamento (não afetou a memória).

    As coisas começaram a ficar estranhas quando o próprio servidor de dados, diante de tanta solicitação, começou a negar conexão (começou aparecer isso no LOG” PHP Warning: mysqli_real_connect(): (HY000/2002): Connection refused in” e “Erro de banco de dados do WordPress Sort aborted: Server shutdown in progress para a consulta SELECT post_modified_gmt FROM”).
    O site não chega a ficar fora do ar, mas o seu tempo de carregamento está bizarro (lerdo!), bem como, os editores estão com grande dificuldade para postar os artigos.

    Tentando identificar a origem do problema, usei o plugin Query Monitor para ver as requisições do site ao banco de dados.
    Diz o plugin que estes três chamadores estão requisitando 300 e poucas linhas do banco de dados:
    QUERY
    SELECT option_name, option_value
    FROM guiatable_options
    WHERE autoload = ‘yes’

    CALLER
    1. wp_not_installed()
    wp-includes/load.php:607
    2. is_blog_installed()
    wp-includes/functions.php:1530
    3. wp_load_alloptions()
    wp-includes/option.php:202

    ROWS: 356

    A questão é: não sei se a origem do problema é essa, bem como, se for, como corrigir (já que estão no core)?

    Alguém, por gentileza, também consegue me auxiliar para tentar identificar a origem do problema?

    Obg

Visualizando 6 respostas - 1 até 6 (de um total de 6)
  • saudações zedomingues,

    não sou desenvolvedor, sou designer, mas como gerencio meus servidores, venho tentar contribuir com sugestões. e pedi que voluntários dev possam, se possível, também dar sugestões.

    eu uso Plesk em meus servidores (apesar que estou testando Cloudways e provavelmente vou migrar para esse sistema). e algo que já reparei é que por vezes o servidor MySQL dispara no consumo de recursos.

    pesquisando documentações, especialmente do Plesk e Cloudways, e conversando com suportes* no passado, há um tempo passei a dar atenção ao banco de dados, inclusive investindo em plugins de otimização. porque como tudo que acontece no WordPress fica registrado no BD, esse vai inchando. e ai além disso ir com o tempo gerando perda de performance, ainda podem ficar registrados erros que causam dores de cabeça no futuro.

    (*aliás, uma coisa que vale muito a pena é ter servidor internacional, porque rola um respeito muito grande com o cliente quando eles percebem que o cliente sabe o que está fazendo. diferente da grande maioria de suportes no Brasil, em que costumam culpar e WordPress e só faltam dizer “o problema é seu…”)

    na minha experiência, como não-programador, eu sugeriria pensar em uma solução para otimizar o banco de dados. e com esse volume, provavelmente teria que ser uma solução premium, pois o volume de carregamento do BD é considerável e ainda tem editores, o que talvez gere constante criação de rascunhos salvos.

    e seria interessante ver que estatísticas seu VPS oferece. das 3 coisas que me conquistaram no Plesk, uma com certeza são as estatísticas. tenho dados do servidor sobre consumo de dados, banda, picos de consumo, etc. e o próprio Plesk me alerta sobre tendências de problemas de acordo com a perspectiva de consumo de dados.

    assim como o Cloudways, que oferecere estatísticas tanto do servidor como de cada aplicativo individual. sendo que com essas estatísticas é ótimo para conversar com o suporte (no meu caso, seja Cloudways, seja Google Cloud com o Plesk) e tentar descobrir o que não posso estar vendo.

    no caso do Google Cloud, eles me alertaram sobre uma contínua criação de log em uma pasta. fui verificar e percebi que era o plugin de cache, que também ficava criando os logs, que só cresciam e cresciam. ai corrigi isso e pronto, os picos de consumo do servidor pararam.

    então toda essa história é para sugerir que busque estatísticas de consumo em seu VPS e tente conversar com o suporte. não que eles mesmos resolvam, eles podem dar um norte de que comportamento pode estar forçando o servidor do banco de dados.

    boa sorte.

    Configura o redis no seu serverpilot e ativa ele como object cache do WordPress. Assim o redis dá uma aliviada ao mysql.
    E procure otimizar seu mysql também. Existe alguns scripts que podem te ajudar, como o MysqlTuner. Mas recomendo mesmo é que você procure alguém especializado.

    @ralden obrigado pelo feedback.

    sim, o servidor fica fora do BR (digital ocean) e eu também uso mecanismos de otimização do banco de dados.

    acontece que, mesmo otimizando o banco de dados, o alto consumo de processo continuava.

    enfim, consegui resolver o problema (acredito que temporariamente) aumentando os limites do MySQL.

    essa informação do plugin de cache me interessou, consegue, por gentileza, me informar qual era o plugin e onde era essa pasta?

    obrigado pela dica @luizbills vou procurar ver como instalar o redis (numa primeira vez, há muito tempo, tive problemas).

    obrigado

    na época era o wp-rocket. que tinha arquivos de log. só que hoje em dia não uso mais, mudei para o swift performance. que também preciso ficar de olho nos logs.

    @zedomingues Como o amigo falou acima, usar o Redis daria um ótimo alívio para o mySQL.

    Outra coisa esse site é mantido sempre atualizado? plugins, tema e etc. Ou teve alguma atualização recente em alguma coisa. O que pode causar aumento de consumo são queries mal otimizadas, plugins desatualizados, ou atualizados que trouxeram alguma coisa diferente.

    Vale instalar o plugin query monitor e fazer uma análise, você pode ganhar segundos preciosos otimizando queries

    Vi que você ja resolveu o problema, mas são boas coisas pra manter no radar.

    @marioernestoms sim, procuro sempre manter o site atualizado

    já estou usando o query monitor, inclusive ele detectou uma forte requisição de algumas linhas (veja na minha primeira interação).

    estou, inclusive, tentando analisar essas requisições

    obrigado

Visualizando 6 respostas - 1 até 6 (de um total de 6)
  • Você deve estar conectado para responder a este tópico.