ajuste de parâmetros - AWS Orientação prescritiva

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:

  1. Mude um parâmetro por vez para que você possa medir o impacto da mudança.

  2. 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.

  3. 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 recuperação para um ponto no tempo (PITR), mas o Aurora Edição 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 da réplica e a recuperação para um ponto no tempo (PITR), defina o valor 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 o banco de dados tiver um valor abaixo do ideal definido para table_open_cache, você verá um aumento regular no valor da variável opened_tables à medida que os encadeamentos simultâneos atingem os limites e é necessário fechar as tabelas menos usadas recentemente para abrir novas tabelas. Isso resulta em sobrecarga de operação no nível do sistema operacional, o que precisa ser evitado 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 e max_heap_table_size, o que for menor.

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_size e max_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.