Mysql
 sql >> Base de Dados >  >> RDS >> Mysql

Desempenho do MySQL:identificando consultas longas


Cada aplicativo com suporte do MySQL pode se beneficiar de um servidor de banco de dados bem ajustado. A equipe do Liquid Web Heroic Support encontrou várias situações ao longo dos anos em que alguns pequenos ajustes fizeram uma grande diferença no desempenho do site e do aplicativo. Nesta série de artigos, descrevemos algumas das recomendações mais comuns que tiveram o maior impacto no desempenho.

Verificação de simulação


Este artigo se aplica à maioria dos servidores MySQL VPS baseados em Linux. Isso inclui, mas não se limita a servidores Dedicados Tradicionais e VPS em Nuvem executando uma variedade de distribuições Linux comuns. O artigo pode ser usado com os seguintes tipos de sistema Liquid Web:
  • CentOS 6x/7x gerenciado por núcleo
  • Ubuntu 14.04/16.04 gerenciado por núcleo
  • CPanel CentOS 6/7 totalmente gerenciado
  • CentOS 7 Plesk Onyx 17 totalmente gerenciado
  • Servidores Linux autogerenciados
ObservaçãoOs sistemas autogerenciados, que optaram por não receber suporte direto, podem tirar proveito das técnicas discutidas aqui, no entanto, a equipe de suporte do Liquid Web Heroic não pode oferecer ajuda direta nesses tipos de servidor.
Esta série de artigos pressupõe familiaridade com os seguintes conceitos básicos de administração do sistema:
  • Conexões SSH e navegação básica do ambiente shell de linha de comando padrão do Linux.
  • Abrindo, editando e salvando arquivos no Vim ou em um editor de sistema escolhido.
  • Modo interativo do MySQL e sintaxe geral de consulta do MySQL.

O que é a otimização do MySQL?


Não há uma definição claramente definida para o termo MySQL Optimization. Pode significar algo diferente dependendo da pessoa, administrador, grupo ou empresa. Para esta série de artigos sobre MySQL Optimization, definiremos MySQL Optimization como: A configuração de um servidor MySQL ou MariaDB que foi configurada para evitar gargalos comumente encontrados discutidos nesta série de artigos.

O que é um gargalo?


Muito semelhante ao gargalo de uma garrafa de refrigerante, um gargalo como termo técnico é um ponto em uma configuração de aplicativo ou servidor onde uma pequena quantidade de tráfego ou dados pode passar sem problemas. No entanto, um volume maior do mesmo tipo de tráfego ou dados é impedido ou bloqueado e não pode operar com sucesso como está. Veja o exemplo a seguir de um gargalo de configuração:

Neste exemplo, o servidor é capaz de lidar com 10 conexões simultaneamente. No entanto, a configuração aceita apenas 5 conexões. Esse problema não se manifestaria enquanto houvesse 5 ou menos conexões ao mesmo tempo. No entanto, quando o tráfego aumenta para 10 conexões, metade delas começa a falhar devido a recursos não utilizados na configuração do servidor. Os exemplos acima ilustram a forma do gargalo de onde deriva seu nome versus uma configuração otimizada que corrige o gargalo.

Quando devo otimizar meu banco de dados MySQL?


Idealmente, o ajuste de desempenho do banco de dados deve ocorrer regularmente e antes que a produtividade seja afetada. É uma prática recomendada realizar auditorias semanais ou mensais do desempenho do banco de dados para evitar que problemas afetem os aplicativos de maneira adversa. Os sintomas mais óbvios de problemas de desempenho são:
  • As consultas se acumulam e nunca são concluídas na tabela de processos do MySQL.
  • Aplicativos ou sites que usam o banco de dados ficam lentos.
  • Erros de tempo limite de conexão, especialmente durante os horários de pico.

Embora seja normal que haja várias consultas simultâneas sendo executadas ao mesmo tempo em um sistema ocupado, torna-se um problema quando essas consultas demoram muito para serem concluídas regularmente. Embora o limite específico varie por sistema e por aplicativo, os tempos médios de consulta que excedem vários segundos se manifestarão como uma lentidão nos sites e aplicativos anexados. Essas lentidão às vezes podem começar pequenas e passar despercebidas até que um grande aumento de tráfego atinja um gargalo específico.

Identificando problemas de desempenho


Saber como examinar a tabela de processos do MySQL é vital para diagnosticar o gargalo específico encontrado. Há várias maneiras de visualizar a tabela de processos, dependendo de seu servidor e preferência específicos. Por questões de brevidade, esta série se concentrará nos métodos mais comuns usados ​​via acesso Secure Shell (SSH):

Método 1. Usando a tabela de processos do MySQL


Use o 'mysqladmin ' ferramenta de linha de comando com o sinalizador 'processlist ' ou 'proc ' como diminutivo. (Adicionar o sinalizador 'estatísticas ' ou 'estatística ' para breve mostrará estatísticas de execução para consultas desde a última reinicialização do MySQL.)

Comando:
mysqladmin proc stat

Saída:
 +-------+------+-----------+-----------+---------+------+-------+
 | Id    | User | Host      | db        | Command | Time | State | Info               | Progress |
 +-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
 | 77255 | root | localhost | employees | Query   | 150  |       | call While_Loop2() | 0.000    |
 | 77285 | root | localhost |           | Query   | 0    | init  | show processlist   | 0.000    |
 +-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
 Uptime: 861755  Threads: 2  Questions: 20961045  Slow queries: 0  Opens: 2976  Flush tables: 1  Open tables: 1011  Queries per second avg: 24.323
Observação:Pro :usado na interface do shell, isso facilita a saída de canal para outros scripts e ferramentas.Con :a coluna de informações da tabela de processos é sempre truncada, portanto, não fornece a consulta completa em consultas mais longas

Método 2:usando a tabela de processos do MySQL


Execute a consulta 'show processlist;' no prompt do modo interativo do MySQL. (Aadicionando o ' completo ’  modificador do comando desativa o truncamento do Informações coluna . Isso é necessário ao visualizar consultas longas.)

Comando:
show processlist;

Saída:
MariaDB [(none)]> show full processlist;
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
 | Id    | User | Host      | db        | Command | Time | State | Info                  | Progress |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
 | 77006 | root | localhost | employees | Query   |  151 | NULL  | call While_Loop2()    |    0.000 |
 | 77021 | root | localhost | NULL      | Query   |    0 | init  | show full processlist |    0.000 |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
Pro :usar o modificador completo permite ver a consulta completa em consultas mais longas.Con :O modo interativo do MySQL não pode acessar scripts e ferramentas disponíveis na interface do shell.

Usando o log de consultas lentas


Outra ferramenta valiosa no  MySQL é o recurso de registro de consultas lentas incluído. Esse recurso é o método preferencial para localizar consultas de longa duração regularmente. Existem várias diretivas disponíveis para ajustar esse recurso. No entanto, as configurações mais comumente necessárias são:
slow_query_log habilitar/desabilitar o log de consultas lentas
slow_query_log_file nome e caminho do arquivo de log de consulta lenta
long_query_time tempo em segundos/microssegundos definindo uma consulta lenta

Essas diretivas são definidas na seção [mysqld] do arquivo de configuração do MySQL localizado em /etc/my.cnf e exigirão uma reinicialização do serviço MySQL antes de entrarem em vigor. Veja o exemplo abaixo para formatação:
Aviso:Há uma grande preocupação com o espaço em disco com o arquivo de log de consulta lenta, que precisa ser atendido continuamente até que o recurso de log de consulta lenta seja desabilitado. Tenha em mente que quanto menor for sua diretiva long_query_time, mais rápido o log de consulta lenta preencherá uma partição de disco
[mysqld]
 log-error=/var/lib/mysql/mysql.err
 innodb_file_per_table=1
 default-storage-engine=innodb
 innodb_buffer_pool_size=128M
 innodb_log_file_size=128M
 max_connections=300
 key_buffer_size = 8M
 slow_query_log=1
 slow_query_log_file=/var/lib/mysql/slowquery.log
 long_query_time=5

Assim que o log de consultas lentas estiver ativado, você precisará acompanhá-lo periodicamente para revisar as consultas indisciplinadas que precisam ser ajustadas para um melhor desempenho. Para analisar o arquivo de log de consulta lenta, você pode analisá-lo diretamente para revisar seu conteúdo. O exemplo a seguir mostra as estatísticas da consulta de amostra que durou mais do que os 5 segundos configurados:
CuidadoO desempenho foi atingido ao ativar o recurso de log de consulta lenta. Isso se deve às rotinas adicionais necessárias para analisar cada consulta, bem como à E/S necessária para gravar as consultas necessárias no arquivo de log. Por isso, é considerado uma prática recomendada em sistemas de produção desabilitar o log de consulta lenta. O log de consultas lentas deve permanecer ativado apenas por um período específico ao procurar ativamente consultas problemáticas que possam estar afetando o aplicativo ou o site. 
# Time: 180717  0:23:28
 # User@Host: root[root] @ localhost []
 # Thread_id: 32  Schema: employees  QC_hit: No
 # Query_time: 627.163085  Lock_time: 0.000021  Rows_sent: 0  Rows_examined: 0
 # Rows_affected: 0
 use employees;
 SET timestamp=1531801408;
 call While_Loop2();

Opcionalmente, você pode usar a ferramenta de linha de comando mysqldumpslow, que analisa o arquivo de log de consulta lenta e agrupa como consultas, exceto valores de dados numéricos e de string:
~ $ mysqldumpslow -a /var/lib/mysql/slowquery.log
 Reading mysql slow query log from /var/lib/mysql/slowquery.log
 Count: 2  Time=316.67s (633s)  Lock=0.00s (0s)  Rows_sent=0.5 (1), Rows_examined=0.0 (0), Rows_affected=0.0 (0), root[root]@localhost
 call While_Loop2()

(Para informações de uso, visite a documentação do MySQL aqui - mysqldumpslow — Resumir arquivos de log de consulta lenta)

Conclusão


Assim conclui a primeira parte de nossa série de Otimização de Banco de Dados e nos dá uma base sólida para referência para fins de benchmark. Embora os problemas de banco de dados possam ser complicados, nossa série detalhará esses conceitos para fornecer meios de otimizar seu banco de dados por meio de conversão de banco de dados, conversão de tabela e indexação.

Como podemos ajudar?


Nós nos orgulhamos de ser os humanos mais úteis em hospedagem™!

Nossas equipes de suporte estão repletas de técnicos Linux experientes e administradores de sistema talentosos que têm conhecimento profundo de várias tecnologias de hospedagem na web, especialmente aquelas discutidas neste artigo.

Se você tiver alguma dúvida sobre essas informações, estamos sempre disponíveis para responder a quaisquer perguntas relacionadas a este artigo, 24 horas por dia, 7 dias por semana, 365 dias por ano.

Se você for um servidor VPS totalmente gerenciado, Dedicado em Nuvem, Nuvem Privada VMWare, Servidor Pai Privado, Servidores em Nuvem Gerenciado ou proprietário de um servidor Dedicado e não se sentir à vontade para executar qualquer uma das etapas descritas, nós pode ser contatado pelo telefone @800.580.4985, um chat ou ticket de suporte para ajudá-lo com este processo.
Series NavigationPróximo artigo>>