Horrendo decréscimo no desempenho do MySQL após atualização para o Ubuntu 16.04 MySQL 5.7.12

Question

Eu tenho um servidor de desenvolvimento que atualizei recentemente de 14.04 para 16.04.

Eu tenho um banco de dados 'álgebra', que hospeda dados para o meu site algebra.com. É um site Q & A que tem Perguntas e Respostas, com relação de 1 a N.

Após a atualização, o desempenho das mesmas consultas exatas de banco de dados se deteriorou drasticamente.

Por exemplo, uma consulta que une perguntas e respostas por id de pergunta, costumava levar menos de meio segundo. Após a atualização, leva um MINUTO.

Como este é um servidor de desenvolvimento, posso compará-lo ao servidor de produção, que ainda executa o 14.04 e onde a mesma consulta leva apenas 0,38 segundos.

Aqui estão os planos de consulta

mysql> explain SELECT 
    ->     questions.id, questions.email, questions.topic, questions.question,  
    ->     questions.date, 
    ->     questions.deleted, 
    ->     questions.is_spam, 
    ->     questions.solved, 
    ->  
    ->     questions.tb_id, 
    ->     questions.tb_isbn, 
    ->     questions.tb_title, 
    ->     questions.tb_edition, 
    ->     questions.tb_chapter, 
    ->     questions.tb_problem, 
    ->  
    ->     solutions.id, solutions.author author, solutions.date, solutions.answer 
    -> FROM questions, solutions 
    -> WHERE 
    ->      questions.solved = 1 
    ->      AND questions.id = solutions.question 
    ->      AND questions.deleted != 1 
    ->      AND questions.is_spam != 1 
    -> ORDER BY solutions.date DESC 
    -> LIMIT 50; 

No "Bom servidor":

+----+-------------+-----------+--------+-----------------------+---------+---------+----------------------------+--------+----------------+
| id | select_type | table     | type   | possible_keys         | key     | key_len | ref                        | rows   | Extra          |
+----+-------------+-----------+--------+-----------------------+---------+---------+----------------------------+--------+----------------+
|  1 | SIMPLE      | solutions | ALL    | solutions_by_question | NULL    | NULL    | NULL                       | 650770 | Using filesort |
|  1 | SIMPLE      | questions | eq_ref | PRIMARY               | PRIMARY | 4       | algebra.solutions.question |      1 | Using where    |
+----+-------------+-----------+--------+-----------------------+---------+---------+----------------------------+--------+----------------+
2 rows in set (0.00 sec)

No "Servidor inválido:

+----+-------------+-----------+------------+------+-----------------------+-----------------------+---------+----------------------+--------+----------+----------------------------------------------+
| id | select_type | table     | partitions | type | possible_keys         | key                   | key_len | ref                  | rows   | filtered | Extra                                        |
+----+-------------+-----------+------------+------+-----------------------+-----------------------+---------+----------------------+--------+----------+----------------------------------------------+
|  1 | SIMPLE      | questions | NULL       | ALL  | PRIMARY               | NULL                  | NULL    | NULL                 | 482186 |     8.10 | Using where; Using temporary; Using filesort |
|  1 | SIMPLE      | solutions | NULL       | ref  | solutions_by_question | solutions_by_question | 4       | algebra.questions.id |      1 |   100.00 | Using index condition                        |
+----+-------------+-----------+------------+------+-----------------------+-----------------------+---------+----------------------+--------+----------+----------------------------------------------+

O conteúdo do banco de dados é mais ou menos o mesmo, o banco de dados de desenvolvimento é um backup do servidor da noite anterior.

Alguma idéia de como eu posso começar a perseguir o declínio do desempenho?

Obrigado!

    

Answer 1

Se você atualizou para um servidor Ubuntu 16.04 e está usando o 5.7.12, você está encontrando - pelo menos em parte - um bug comendo RAM, e algumas otimizações dinâmicas / configurações padrão baseadas no servidor disponível RAM e são definidos menos do que idealmente. Isso tem sido problemático para muitas pessoas, mas especialmente para servidores / vps menores com pouca RAM.

Procure em laracasts.com pelo vazamento de memória do MySQL 5.7

link

Existem outras questões, algumas das quais 5.7.13 corrigidas, é claro ...

link

Também houve algumas otimizações / alterações diferentes feitas que terão impacto, dependendo se você usar ou não o InnoDB ou o MyISAM. Para dar um exemplo, um VPS recentemente instalado com 2 GB de RAM que consome cerca de 320 MB de RAM se você reiniciar o MySQL irá aumentar lentamente até consumir 1 GB em um aplicativo inativo, no modo de manutenção ... com tráfego zero ou consultas de banco de dados (que foi uma instalação do OpenCart que usa o MyISAM ... que eu não gostaria de desejar a ninguém tentando avançar ... mas esse foi um caso de "apresse-se e vamos fazer isso e usar isso e ....") . E assim, essa instância específica requer mais tempo para voltar e lidar com esse mesmo problema de desempenho insatisfatório do MySQL por causa de uma dependência do MyISAM no aplicativo, vazamento de memória e alguns padrões ruins que a equipe da Oracle jogou na natureza. / p>

Claro, você provavelmente quer otimizar suas consultas e participar das novas atualizações. Mas, ao mesmo tempo, você provavelmente estará desperdiçando um grande esforço e não realizando nada por causa da memória subjacente vazando como um problema de peneira. Se você vai passar por otimizações, você pode fazê-lo com um servidor MySQL diferente daquele que causa problemas para você.

Suas opções são, dado a lentidão do MySQL na correção de bugs, são:

1) montando e aguardando por atualizações de repositório que consertem isso

2) desinstalar a versão atual e voltar para um anterior (mas por quê?)

3) substitua por MariaDB ou Percona

Se você iniciar um novo servidor Ubuntu 16.04, eu mudaria os repositórios antes de conectar qualquer agente de administração remota ou instalar painéis de gerenciamento de servidores, para que você esteja em uma faixa MariaDB / Percona. Ou acompanhando os repositórios oficiais do MySQL em vez dos repositórios do Ubuntu, para que você consiga correções mais rapidamente.

A solução segura e imediata (certamente mais inteligente do que prolongar o uso de versões anteriores com bugs e um ponto de interrupção de compatibilidade principal no fluxo de release) é alternar para o MariaDB ou Percona. Ou, se você estiver usando um aplicativo que pode usar o PostgreSQL, bem como o MySQL, mude para o Postgre - se é algo que não é nada prático.

Eu não perderia meu tempo tentando otimizar o banco de dados até que eu tivesse atualizado para o 5.7.13 e monitorado os resultados, ou mudado para o MariaDB ou o Percona. Otimização / solução de problemas 5.7.12 é apenas um buraco negro sugando seu tempo e recursos.

    

Answer 2

Especificamente, é o erro Memória excessiva usada na memória / innodb / os0file começando em 5.7.8 .

Ele é rastreado no Ubuntu como RAM de consumo excessivo do daemon mysqld no Ubuntu 16.04 , e há também uma discussão no Reddit .