O MySQL 5.5 degradou o desempenho no kernel Linux 3.2 em comparação com 2.6

Question

Nossos servidores de banco de dados (principalmente baseados nos pacotes estáveis do Debian (= atualmente Wheezy) parecem ter cerca de 4 vezes mais carregamento para a mesma carga de trabalho no kernel 3.2.0-4-amd64 do que no anterior 2.6.32-5-amd64 Com todos os pacotes da mesma inicialização do outro kernel, podemos ver claramente a diferença, e não sei o porquê.O problema é que não vejo muita diferença de carga de IO ou de CPU. / p>

Definindo o padrão kernel.sched_min_granularity_ns & kernel.sched_latency_ns de volta para ele é 2.6.32 valores ajuda um pouco (três vezes a carga em vez de 4 vezes), mas não para o nível que gostaríamos. Como muitas das configurações do kernel foram alteradas, dificilmente podemos definir cegamente o novo kernel para os valores padrão antigos do 2.6 one.

Alguém mais já teve experiência com isso? Se sim, o que causou isso (e idealmente: como isso poderia ser resolvido)?

Como é relacionado ao kernel, talvez uma diferença nos valores de sysctl possa ser interessante: aqui está um diff dos 2 (pastebinned para evitar uma questão excessivamente longa).

edit : no momento, estamos investigando isto SO responde para ver se isso se aplica.

    

Answer 1

Os kernels 3.0 - 3.8 do Linux devem ser evitados ou atualizados para resolver a degradação do desempenho da E / S

A degradação do desempenho do IO do kernel Linux demonstrada por Josh Berkus usando uma carga de trabalho de benchmark privada em execução no PostgreSQL 9.3 no Ubuntu 12.04 com o kernel 3.2.0.

"... você realmente precisa evitar todos os núcleos entre 3.0 e 3.8. Enquanto o RHEL tem aderido aos kernels 2.6 (que têm seus próprios problemas, mas não tão ruins quanto isso), o Ubuntu lançou vários 3.x os núcleos para 12.04 ... atualizaram ... para o kernel 3.13.0 e executaram a mesma carga de trabalho exata ... uma redução de 80% no IO. Podemos agradecer ao pessoal inteligente do grupo Linux FS / MM por martelar um todo muitos problemas de desempenho. "

Por favor, veja link

    

Answer 2

Eu abordei um problema no DBA StackExchange sobre o kernel e o registro no diário . Eu aprendi isso com Percona em maio que um certo comportamento de flush é realmente simulado.

• Talvez seja necessário alterar o modo de fazer o registro no diário.
• Você pode ter que ajustar o InnoDB
  • Diminuindo a conformidade com o ACID para desempenho de gravação (definindo innodb_flush_log_at_trx_commit como 0 ou 2)
  • Arquivos de registros maiores
  • Maior buffer de log

Answer 3

Talvez a carga reportada simplesmente não esteja correta, como neste relatório de bug: link

Você pode ver que há algo realmente mais lento? ou vmstat parece que o servidor está realmente fazendo mais trabalho? caso contrário, eu suponho que você acabou de acertar esse bug relatado, o mesmo aconteceu comigo há algum tempo, o desempenho do servidor não era diferente apenas a média de carga gerada era maior.

    

Answer 4

Eu não tenho a reputação de fazer isso como um comentário ... mas como você estava atualizando o kernel, você também atualizou a versão do MySQL? Você pode listar qual MySQL 5.5.X você está executando?

Ironicamente, bugs em algumas das versões mais recentes do MySQL tornaram o desempenho notavelmente pior. eles resolveram resolvê-los, é claro, mas criaram uma audição vermelha significativa para mim ao fazer alterações no meu aplicativo.

"InnoDB: A correção para o Bug # 17699331 causou uma alta taxa de criação e destruição de bloqueio de leitura / gravação que resultou em uma regressão de desempenho. (Bug # 18345645, Bug # 71708)"

link

"InnoDB: Uma regressão introduzida pelo Bug # 14329288 resultaria em uma degradação do desempenho quando uma tabela compactada não couber na memória. (Bug # 18124788, Bug # 71436)"

link

.. etc

É o mesmo para o 5.5:

"InnoDB: Uma regressão introduzida pelo Bug # 14329288 resultaria em uma degradação do desempenho quando uma tabela compactada não couber na memória. (Bug # 18124788, Bug # 71436)"

link

A atualização para um MySQL mais recente retorna a um desempenho razoável?

O MySQL também possui algum código específico do kernel:

"E / S assíncrona não é suportada em tmpfs em algumas versões do kernel Linux. A solução alternativa era desativar a configuração innodb_use_native_aio ou usar um diretório temporário diferente. A correção faz com que o InnoDB desative a configuração innodb_use_native_aio automaticamente se detectar que o diretório de arquivos temporários não suporta E / S assíncronas (Bug # 13593888, Bug # 11765450, Bug # 58421) "

" link

Então, garanto que você está executando a versão mais recente.

Como um aparte, considere o MySQL 5.6.X (que agora é oficialmente estável e já existe há algum tempo), "Para Linux, o MySQL 5.6 mostra uma melhoria de até 150% na taxa de transferência de TPS sobre o MySQL 5.5" link

    

Answer 5

Eu tive problemas enormes de performance no mysql passando do debian w / kernel 2.6 e mysql 5.1 para o debian w / kernel 3.2 e mysql 5.5 (wheezy).

O que resolveu o problema para o mysql foi barrier = 0 em / etc / fstab. Confira o link