Início / dba / Perguntas / 63415
Accepted
Michal Charemza
Asked: 2014-04-18 04:45:59 +0800 CST

Como decidir se deseja habilitar o cache de consulta do MySQL usando o InnoDB

  • 772

Como deve ser tomada a decisão de habilitar/desabilitar o cache de query do MySQL, em um servidor que utiliza apenas tabelas InnoDB. Digamos, por exemplo, se o cache estiver ativado, como deve ser a saída de:

SHOW STATUS LIKE 'Qcache%';

ser interpretado para tomar a decisão? Ou que outras consultas/criação de perfil podem ser realizadas para obter mais informações e, em seguida, como devem ser interpretadas? Se for habilitado, como seu tamanho deve ser determinado? Estou no Amazon RDS, usando MySQL 5.6. Vou acabar tendo cerca de ~ 250 bancos de dados separados, totalizando ~ 200 GB de espaço.

mysql innodb

3 respostas

  1. Best Answer

    SHOW GLOBAL STATUS;

    Em seguida, calcule estes (seja usando MyISAM ou InnoDB):

    • Qcache_lowmem_prunes / Uptime-- Com que frequência o QC está sendo podado -- Mais de 15/s diz que há muita sobrecarga em ter o QC ativado.
    • Qcache_not_cached / Uptime-- Falha nas tentativas de cache (por segundo). >40 é provavelmente ruim.
    • Qcache_not_cached / (Qcache_hits + Com_select + Qcache_not_cached)-- Porcentagem SELECTsdisso não é armazenada em cache no QC -- >30% significa que o QC não é muito útil.
    • Qcache_hits / Qcache_inserts-- Hit to insert ratio -- > 10 é desejável
    • 5

  2. Eu tinha discutido isso em posts anteriores

    Os internos do InnoDB têm uma abordagem muito prática para o cache de consulta, pois microgerencia a invalidação da entrada do cache de consulta. Nos dias do MySQL 4.x, o cache de consulta foi desabilitado por padrão por causa do InnoDB. No MySQL 5.x, pode ser difícil. Os comentários de @akuzminsky mostram que os problemas locais giram em torno do InnoDB.

    Considerando que você está usando o Amazon RDS, você encontra os seguintes desafios

    • Alterar algumas configurações do InnoDB pode ser complicado
    • Algumas configurações do InnoDB não podem ser alteradas
    • Os aspectos de ajuste do InnoDB têm limites devido ao RDS

    Eu eliminaria qualquer trabalho de adivinhação e apenas deixaria o cache de consulta desativado. Se tiver um buffer pool maior (conforme sugerido no segundo comentário de @akuzminsky), você terá que migrar para um modelo de servidor maior ($$$ Cha-Ching $$$). Aqui estão os tamanhos do buffer pool para os modelos de servidor

    MODEL      max_connections innodb_buffer_pool_size
---------  --------------- -----------------------
t1.micro   34                326107136 (  311M)
m1-small   125              1179648000 ( 1125M,  1.097G)
m1-large   623              5882511360 ( 5610M,  5.479G)
m1-xlarge  1263            11922309120 (11370M, 11.103G)
m2-xlarge  1441            13605273600 (12975M, 12.671G)
m2-2xlarge 2900            27367833600 (26100M, 25.488G)
m2-4xlarge 5816            54892953600 (52350M, 51.123G)
    • 4

  3. Realmente depende da divisão de leitura e gravação em seus dados em geral. Se a leitura for pesada, você economiza a carga da CPU no RDS usando o query_cache de maneira inteligente. No entanto, eu nunca recomendaria torná-lo padrão para ON, mas sim usar DEMAND (número 2 no parâmetro RDS) dessa forma, você pode usar SQL_CACHE em suas instruções de seleção para consultas particularmente complicadas para evitar potencialmente ir para o disco (que é muito lento em RDS geralmente) embora ainda não tenha query_cache e a expiração de dados assuma seu banco de dados de maneira fora de controle.

    O uso da opção 2 deve permitir que você mantenha seu query_cache_size pequeno e evite remoções enquanto ainda fornece espaço suficiente para que seus piores resultados de execução de consulta sejam armazenados em cache. Em uma situação de leitura pesada, isso rendeu bons aumentos de velocidade para nossas consultas mais lentas com um banco de dados RDS de 500 GB, sem sobrecarregar o sistema ao mesmo tempo.

    HTH

    • 2

relate perguntas