-
Verifique se seu hardware e SO estão configurados e ajustados corretamente:
- Origem do problema (uso de CPU / IO / memória / permuta). Você tem muita PIO? A CPU está carregada? Se você tem um monte de IOPs de leitura, provavelmente você não tem buffer_pool suficiente para o InnoDB. Se a CPU estiver carregada, provavelmente suas consultas fazem varreduras de tabela completas em vez de usar índices apropriados.
- Configuração de disco / RAID / LVM. Em algumas configurações específicas, Distribuição de LVM pode ser útil para você carregamento de disco (sem hardware RAID, vários LUNS conectados)
- Agendador IO: quando você tem um bom controlador RAID de hardware, provavelmente noop é o melhor. RedHat fez alguns testes e eles disseram, que para o Oracle (e outro DB) CFQ é a melhor escolha. Você precisa executar alguns benchmarks (como tpc-c ou tpc-e) e escolher o que é melhor para o seu hardware.
- Bom sistema de arquivos - o ext3 não funciona bem em cargas de trabalho específicas do banco de dados. Melhor é XFS ou OCFS2. Você precisa de alguns benchmarks novamente.
- Assista, se o seu sistema usa swap. Usando o swap degrada o desempenho do mysql .
-
Verifique se a sua instância do MySQL / InnoDB está devidamente ajustada:
- tamanho do buffer pool - páginas de dados de cache na memória
- innodb_flush_method = O_DIRECT - evita o buffer de E / S duplo
- aumenta o tamanho do arquivo de log do InnoDB - para uma carga de trabalho intensiva de gravação, isso pode melhorar o desempenho. Mas lembre-se: tamanho de arquivo de log maior significa maior recuperação de falhas. Às vezes em horas !!!
- innodb_flush_log_at_trx_commit = 0 ou 2 - Se você não está preocupado com o ACID e pode perder transações por um segundo ou dois segundos.
- key_buffer_size - muito importante para o MyISAM, mas é usado para tabelas temporárias de disco.
- Assista ao seu STATUS INNODB
- Analise sua carga de trabalho - capture todas as suas consultas para desacelerar o log e executar o mk-query-digest nele. Você pode capturar todas as consultas usando tcpdump e maatkit
- Quais consultas levam mais tempo do seu servidor?
- Existem tabelas temporárias criadas, especialmente grandes tabelas temporárias?
- Aprenda como usar explicar
- Seu aplicativo usa transações? Quando você executa consultas com autocommit = 1 (padrão para o MySQL), cada consulta de inserção / atualização inicia uma nova transação, o que gera alguma sobrecarga. Se for possível, é melhor desabilitar o autocommit (por padrão, o autocommit do driver python do MySQL é desabilitado por padrão) e executar manualmente o commit depois que todas as modificações forem feitas.
- Seu aplicativo faz séries de inserções na mesma tabela em um loop? O comando
Load data infileé muito mais rápido para séries de inserções. - Lembre-se:
select count(*) from table;é muito mais lento para innodb do que para myisam. - Que tipos de consultas INSERT / UPDATE levam a maior parte do tempo do servidor? Como eles podem ser otimizados?
- Verifique se o seu banco de dados tem índices apropriados e adicione-os, se necessário.
In our environment we had situation, that one type of update queries was slow. Estimated time to finish batch job was 2 days!!! After analyzing slowquery log we find, that this type of update query needs 4 seconds to complete. Query looked like this:
update table1 set field1=value1 where table1.field2=xx table2.field3=yy and table2.field4=zz. After converting update query to select query and running explain on that select query we find, that this type of query doesn't use index. After creating proper index we had reduced update query execution time to miliseconds and whole job finished in less than two hours.
Alguns links úteis:
- SHOW INNODB STATUS percorrer
- O que ajustar no MySQL Server após a instalação
- Noções básicas de otimização de desempenho da Innodb
- Como você calcula um bom InnoDB? tamanho do arquivo de log
- Escolhendo innodb_buffer_pool_size
- Escolhendo o innodb_log_file_size adequado