Ajuste de desempenho do banco de dados para MariaDB

Desde que o MySQL foi originalmente bifurcado para formar o MariaDB, ele tem sido amplamente suportado e adotado rapidamente por um grande público na comunidade de banco de dados de código aberto. Originalmente um substituto imediato, o MariaDB começou a criar distinção em relação ao MySQL, especialmente com o lançamento do MariaDB 10.2.

Apesar disso, no entanto, ainda não há diferença reveladora real entre MariaDB e MySQL, pois ambos têm mecanismos compatíveis e podem ser executados nativamente um com o outro. Portanto, não se surpreenda se o ajuste de sua configuração do MariaDB tiver uma abordagem semelhante a um ajuste do MySQL.

Este blog discutirá o ajuste do MariaDB, especificamente os sistemas executados em um ambiente Linux.

Otimização de hardware e sistema do MariaDB

MariaDB recomenda que você melhore seu hardware na seguinte ordem de prioridade...

Memória

A memória é o fator mais importante para bancos de dados, pois permite ajustar as variáveis ​​do sistema do servidor. Mais memória significa caches de chave e tabela maiores, que são armazenados na memória para que os discos possam acessar, uma ordem de magnitude mais lenta, sendo posteriormente reduzidos.

Tenha em mente, porém, que simplesmente adicionar mais memória pode não resultar em melhorias drásticas se as variáveis ​​do servidor não estiverem configuradas para usar a memória extra disponível.

Usar mais slots de RAM na placa-mãe aumenta a frequência do barramento e haverá mais latência entre a RAM e a CPU. Isso significa que é preferível usar o maior tamanho de RAM por slot.

Discos

O acesso rápido ao disco é fundamental, pois, em última análise, é onde os dados residem. O índice é o tempo de busca do disco (uma medida de quão rápido o disco físico pode se mover para acessar os dados), então escolha discos com o menor tempo de busca possível. Você também pode adicionar discos dedicados para arquivos temporários e logs de transações.

Fast Ethernet

Com os requisitos adequados para sua largura de banda de internet, fast ethernet significa que pode ter uma resposta mais rápida às solicitações dos clientes, tempo de resposta de replicação para ler logs binários nos escravos, tempos de resposta mais rápidos também são muito importantes, especialmente no Galera baseados em clusters.

CPU

Embora os gargalos de hardware geralmente caiam em outros lugares, processadores mais rápidos permitem que os cálculos sejam executados mais rapidamente e os resultados sejam enviados de volta ao cliente mais rapidamente. Além da velocidade do processador, a velocidade do barramento do processador e o tamanho do cache também são fatores importantes a serem considerados.

Configurando seu Agendador de E/S de disco

Os agendadores de E/S existem como uma forma de otimizar as solicitações de acesso ao disco. Ele mescla solicitações de E/S para locais semelhantes no disco. Isso significa que a unidade de disco não precisa procurar com tanta frequência e melhora um enorme tempo de resposta geral e economiza operações de disco. Os valores recomendados para desempenho de E/S são noop e deadline.

noop é útil para verificar se decisões complexas de programação de E/S de outros programadores não estão causando regressões de desempenho de E/S. Em alguns casos, pode ser útil para dispositivos que fazem agendamento de E/S por conta própria, como armazenamento inteligente, ou dispositivos que não dependem de movimento mecânico, como SSDs. Normalmente, o agendador DEADLINE I/O é a melhor escolha para esses dispositivos, mas devido à menor sobrecarga, o NOOP pode produzir melhor desempenho em determinadas cargas de trabalho.

Para prazo, é um escalonador de E/S orientado à latência. Cada solicitação de E/S tem um prazo atribuído. Normalmente, as solicitações são armazenadas em filas (leitura e gravação) classificadas por números de setor. O algoritmo DEADLINE mantém duas filas adicionais (leitura e gravação) onde as solicitações são classificadas por prazo. Desde que nenhuma solicitação tenha expirado, a fila “setor” é usada. Se ocorrerem tempos limite, as solicitações da fila “deadline” serão atendidas até que não haja mais solicitações expiradas. Geralmente, o algoritmo prefere leituras sobre gravações.

Para dispositivos PCIe (unidades SSD NVMe), eles têm suas próprias grandes filas internas juntamente com um serviço rápido e não requerem ou se beneficiam da configuração de um agendador de E/S. Recomenda-se não ter nenhum parâmetro de configuração explícito do modo do planejador.

Você pode verificar a configuração do seu agendador com:

cat /sys/block/${DEVICE}/queue/scheduler

Por exemplo, deve se parecer com esta saída:

cat /sys/block/sda/queue/scheduler

[noop] deadline cfq

Para torná-lo permanente, edite o arquivo de configuração /etc/default/grub, procure a variável GRUB_CMDLINE_LINUX e adicione o elevador como abaixo:

GRUB_CMDLINE_LINUX="elevator=noop"

Aumentar o limite de arquivos abertos

Para garantir um bom desempenho do servidor, o número total de conexões de clientes, arquivos de banco de dados e arquivos de log não deve exceder o limite máximo do descritor de arquivo no sistema operacional (ulimit -n). Os sistemas Linux limitam o número de descritores de arquivo que qualquer processo pode abrir para 1.024 por processo. Em servidores de banco de dados ativos (especialmente os de produção), pode facilmente atingir o limite padrão do sistema.

Para aumentar isso, edite /etc/security/limits.conf e especifique ou adicione o seguinte:

mysql soft nofile 65535

mysql hard nofile 65535

Isso requer uma reinicialização do sistema. Depois, você pode confirmar executando o seguinte:

$ ulimit -Sn

65535

$ ulimit -Hn

65535

Opcionalmente, você pode definir isso via mysqld_safe se estiver iniciando o processo mysqld através do mysqld_safe,

[mysqld_safe]

open_files_limit=4294967295

ou se você estiver usando systemd,

sudo tee /etc/systemd/system/mariadb.service.d/limitnofile.conf <<EOF

[Service]



LimitNOFILE=infinity

EOF

sudo systemctl daemon-reload

Configurando Swappiness no Linux para MariaDB

Linux Swap desempenha um grande papel em sistemas de banco de dados. Ele age como seu pneu sobressalente em seu veículo, quando vazamentos de memória desagradáveis ​​interferem no seu trabalho, a máquina fica mais lenta... mas na maioria dos casos ainda será utilizável para terminar sua tarefa atribuída.

Para aplicar as alterações ao seu swappiness, basta executar,

sysctl -w vm.swappiness=1

Isso acontece dinamicamente, sem a necessidade de reinicializar o servidor. Para torná-lo persistente, edite /etc/sysctl.conf e adicione a linha,

vm.swappiness=1

É bastante comum definir swappiness=0, mas desde o lançamento de novos kernels (ou seja, kernels> 2.6.32-303), foram feitas alterações, então você precisa definir vm.swappiness=1.

Otimizações do sistema de arquivos para MariaDB

Os sistemas de arquivos mais comuns usados ​​em ambientes Linux que executam MariaDB são ext4 e XFS. Existem também algumas configurações disponíveis para implementar uma arquitetura usando ZFS e BRTFS (conforme referenciado na documentação do MariaDB).

Além disso, a maioria das configurações de banco de dados não precisa registrar o tempo de acesso ao arquivo. Você pode querer desabilitar isso ao montar o volume no sistema. Para fazer isso, edite seu arquivo /etc/fstab. Por exemplo, em um volume chamado /dev/md2, fica assim:

/dev/md2 / ext4 defaults,noatime 0 0

Criando uma instância ideal do MariaDB

Armazenar dados em um volume separado

É sempre ideal separar os dados do banco de dados em um volume separado. Este volume é especificamente para esses tipos de volumes de armazenamento rápido, como placas SSD, NVMe ou PCIe. Por exemplo, se todo o volume do seu sistema falhar, você terá seu volume de banco de dados seguro e com a certeza de que não será afetado caso seu hardware de armazenamento falhe.

Ajuste o MariaDB para utilizar a memória com eficiência

innodb_buffer_pool_size

O valor primário a ser ajustado em um servidor de banco de dados com tabelas inteiramente/principalmente XtraDB/InnoDB, pode ser configurado em até 80% da memória total nesses ambientes. Se configurado para 2 GB ou mais, você provavelmente desejará ajustar innodb_buffer_pool_instances também. Você pode definir isso dinamicamente se estiver usando MariaDB>=versão 10.2.2. Caso contrário, será necessário reiniciar o servidor.

tmp_memory_table_size/max_heap_table_size

Para tmp_memory_table_size (tmp_table_size), se você estiver lidando com grandes tabelas temporárias, definir este valor mais alto fornece ganhos de desempenho, pois será armazenado na memória. Isso é comum em consultas que usam muito GROUP BY, UNION ou subconsultas. Embora se max_heap_table_size for menor, o limite inferior será aplicado. Se uma tabela exceder o limite, o MariaDB a converte em uma tabela MyISAM ou Aria. Você pode ver se é necessário aumentar comparando as variáveis ​​de status Created_tmp_disk_tables e Created_tmp_tables para ver quantas tabelas temporárias do total criado precisavam ser convertidas em disco. Frequentemente, consultas GROUP BY complexas são responsáveis ​​por exceder o limite.

Enquanto max_heap_table_size, este é o tamanho máximo para tabelas MEMORY criadas pelo usuário. O valor definido nesta variável é aplicável apenas para as tabelas recém-criadas ou recriadas e não para as existentes. O menor de max_heap_table_size e tmp_table_size também limita as tabelas internas na memória. Quando o tamanho máximo for atingido, qualquer outra tentativa de inserir dados receberá um erro "tabela... está cheia". As tabelas temporárias criadas com CREATE TEMPORARY não serão convertidas para Aria, como ocorre com as tabelas temporárias internas, mas também receberão um erro de tabela cheia.

innodb_log_file_size

Grandes memórias com processamento de alta velocidade e disco de E/S rápido não são novidade e tem seu preço razoável como recomenda. Se você preferir mais ganhos de desempenho, especialmente durante e lidar com suas transações InnoDB, é razoável definir a variável innodb_log_file_size para um valor maior, como 5Gib ou até 10GiB. Aumentar significa que as transações maiores podem ser executadas sem a necessidade de executar E/S de disco antes de confirmar.

join_buffer_size

Em alguns casos, suas consultas tendem a não usar a indexação adequada ou, simplesmente, há instâncias em que você precisa que essa consulta seja executada. A menos que seja fortemente chamado ou invocado da perspectiva do cliente, definir essa variável é melhor em nível de sessão. Aumente-o para obter junções completas mais rápidas quando não for possível adicionar índices, embora esteja ciente dos problemas de memória, pois as junções sempre alocarão o tamanho mínimo.

Defina seu max_allowed_packet

MariaDB tem a mesma natureza do MySQL ao lidar com pacotes. Ele divide os dados em pacotes e o cliente deve estar ciente do valor da variável max_allowed_packet. O servidor terá um buffer para armazenar o corpo com tamanho máximo correspondente a este valor max_allowed_packet. Se o cliente enviar mais dados do que o tamanho max_allowed_packet, o soquete será fechado. A diretiva max_allowed_packet define o tamanho máximo do pacote que pode ser enviado.

Definir este valor muito baixo pode fazer com que uma consulta pare e feche sua conexão de cliente, o que é bastante comum para receber erros como ER_NET_PACKET_TOO_LARGE ou Conexão perdida com o servidor MySQL durante a consulta. Idealmente, especialmente na maioria das demandas de aplicativos atuais, você pode começar a configurar isso para 512MiB. Se for um tipo de aplicação de baixa demanda, basta usar o valor padrão e definir esta variável somente via sessão quando necessário se os dados a serem enviados ou recebidos forem muito grandes que o valor padrão (16MiB desde MariaDB 10.2.4). Em certas cargas de trabalho que demandam grandes pacotes para serem processados, então você precisa ajustar seu maior de acordo com suas necessidades principalmente quando estiver em replicação. Se max_allowed_packet for muito pequeno no escravo, isso também fará com que o escravo pare o encadeamento de E/S.

Usando o pool de threads

Em alguns casos, esse ajuste pode não ser necessário ou recomendado para você. Os pools de threads são mais eficientes em situações em que as consultas são relativamente curtas e a carga é vinculada à CPU (cargas de trabalho OLTP). Se a carga de trabalho não estiver vinculada à CPU, você ainda poderá limitar o número de encadeamentos para economizar memória para os buffers de memória do banco de dados.

Usar o pool de threads é uma solução ideal, especialmente se o seu sistema estiver passando por troca de contexto e você estiver encontrando maneiras de reduzir isso e manter um número menor de threads do que o número de clientes. No entanto, esse número também não deve ser muito baixo, pois também queremos aproveitar ao máximo as CPUs disponíveis. Portanto, deve haver, idealmente, um único thread ativo para cada CPU na máquina.

Você pode definir thread_pool_max_threads, thread_pool_min_threads para o número máximo e mínimo de threads. Ao contrário do MySQL, isso está presente apenas no MariaDB.

Defina a variável thread_handling que determina como o servidor lida com threads para conexões de clientes. Além de threads para conexões de clientes, isso também se aplica a certos threads internos do servidor, como os threads escravos do Galera.

Ajuste seu cache de tabela + max_connections

Se você estiver enfrentando ocorrências ocasionais na lista de processos sobre os status de tabelas de abertura e fechamento de tabelas, isso pode significar que você precisa aumentar seu cache de tabela. Você pode monitorar isso também através do prompt do cliente mysql executando SHOW GLOBAL STATUS LIKE 'Open%table%'; e monitorar as variáveis ​​de status.

Para max_connections, se seu aplicativo requer muitas conexões simultâneas, você pode começar a configurar para 500.

Para table_open_cache, deve ser o número total de suas tabelas, mas é melhor adicionar mais dependendo do tipo de consulta que você atende, pois as tabelas temporárias também devem ser armazenadas em cache. Por exemplo, se você tiver 500 tabelas, seria razoável começar com 1500.

Enquanto seu table_open_cache_instances, comece a defini-lo para 8. Isso pode melhorar a escalabilidade reduzindo a contenção entre sessões, o cache de tabelas abertas pode ser particionado em várias instâncias de cache menores de tamanho table_open_cache / table_open_cache_instances.

Para o InnoDB, table_definition_cache atua como um limite flexível para o número de instâncias de tabela abertas no cache do dicionário de dados do InnoDB. O valor a ser definido definirá o número de definições de tabela que podem ser armazenadas no cache de definição. Se você usar um grande número de tabelas, poderá criar um cache de definição de tabela grande para acelerar a abertura de tabelas. O cache de definição de tabela ocupa menos espaço e não usa descritores de arquivo, ao contrário do cache de tabela normal. O valor mínimo é 400. O valor padrão é baseado na seguinte fórmula, limitada a um limite de 2000:

MIN(400 + table_open_cache / 2, 2000)

Se o número de instâncias de tabela abertas exceder a configuração table_definition_cache, o mecanismo LRU começará a marcar instâncias de tabela para remoção e, eventualmente, as removerá do cache do dicionário de dados. O limite ajuda a resolver situações em que quantidades significativas de memória seriam usadas para armazenar em cache instâncias de tabela raramente usadas até a próxima reinicialização do servidor. O número de instâncias de tabela com metadados em cache pode ser maior que o limite definido por table_definition_cache, porque as instâncias de tabela pai e filho com relacionamentos de chave estrangeira não são colocadas na lista LRU e não estão sujeitas a remoção da memória.

Ao contrário do table_open_cache, o table_definition_cache não usa descritores de arquivo e é muito menor.

Lidando com o Cache de Consulta

De preferência, recomendamos desabilitar o cache de consulta em todas as configurações do MariaDB. Você precisa garantir que query_cache_type=OFF e query_cache_size=0 para concluir a desativação do cache de consulta. Ao contrário do MySQL, o MariaDB ainda suporta completamente o cache de consulta e não tem planos de retirar seu suporte para usar o cache de consulta. Algumas pessoas afirmam que o cache de consulta ainda oferece benefícios de desempenho para elas. No entanto, este post de Percona O cache de consulta do MySQL:pior inimigo ou melhor amigo revela que o cache de consulta, se ativado, resulta em sobrecarga e mostra um desempenho ruim do servidor.

Se você pretende usar o cache de consulta, certifique-se de monitorar seu cache de consulta executando SHOW GLOBAL STATUS LIKE 'Qcache%';. Qcache_inserts contém o número de consultas adicionadas ao cache de consulta, Qcache_hits contém o número de consultas que usaram o cache de consulta, enquanto Qcache_lowmem_prunes contém o número de consultas que foram eliminadas do cache devido à falta de memória. No devido tempo, usar e habilitar o cache de consulta pode ficar fragmentado. Um Qcache_free_blocks alto em relação a Qcache_total_blocks pode indicar fragmentação. Para desfragmentá-lo, execute FLUSH QUERY CACHE. Isso desfragmentará o cache de consulta sem descartar nenhuma consulta.

Sempre monitore seus servidores

É muito importante que você monitore adequadamente seus nós MariaDB. Ferramentas comuns de monitoramento (como Nagios, Zabbix ou PMM) estão disponíveis se você preferir ferramentas gratuitas e de código aberto. Para ferramentas corporativas e totalmente compactas, sugerimos que você experimente o ClusterControl, pois ele não apenas fornece monitoramento, mas também oferece consultores de desempenho, alertas e alarmes que ajudam a melhorar o desempenho do sistema e manter-se atualizado com o atual tendências à medida que você se envolve com a equipe de suporte. O monitoramento de banco de dados com o ClusterControl é gratuito e faz parte da Community Edition.

Conclusão