Ajustando Firebird e Linux para um banco de dados de 691 GB de tamanho com mais de 1000 usuários

O Firebird é um DBMS aberto muito popular na Rússia e, apesar da ausência de campanhas de marketing barulhentas, é usado em um grande número de sistemas críticos, especialmente em sistemas de automação médica e estadual.

O tamanho do banco de dados e o número de usuários ativos em tais sistemas geralmente são bastante grandes; portanto, neste artigo, falarei sobre a experiência de otimizar as configurações do Firebird e Linux com base em exemplos específicos de grandes bancos de dados do Firebird no BeZdorov (Ingosstrakh), AlfaZdrav e abordarei a experiência de outras empresas de otimização Firebird + Linux.

Vamos examinar mais de perto o assunto da otimização - o Firebird 3.0.5 DBMS (com extensões HQbird), serve um banco de dados de 691 GB (atualmente) com 1.000 a 1100 usuários diários, roda no Linux CentOS 7, o servidor usa um ferro HP DL380. A replicação para o servidor de backup está configurada para o banco de dados (a questão da replicação está fora do escopo deste artigo).

O DBMS atende ao sistema de informações médicas Infoklinika (produzido pela empresa russa Smart Delta Systems ), que é um dos sistemas de informações médicas mais populares na Rússia.

Vamos dar uma olhada nos detalhes (as capturas de tela são tiradas do HQbird posteriormente) da operação deste banco de dados:

Os dados são intensivamente inseridos no banco de dados - um ganho diário de cerca de 0,4 - 0,5 GB



1000-1100 conexões é a carga diária usual:



Apesar do crescimento intenso e do trabalho ativo, o banco de dados não contém nenhuma quantidade significativa de versões de registros de lixo - graças a aplicativos criados com um bom conhecimento da arquitetura de várias versões e devido à coleta de lixo configurada corretamente:



Marcadores de transação na zona verde:



A propósito, observe que os dados no banco de dados são string, estão presentes blobs, mas há alguns deles - apenas 10 GB dos 690 GB do tamanho total.

A natureza da carga do banco de dados é mista, 75% das operações de leitura e 25% da gravação:

Ferro

O servidor que atende esse sistema não é ruim, mas está longe de ser de ponta:

HP ProLiant DL380p Gen8, Gen8 2x Xeon(R) CPU E5v2 @ 2.60GHz, 24 logical cores with HT 320Gb RAM, 4 network cards 

O subsistema de disco consiste em duas partes: um disco local de 745Gb e uma conexão de 2 canais de fibra dupla à SAN, com uma partição de 1,8Tb.

Sistema operacional

Usando o CentOS 7, versão do kernel:

 Linux version 3.10.0-957.21.3.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Tue Jun 18 16:35:19 UTC 2019 

Para a pergunta lógica, por que o kernel mais moderno e o CentOS 8 não são usados, a resposta também é lógica - a migração de sistemas críticos ocorre apenas após o lançamento de vários lançamentos menores e testes rigorosos - esse é um daqueles casos em que um bug conhecido é melhor que dois desconhecidos.

No entanto, deve-se observar que até 2017 o sistema funcionava no CentOS 6.x e após a migração, foi observada uma melhora significativa nos indicadores de desempenho.

Configuração do Linux

Uma personalização absolutamente essencial do Linux para Firebird

Existem 2 parâmetros que devem ser aumentados em todos os servidores Linux onde o Firebird é executado - o número de áreas de memória virtual (VMA) e o número de arquivos abertos para o processo do Firebird.

1. VMA

O número VMA padrão é 64K, deve ser aumentado 4 vezes; para isso, adicione a linha no sysctl.conf

 vm.max_map_count=262144 

Para verificar o valor atual, use o comando

 sysctl vm.max_map_count 

2. Máximo de arquivos abertos

O Firebird abre até 20 descritores (identificadores de arquivo) para cada conexão com o banco de dados (considerando o fato de que no Linux todos os recursos se parecem com arquivos), então o número máximo de arquivos abertos por padrão (geralmente 4096) pode ser esgotado rapidamente.

Para verificar o número de arquivos disponíveis para o Firebird, é melhor verificar os limites do arquivo executável do Firebird:

 cat /proc/$(pgrep firebird)/limits 

onde verificar o valor para Max Open Files e aumentá-los, se necessário.

Para aumentar o parâmetro Max Open Files para o Firebird, adicionamos a linha ao arquivo firebird-superserver.service na seção [service]:

 LimitNOFILE=49999 

Configuração opcional do Linux

Nesse servidor, também fizemos as seguintes configurações

1. Swapiness reduzido

Como o servidor é dedicado exclusivamente aos DBMSs do Firebird, e desejamos usar a RAM de maneira eficiente no cache do DBMS e no cache de arquivos do sistema operacional, reduzimos a troca do padrão de 60% para 10%, por isso adicionamos o sysctl.conf

 vm.swappiness=10 

2. Aumentou o tamanho mínimo de memória reservada para processos especiais do SO

 vm.min_free_kbytes=1048576 

ou seja, 1 GB de memória. Essa configuração afeta indiretamente a desfragmentação da memória.

Observe que essa configuração é individual - já que temos 320 GB de RAM, 1 GB não é tanto, mas no caso de uma pequena quantidade de memória (por exemplo, 32 GB), 1 GB pode ser demais.

3. Keepalive reduzido

O Firebird conta com intervalos de manutenção da manutenção para verificar o status da conexão, e o valor padrão da manutenção da manutenção pode ser muito grande. Limitando-o a 300 segundos, eliminamos as conexões suspensas

 net.ipv4.tcp_keepalive_time=300 net.ipv4.tcp_keepalive_probes=5 net.ipv4.tcp_keepalive_intvl=15 

Mais ajuste do Linux

Por que estamos limitados a um número tão pequeno de configurações do Linux?

Primeiro, adotamos uma abordagem conservadora para ajustar servidores com Linux (que está ficando cada vez melhor a cada nova versão); segundo, esse banco de dados Firebird não é extremamente grande nem mais carregado, e o Linux lida com as configurações especificadas. com suas tarefas.

Obviamente, existem mais algumas configurações que podem ser usadas para otimizar o trabalho do Firebird no Linux - por exemplo, várias coisas interessantes foram apresentadas na apresentação sobre o banco de dados do Firebird de 3 TB (RedBaza) no Serviço Federal de Representantes .

Configurar Firebird

Os arquivos de configuração da comunidade Firebird com firebirdsql.org são configurados de maneira muito conservadora e, em um servidor mais ou menos poderoso, você precisa alterar os arquivos de configuração e selecionar cuidadosamente a arquitetura usada (no Firebird 3.0 existem 2 tipos de conexão: Embedded e NetworkServer e 3 tipos de arquiteturas: SuperServer , SuperClassic, Classic).
Além disso, você deve usar as configurações de cada banco de dados, ou seja, coloque configurações críticas no database.conf, com referência a um banco de dados específico.

No nosso caso, escolhemos a arquitetura SuperServer, a mais popular na versão 3.0, porque usa eficientemente processadores com vários núcleos e possui um cache compartilhado para todas as conexões (mas separado para cada banco de dados).

A seguir, estão os arquivos de configuração (apenas valores relacionados ao desempenho):

firebird.conf - arquivo de configuração para todos os bancos de dados no servidor

 DefaultDbCachePages = 50K # pages FileSystemCacheThreshold = 300K # pages TempBlockSize = 2M # bytes TempCacheLimit = 20480M # bytes LockMemSize = 30M # bytes LockHashSlots = 30011 WireCompression = true ServerMode = Super ExtConnPoolSize = 500 # HQBird ExtConnPoolLifeTime = 14200 # HQBird SortDataStorageThreshold = 8192 #HQbird reports queries 

Em termos de desempenho, os principais parâmetros aqui são:

1. DefaultDbCachePages = 50K # é medido em páginas, em um banco de dados, na página 16K = 0.8Gb

O tamanho do cache da página DefaultDbCachePages no firebird.conf é especialmente definido por padrão como 800Mb, para que o banco de dados de teste acidentalmente desordenado no servidor não tente ocupar uma quantidade enorme de RAM.

2. FileSystemCacheThreshold = 300K # páginas

É importante definir esse parâmetro com um valor maior que DefaultDBCachePages para permitir o uso do cache de arquivos do SO.

3. TempCacheLimit = 20480M # bytes

Este parâmetro define o tamanho da memória para consultas com classificações (e algumas outras operações) e é individual para cada sistema.
Como resultado do monitoramento do tamanho das sortes, descobrimos que 20 GB são ideais para esse banco de dados.

4. LockMemSize e LockHashSlots - parâmetros da tabela de bloqueio

Esses parâmetros determinam o tamanho inicial da tabela de bloqueios e o número de slots para calcular a função de hash.

5. WireCompression = True

A configuração do tráfego de compactação entre clientes e servidores é especialmente útil com o Execute Statement On External intenso, que executa o aplicativo cliente.

Os parâmetros restantes são descritos no próprio firebird.conf e na documentação relacionada do Firebird e HQbird.

Fizemos as configurações mais importantes no database.conf , com o banco de dados exato

 database1 = /data/database1.fdb { DefaultDbCachePages = 14080K # 16K pages, 220 GB FileSystemCacheThreshold = 15361K TempSpaceCacheThreshold=2G #HQbird only, track big sorts LockHashSlots = 40099 LockMemSize = 50M } 

Como você pode imaginar, a principal dificuldade nesse caso é como calcular corretamente o tamanho da memória alocada pelo nosso grande banco de dados.

Para o Firebird 3.0 com arquitetura SuperServer, existem duas abordagens - conservadora, usada em servidores com uma pequena quantidade de RAM (até 32 GB inclusive), que consiste em alocar não mais de 25% de RAM para o cache da página, e o restante depende do sistema operacional do arquivo sistemas e ajuste fino, quando determinamos com precisão o tamanho ideal para classificação, alocamos um determinado tamanho de memória para o kernel do SO, reservamos uma certa quantidade de memória para operações massivas de arquivo (por exemplo, backup), o restante alocado para o cache de página.

No segundo caso, não é possível obter imediatamente o tamanho ideal do cache, pois a natureza da carga pode diferir bastante para diferentes tipos de bancos de dados, mas após várias iterações, você pode obter um excelente resultado.

Erros comuns na configuração do Firebird

Erros típicos incluem o seguinte:

1) O tamanho do cache da página especificado explicitamente na página do cabeçalho do DB, que substitui os valores especificados em firebird.conf e database.conf.

Especialmente esse erro ocorre ao alterar a arquitetura de Classic / SuperClassic para SuperServer - se o tamanho do cache da conexão Classic / SuperClassic estiver funcionando bem com um tamanho pequeno claramente indicado (500-2000 páginas), será necessário um cache muito maior para o SuperServer.
Para verificar, execute o comando

 gstat -h databasepathname 

e verifique o valor de Page Buffers - ele deve ser 0, o Firebird usará os valores de database.conf ou firebird.conf.

Para redefinir a configuração de cache da página na página de cabeçalho, execute o comando

 gfix -buff 0 databasepathname 

2) Ao aumentar o cache da página, eles esquecem de aumentar o FileSystemCacheThreshold, o que leva à desconexão do cache do arquivo, o que reduz o desempenho.

3) Usando o tamanho da página padrão do banco de dados (4096 ou 8192), enquanto para bancos de dados grandes você precisa usar 16K.

Conclusão

Em geral, mais de 1000 usuários do Firebird em ferro, correspondentes à carga configurada pelo Linux e configurada pelo Firebird, trabalham sem problemas. Há uma margem nesse servidor em termos de desempenho, que foi testado em picos de carga para até 1500 a 1800 usuários.

Entre as distribuições Linux para o banco de dados Firebird com carga semelhante, a mais popular é o CentOS 7, a versão recomendada é o Firebird 3.0.

Se você tiver alguma dúvida, terei prazer em responder nos comentários ou pelo e-mail ak@ibase.ru.