Em quase todos os servidores de produção, é aconselhável desativar o cache de consulta. Toda modificação em uma tabela causa a eliminação de todos entradas de CQ para essa tabela. Quanto maior a mesa, mais tempo leva. 128M é perigosamente alto.
Normalmente, é aconselhável definir
innodb_buffer_pool_size para cerca de 70% dos disponíveis BATER. Você o definiu para um valor muito menor, ainda menor que o tamanho do conjunto de dados. 3G provavelmente ajudaria. 20G não ajudaria mais (até que seu conjunto de dados cresça significativamente). Certifique-se de que o SO e o MySQL sejam versões de 64 bits.
Para uma análise mais completa, forneça
- Tamanho da RAM (32G)
SHOW VARIABLES;SHOW GLOBAL STATUS;(depois de correr pelo menos 24 horas)
Análise de VARIÁVEIS e STATUS:
Os problemas mais importantes
Como você está usando apenas (?) InnoDB e apenas 2 GB de dados, não é crítico responder aos comentários sobre
innodb_buffer_pool_size e key_buffer_size Forneça mais alguns detalhes sobre seu uso intenso de
DELETE . Faça uso do slowlog para encontrar as 'piores' consultas. Mais detalhes aqui . Isso deve identificar os problemas de varredura de tabela e tmp_table mencionados abaixo.
Não se preocupe em usar
OPTIMIZE TABLE . Como você está fazendo "transações"? Às vezes com autocommit, às vezes com
COMMIT ? Detalhes e outras observações
( Key_blocks_used * 1024 / key_buffer_size ) = 4,710 * 1024 / 128M = 3.6% -- Porcentagem do key_buffer usado. Marca d'água alta.-- Diminua o key_buffer_size para evitar o uso desnecessário de memória. ( innodb_buffer_pool_size / _ram ) = 4096M / 32768M = 12.5% -- % de RAM usada para buffer_pool do InnoDB ( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) / _ram ) = (128M / 0.20 + 4096M / 0.70) / 32768M = 19.8% -- A maior parte da memória RAM disponível deve ser disponibilizada para armazenamento em cache.-- http://mysql. rjweb.org/doc.php/memory
( Innodb_buffer_pool_pages_free * 16384 / innodb_buffer_pool_size ) = 187,813 * 16384 / 4096M = 71.6% -- buffer pool livre-- buffer_pool_size é maior que o conjunto de trabalho; poderia diminuir ( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 7,144,121 / 29935426 = 23.9% -- Requisições de gravação que tiveram que atingir o disco -- Verifique innodb_buffer_pool_size ( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 1,199,046,656 / 4096M = 27.9% -- Porcentagem do buffer pool ocupado por dados -- Uma pequena porcentagem pode indicam que o buffer_pool é desnecessariamente grande. ( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 533,153 / 60 * 512M / 20356473344 = 234 -- Minutos entre as rotações de log do InnoDB A partir do 5.6.8, isso pode ser alterado dinamicamente; certifique-se de alterar também my.cnf.-- (A recomendação de 60 minutos entre as rotações é um tanto arbitrária.) Ajuste innodb_log_file_size. (Não é possível alterar na AWS.) ( Innodb_rows_deleted / Innodb_rows_inserted ) = 364,605 / 414950 = 0.879 -- Churn-- "Não faça fila, apenas faça." (Se o MySQL estiver sendo usado como uma fila.) ( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 247,373 / (247373 + 446152) = 35.7% -- Porcentagem de tabelas temporárias que vazaram para o disco -- talvez aumente tmp_table_size e max_heap_table_size; evitar bolhas, etc. ( Select_scan ) = 871,872 / 533153 = 1.6 /sec -- varreduras de tabela completas-- Adicione índices/otimize consultas (a menos que sejam tabelas pequenas) ( Select_scan / Com_select ) = 871,872 / 12593904 = 6.9% -- % de seleções fazendo varredura completa da tabela. (Pode ser enganado por rotinas armazenadas.) -- Adicionar índices/otimizar consultas ( Com_optimize ) = 216 / 533153 = 1.5 /HR -- Com que freqüência OPTIMIZE TABLE é executado. -- OPTIMIZE TABLE raramente é útil, certamente não em alta freqüência. ( long_query_time ) = 10.000000 = 10 -- Corte (segundos) para definir uma consulta "lenta". -- Sugestão 2 Extremos (sem comentários):
Anormalmente pequeno:
Com_commit = 2.5 /HR
Innodb_buffer_pool_pages_made_not_young = 0.15 /sec
Innodb_ibuf_merged_delete_marks = 27 /HR
Innodb_row_lock_time = 8
Innodb_row_lock_time_max = 1
interactive_timeout = 360
Anormalmente grande:
Com_rollback_to_savepoint = 14 /HR
Handler_savepoint_rollback = 14 /HR
join_cache_level = 8 (This may be unused? It was removed in 5.6.3, but possibly left in MariaDB 10.1?)
Cordas anormais:
Innodb_buffer_pool_dump_status = Dumping buffer pool(s) not yet started
Innodb_buffer_pool_load_status = Loading buffer pool(s) not yet started
innodb_checksum_algorithm = INNODB
innodb_cleaner_lsn_age_factor = HIGH_CHECKPOINT
innodb_empty_free_list_algorithm = BACKOFF
innodb_force_load_corrupted = OFF
innodb_foreground_preflush = EXPONENTIAL_BACKOFF
innodb_log_checksum_algorithm = INNODB
myisam_stats_method = NULLS_UNEQUAL
opt_s__engine_condition_pushdown = off
opt_s__mrr = off
opt_s__mrr_cost_based = off
Cache de consulta
Desde que foi desativado, nenhum dos valores de status do Qcache foi definido. Portanto, não posso responder à pergunta original. Se você quiser ligar o QC e reiniciar o servidor e esperar alguns dias, eu poderia reanalisar com ele ligado. Várias métricas sobre hits, ameixas etc. podem responda a pergunta original.
