Por que os threads do MySQL geralmente mostram o status "freeing items" quando o cache da consulta está desativado?

Quando executo SHOW PROCESSLIST, geralmente há um grande número de threads INSERT / UPDATE no estado "liberando itens".

O manual do MySQL sugere que pelo menos parte do motivo de um thread estar nesse estado envolve o cache de consultas - presumivelmente, isso invalidaria as consultas em cache devido aos dados alterados.

No entanto, meu query_cache_sizeé definido como 0, o que deve desabilitar completamente o cache da consulta.

Que outros motivos haveria para haver tantos threads nesse estado?

As tabelas relevantes usam o mecanismo de armazenamento InnoDB.

Verifique o valor de innodb_thread_concurrency.

Para o meu sistema, aumentar o valor de 8 para 32, de acordo com as diretrizes na documentação do MySql , causou uma diminuição discernível no número de threads que relatavam simultaneamente o estado "liberando itens". Além disso, o tempo médio de consulta dos obesos diminuiu em uma ordem de magnitude.

Embora isso tenha feito uma grande diferença no desempenho geral do servidor, não foi a bala de prata dos "itens liberados". Meu ecossistema de hardware me leva a supor que esse estado é visto principalmente em sistemas com discos "lentos" (2x10k discos RAID 1) e é menos prevalente em sistemas com armazenamento mais rápido (12x15k discos RAID 10). Portanto, uma verificação do desempenho do disco também pode ser garantida.

Boa sorte!

Além disso:

Vale a pena notar que o valor padrão de innodb_thread_concurrency é radicalmente diferente, dependendo do release de 5.0 pontos que está sendo usado.

O valor padrão foi alterado várias vezes: 8 antes do MySQL 5.0.8, 20 (infinito) de 5.0.8 a 5.0.18, 0 (infinito) de 5.0.19 a 5.0.20 e 8 (finito) de 5.0.21 em. - fonte

Isso significa que uma atualização aparentemente inócua de 5.0.20 para 5.0.21 alterou o padrão de infinito para 8 e trouxe consigo as ramificações de desempenho.

Liberar itens é um estágio de execução de consulta em que estruturas temporárias, buffers etc. são desalocadas. Alguns trabalhos de cache de consulta são feitos neste estágio, mas essa não é a única coisa que acontece lá. Eu sugeriria o uso de SHOW PROFILES para ver quanto tempo esse estágio leva em relação a outros estágios e, se o tempo consumido acabar sendo uma preocupação, a solução de problemas com ferramentas como o perfil do pobre homem e o oprofile.

Houve um relatório de bug sobre esse problema referente a "liberar itens" e o cache de consultas . Embora o bug esteja fechado, não houve menção a innodb_thread_concurrency .

Conincidentemente, conversei com Ronald Bradford no Percona Live NYC em maio. Eu contei a ele sobre uma situação em que tentei innodb_thread_concurrency porque o InnoDB Buffer Pool múltiplo do MySQL 5.5 produziu toneladas de bloqueios de encadeamento e suspeitei que os dados armazenados em cache de que eu necessitava provavelmente tivessem se espalhado pelos vários buffer pools.

Ele me disse claramente que eu nunca deveria definir valores contra innodb_thread_concurrency. Seja sempre o valor padrão, que agora é zero (0). Ao fazer isso, você permite que o armazenamento do InnoDB decida quantos innodb_concurrency_tickets serão gerados por conta própria. É isso que a simultaneidade infinita faz.

Provavelmente, 'liberando itens' ocorre com mais frequência quando impomos limites à innodb_thread_concurrency. Isso sempre deve ser zero (0). Eu correria um risco e aumentaria innodb_concurrency_tickets e veria se isso ajuda ou não.

Tivemos um problema com exatamente os mesmos sintomas. Verificou-se que o disco com os arquivos de log do InnoDB foi preenchido. Vale a pena conferir.

Outra dica: pode ser innodb fsync (). Tente configurar

innodb_flush_log_at_trx_commit = 2

Em my.cnf

O arquivo de log innodb é então liberado para o disco a cada 1-2 segundos, em vez de ob a cada confirmação. Pequena penalidade na integridade dos dados, grande ganho de velocidade.