As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
ajuste de parâmetros
Além dos parâmetros relacionados à conexão, há alguns parâmetros que você pode ajustar para melhorar a performance do seu cluster do Amazon Aurora Edição Compatível com MySQL quando confrontado com o crescimento excessivo. Ao alterar qualquer parâmetro do banco de dados, é importante usar as seguintes práticas recomendadas:
-
Mude um parâmetro por vez para que você possa medir o impacto da mudança.
-
Alguns parâmetros podem exigir um período de aquecimento para manifestar seu efeito após serem alterados. Considere isso ao observar e medir a performance do seu cluster compatível com o Aurora Edição Compatível com MySQL.
-
Evite valores de parâmetros incorretos, o que pode impedir a inicialização da instância do banco de dados.
As seções a seguir discutem alguns parâmetros muito importantes e como você pode ajustá-los para melhorar a performance.
Desabilitar logs binários
Nas implementações tradicionais do MySQL, o log binário serve funções críticas, como alta disponibilidade (HA) e point-in-time recuperação (PITR), mas o Aurora compatível com MySQL não depende do binlog para HA e PITR. No Aurora Edição Compatível com MySQL, o log binário é valioso apenas para fornecer captura de dados de alterações (CDC) para sistemas downstream. Portanto, a desativação do binlog melhora a performance da instância do gravador.
sync_binlog
Se você estiver preocupado com a consistência e point-in-time recuperação da réplica (PITR), defina o. sync_binlog=1 No entanto, se você não se importa em perder alguns eventos dos logs binários durante uma falha grave, é possível melhorar a performance definindo sync_binlog=0.
table_open_cache
O parâmetro table_open_cache está relacionado ao parâmetro max_connections. Por exemplo, se uma instância de banco de dados tiver 100 conexões simultâneas, o valor ideal de table_open_cache será 100 * N, onde N é o número máximo de tabelas que participam de consultas de união que atendem à sua aplicação
Se seu banco de dados tiver menos do que o valor ideal definido para table_open_cache, você verá um aumento regular no valor da opened_tables variável à medida que os encadeamentos simultâneos atingirem os limites e precisarem fechar as least-recently-used tabelas para abrir novas tabelas. Isso resulta em sobrecarga de operating-system-level operação, que precisa ser evitada em alta simultaneidade. Se você achar que isso está acontecendo em seu banco de dados, aumente a variável table_open_cache para permitir uma melhor performance do MySQL em alta simultaneidade.
Se o valor for o ideal, será possível observar um aumento muito pequeno na variável opened_tables. Essa é uma variável dinâmica no grupo de parâmetros do banco de dados. Assim, não é necessário reiniciar sua instância para observar o efeito das alterações feitas nessa variável.
innodb_sync_array_size
Recomendamos aumentar o valor para workloads altamente simultâneas, nas quais um grande número de threads é encontrado frequentemente em espera. O valor padrão do parâmetro innodb_sync_array_size é 1. Para grandes workloads simultâneas, o valor padrão pode causar contenção. Para encontrar o valor ideal para esse parâmetro, execute o teste de carga.
innodb_flush_log_at_trx_commit
Esse parâmetro oferece três opções. Você deve decidir se deseja otimizar a performance ou a durabilidade. Se você preferir durabilidade em vez de performance, defina innodb_flush_log_at_trx_commit para 1. Isso garantirá que os logs sejam gravados e liberados no disco após a confirmação de uma transação bem-sucedida.
Quando innodb_flush_log_at_trx_commit está definido como 0, o InnoDB grava registros e os libera para o disco uma vez a cada segundo. Se innodb_flush_log_at_trx_commit está definido como 2, o InnoDB grava entradas de log imediatamente após a emissão de uma confirmação e as libera para o disco uma vez a cada segundo.
O valor 2 significa não descarregar e não sincronizar imediatamente quando uma confirmação é recebida (novamente, nenhuma E/S real é executada na confirmação).
No Aurora Edição Compatível com MySQL, recomendamos manter innodb_flush_log_at_trx_commit=1.
confirmação automática
Desativar autocommit não é recomendado porque incentiva transações de longa duração. Quando a opção autocommit está desativada, a conexão está sempre “em transação”. As transações abertas podem levar a consumo excessivo de armazenamento, alta utilização da CPU e lentidão nas consultas. Com a opção autocommit ativada, cada instrução SQL é executada em sua própria transação.
A coleta de resíduos resultante de transações de longa duração pode ser monitorada por meio da métrica RollbackSegmentHistoryListLength.
tmp_table_size e max_heap_table_size
Quando uma consulta complexa é executada, uma tabela temporária é criada como uma tabela na memória. Quando a tabela temporária se torna muito grande, ela é automaticamente convertida em uma tabela em disco. As consultas envolvendo tabelas em disco são mais lentas do que as que usam tabelas temporárias na memória.
O tamanho das tabelas temporárias na memória é determinado pelo valor de tmp_table_size
Para ver a criação de tabelas temporárias na memória e no disco, use a consulta a seguir.
mysql> SHOW GLOBAL STATUS LIKE 'Created_tmp%'; +-------------------------+--------+ | Variable_name | Value | +-------------------------+--------+ | Created_tmp_disk_tables | 826 | | Created_tmp_files | 5 | | Created_tmp_tables | 168754 | +-------------------------+--------+ 3 rows in set (0.01 sec)
Se o valor de Created_tmp_disk_tables for alto, aumente as variáveis para tmp_table_sizemax_heap_table_size.
Se você estiver usando o tamanho de computação correto com código ajustado, essas pequenas alterações poderão melhorar a performance do seu servidor de banco de dados.
