A lentidão é devido ao trânsito todos os dias perto das 12h

Question

Análise de STATUS GLOBAL e VARIÁVEIS:

Observações:

Versão: 10.4.12-MariaDB
32 GB de RAM
Tempo de atividade = 19d 23:11:43
Parece que você está executando o MyISAM e o InnoDB.
240 QPS

As questões mais importantes:

Mude long_query_timepara 1para poder capturar mais consultas no slowlog. (Você tem 10 segundos agora; isso provavelmente explica por que você encontrou apenas 4 consultas.) Existem vários indícios de que algumas das consultas estão sendo executadas de forma ineficiente. Esta é uma maneira de encontrar essas consultas: http://mysql.rjweb.org/doc.php/mysql_análise#slow_queries_and_slowlog

Por que você está usando MyISAM? Os valores são confusos - é como se você [re]construísse um índice para uma grande tabela MyISAM, mas não fizesse muito mais. Na maioria dos casos, é melhor usar o InnoDB.

innodb_buffer_pool_sizeprovavelmente pode ser aumentado para melhorar a velocidade de consulta do InnoDB.

Tenha cuidado com isso general_log- ele enche o disco rapidamente.

O "Query Cache" está funcionando de forma ineficiente. Eu recomendo desligá-lo completamente: query_cache_type=offe query_cache_size=0.

Max_used_connectionsatingiu 152, indicando que muitos usuários estão conectados ao mesmo tempo. (Isso não significa que 152 consultas estavam sendo executadas simultaneamente.)

Detalhes e outras observações:

Conversão de MyISAM para InnoDB ( Key_blocks_used * 1024 / key_buffer_size ) = 460 * 1024 / 128M = 0.35%-- Porcentagem de key_buffer usado. Marca d'água alta. -- Reduza key_buffer_size (agora 134217728) para evitar uso desnecessário de memória.

( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) ) = ((128M / 0.20 + 8192M / 0.70)) / 32768M = 37.7%-- A maior parte da memória RAM disponível deve ser disponibilizada para cache. --http://mysql.rjweb.org/doc.php/memory

( general_log ) = general_log = ON-- Log (FILE ou TABLE) de todas as consultas executadas. -- Desligue o general_log (agora LIGADO) quando não estiver em uso. Esse log pode preencher o disco muito rapidamente.

( innodb_buffer_pool_size ) = 8,192 / 32768M = 25.0%-- % de RAM usada para InnoDB buffer_pool -- Definido para cerca de 70% da RAM disponível. (Muito baixo é menos eficiente; muito alto corre o risco de troca.)

`( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) ) = ((128M / 0.20 + 8192M / 0.70)) / 32768M = 37.7%`-- (métrica para avaliar o uso de RAM)

( innodb_lru_scan_depth * innodb_page_cleaners ) = 1,024 * 4 = 4,096-- Quantidade de trabalho para limpadores de páginas a cada segundo. - "InnoDB: page_cleaner: loop pretendido de 1000ms levado ..." pode ser corrigido diminuindo lru_scan_profundidade: Considere 1000 / innodb_page_cleaners (agora 4). Verifique também se há troca.

( innodb_lru_scan_depth ) = 1,024 - "InnoDB: page_cleaner: loop pretendido de 1000ms levado ..." pode ser corrigido diminuindo lru_scan_profundidade

( innodb_io_capacity ) = 200-- Ao lavar, use esta quantidade de IOPs. - As leituras podem ser lentas ou pontiagudas.

( Innodb_log_writes ) = 43,856,157 / 1725103 = 25 /sec

( Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group / innodb_log_file_size ) = 137,804,939,264 / (1725103 / 3600) / 2 / 48M = 2.86-- Proporção -- (ver ata)

( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 1,725,103 / 60 * 48M / 137804939264 = 10.5-- Minutos entre rotações de log do InnoDB A partir da versão 5.6.8, isso pode ser alterado dinamicamente; certifique-se de alterar também my.cnf. -- (A recomendação de 60 minutos entre rotações é um tanto arbitrária.) Ajuste innodb_log_file_size (agora 50331648). (Não é possível alterar na AWS.)

( innodb_flush_method ) = innodb_flush_method = fsync-- Como o InnoDB deve solicitar ao sistema operacional para escrever blocos. Sugira O_DIRECT ou O_ALL_DIRECT (Percona) para evitar buffer duplo. (Pelo menos para Unix.) Consulte chrischandler para advertências sobre O_ALL_DIRECT

( default_tmp_storage_engine ) = default_tmp_storage_engine =

( innodb_flush_neighbors ) = 1-- Uma pequena otimização ao gravar blocos no disco. -- Use 0 para unidades SSD; 1 para HDD.

( innodb_io_capacity ) = 200- Capacidade de operações de E/S por segundo no disco. 100 para unidades lentas; 200 para unidades giratórias; 1000-2000 para SSDs; multiplique pelo fator RAID.

( innodb_adaptive_hash_index ) = innodb_adaptive_hash_index = ON-- Geralmente deve estar LIGADO. -- Há casos em que OFF é melhor. Veja também innodb_adaptive_hash_index_parts (agora 8) (após 5.7.9) e innodb_adaptive_hash_index_partitions (MariaDB e Percona). ON foi implicado em travamentos raros (bug 73890). 10.5.0 decidiu desativar como padrão.

( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF-- Se deseja registrar todos os impasses. - Se você está atormentado com Deadlocks, ative esta opção. Cuidado: Se você tiver muitos deadlocks, isso poderá gravar muito no disco.

( character_set_server ) = character_set_server = latin1 -- Problemas de Charset podem ser resolvidos definindo character_set_server (agora latin1) como utf8mb4. Esse é o padrão futuro.

( local_infile ) = local_infile = ON -- local_infile (agora ON) = ON é um possível problema de segurança

( Key_blocks_used * 1024 / key_buffer_size ) = 460 * 1024 / 128M = 0.35%-- Porcentagem de key_buffer usado . Marca d'água alta. -- Reduza key_buffer_size (agora 134217728) para evitar uso desnecessário de memória.

( Key_writes / Key_write_requests ) = 19,978,377 / 40284646 = 49.6%-- eficácia do key_buffer para gravações -- Se você tiver RAM suficiente, valeria a pena aumentar o key_buffer_size (agora 134217728).

( query_cache_size ) = 524,288 = 0.5MB-- Tamanho do CQ -- Muito pequeno = não tem muita utilidade. Muito grande = muita sobrecarga. Recomendo 0 ou não mais que 50 milhões.

( Qcache_lowmem_prunes ) = 125,234,412 / 1725103 = 73 /sec-- Ficando sem espaço no QC -- aumente query_cache_size (agora 524288)

( Qcache_lowmem_prunes/Qcache_inserts ) = 125,234,412/146211296 = 85.7%-- Taxa de remoção (frequência de necessidade de remoção devido à falta de memória)

( Qcache_not_cached ) = 78,413,835 / 1725103 = 45 /sec-- SQL_CACHE tentou, mas foi ignorado -- Repensar o cache; sintonizar qcache

( Qcache_hits / Qcache_inserts ) = 37,201,050 / 146211296 = 0.254-- Proporção de ocorrências para inserção -- alto é bom -- Considere desligar o cache de consulta.

( Qcache_hits / (Qcache_hits + Com_select) ) = 37,201,050 / (37201050 + 282029692) = 11.7%-- Taxa de acertos -- SELECTs que usaram QC -- Considere desligar o cache de consulta.

( Qcache_hits / (Qcache_hits + Qcache_inserts + Qcache_not_cached) ) = 37,201,050 / (37201050 + 146211296 + 78413835) = 14.2%- Taxa de acertos do cache de consulta - Provavelmente é melhor desligar o QC.

( (query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache / query_alloc_block_size ) = (524288 - 78344) / 82 / 16384 = 0.332-- query_alloc_block_size vs fórmula -- Ajuste query_alloc_block_size (agora 16384)

( Created_tmp_tables ) = 96,501,765 / 1725103 = 56 /sec-- Frequência de criação de tabelas "temp" como parte de SELECTs complexos.

( Created_tmp_disk_tables ) = 23,539,653 / 1725103 = 14 /sec- Frequência de criaçãodiscoTabelas "temp" como parte de SELECTs complexos - aumente tmp_table_size (agora 16777216) e max_heap_table_size (agora 16777216). Verifique as regras para tabelas temporárias quando MEMORY é usado em vez de MyISAM. Talvez pequenas alterações no esquema ou na consulta possam evitar o MyISAM. Melhores índices e reformulação de consultas têm maior probabilidade de ajudar.

( Created_tmp_disk_tables / Questions ) = 23,539,653 / 414140316 = 5.7%-- Porcentagem de consultas que precisavam de tabela tmp no disco. -- Melhores índices/Sem blobs/etc.

( Select_full_join / Com_select ) = 30,333,225 / 282029692 = 10.8%-- % de seleções que são junções sem índice -- Adiciona índice(s) adequado(s) às tabelas usadas em JOINs.

( Com_insert + Com_delete + Com_delete_multi + Com_replace + Com_update + Com_update_multi ) = (87669877 + 27242 + 0 + 0 + 1452911 + 0) / 1725103 = 52 /sec-- gravações/seg -- 50 gravações/seg + liberações de log provavelmente maximizarão a capacidade de gravação de E/S das unidades HDD. Se você tiver SSD, essa métrica provavelmente será adequada.

( binlog_format ) = binlog_format = MIXED-- DECLARAÇÃO/LINHA/MISTA. - ROW é preferido por 5,7 (10,3)

( long_query_time ) = 10-- Corte (segundos) para definir uma consulta "lenta". - Sugestão 2

( Max_used_connections / max_connections ) = 152 / 151 = 100.7%-- Pico % de conexões -- aumente max_connections (agora 151) e/ou diminua wait_timeout (agora 28.800). Ou acelere as consultas.

( Connections ) = 11,987,448 / 1725103 = 6.9 /sec-- Conexões -- Aumenta wait_timeout (agora 28800); usar pooling?

( Connection_errors_accept + Connection_errors_internal + Connection_errors_peer_address + Connection_errors_select + Connection_errors_tcpwrap ) = 0 + 26 + 0 + 0 + 0 = 26-- Erros de conexão diferentes de max_connections. -- Para mais informações, consulte MOSTRAR STATUS GLOBAL LIKE 'Connection_errors%'

Anormalmente pequeno:

Created_tmp_files = 0.094 /HR
innodb_spin_wait_delay = 4

Anormalmente grande:

Aria_pagecache_writes = 34 /sec
Aria_transaction_log_syncs = 25,641
Com_show_warnings = 40 /HR
Connection_errors_internal = 0.054 /HR
Handler_read_key = 85109 /sec
Handler_tmp_update = 839 /sec
Innodb_buffer_pool_read_requests = 675158 /sec
Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads ) = 100.0%
Innodb_rows_updated = 356 /sec
performance_schema_max_cond_classes = 90

Sequências anormais:

Innodb_have_punch_hole = OFF
aria_recover_options = BACKUP,QUICK
disconnect_on_expired_password = OFF
ft_boolean_syntax = + -><()~*:
innodb_fast_shutdown = 1
log_output = TABLE
myisam_stats_method = NULLS_UNEQUAL
old_alter_table = DEFAULT
optimizer_trace = enabled=off

Answer 1

Análise de STATUS GLOBAL e VARIÁVEIS:

Observações:

Versão: 10.4.12-MariaDB
32 GB de RAM
Tempo de atividade = 19d 23:11:43
Parece que você está executando o MyISAM e o InnoDB.
240 QPS