Bem-vindo ao PostgreSQL, um poderoso sistema de banco de dados de código aberto que pode hospedar desde alguns megabytes de dados de clientes para uma pequena empresa até centenas de terabytes de ‘big data’ para corporações multinacionais. Independentemente do aplicativo, é provável que alguma ajuda de configuração e configuração seja necessária para deixar o banco de dados pronto para ação.
Quando um novo servidor é instalado, as configurações do PostgreSQL são mínimas, pois são projetadas para rodar na menor quantidade de hardware possível. No entanto, eles raramente são ótimos. Aqui, veremos uma configuração básica para novos projetos e como configurar o PostgreSQL para executar da maneira mais otimizada em novos projetos.
Hospedagem
Hospedagem no local
Com um banco de dados local, a melhor opção é para um host bare metal, pois as máquinas virtuais geralmente têm um desempenho mais lento, a menos que estejamos falando de VMs de nível empresarial de ponta. Isso também permite um controle mais rígido sobre as configurações de CPU, memória e disco. Isso, no entanto, vem com a necessidade de ter um especialista disponível (ou contrato) para fazer a manutenção do servidor.
Nuvem
Hospedar um banco de dados na nuvem pode ser maravilhoso em alguns aspectos, ou um pesadelo em outros. A menos que a plataforma de nuvem escolhida seja altamente otimizada (o que geralmente significa preço mais alto), ela pode ter problemas com ambientes de carga mais alta. Fique atento se o servidor em nuvem é compartilhado ou dedicado (dedicado permitindo total desempenho do servidor para a aplicação), bem como o nível de IOPS (Operações de entrada/saída por segundo) fornecido por um servidor em nuvem. Quando (ou se) o aplicativo cresce a ponto de a maioria dos dados não poder ser armazenada na memória, a velocidade de acesso ao disco é crucial.
Configuração geral do host
Os principais pilares necessários para configurar o PostgreSQL de forma confiável são baseados nas capacidades de CPU, Memória e Disco do host. Dependendo das necessidades dos aplicativos, um host suficiente e uma configuração PostgreSQL bem ajustada terão um impacto incrível no desempenho do sistema de banco de dados.
Escolhendo um sistema operacional
O PostgreSQL pode ser compilado na maioria dos sistemas operacionais do tipo Unix, bem como no Windows. No entanto, o desempenho no Windows nem é comparável a um sistema semelhante ao Unix, portanto, a menos que seja para um pequeno projeto descartável, manter um sistema semelhante ao Unix estabelecido será o caminho a percorrer. Para esta discussão, vamos nos ater aos sistemas baseados em Linux.
A distribuição Linux aparentemente mais usada para hospedar o PostgreSQL é um sistema baseado em Red Hat, como CentOS ou Scientific Linux, ou até mesmo o próprio Red Hat. Como o Red Hat e o CentOS se concentram em estabilidade e desempenho, a comunidade por trás desses projetos trabalha duro para garantir que aplicativos importantes, como bancos de dados, estejam na versão mais segura e confiável possível do Linux.
NOTA:O Linux tem uma variedade de versões de kernel que não são ideais para executar o PostgreSQL, portanto, é altamente recomendável que sejam evitadas, se possível (especialmente em aplicativos em que o desempenho máximo é a maior importância). Os benchmarks mostraram que o número de transações por segundo caiu da versão 3.4 – 3.10 do kernel, mas se recupera e melhora significativamente no kernel 3.12. Infelizmente, isso exclui o uso do CentOS 7 se estiver seguindo a rota do CentOS. O CentOS 6 ainda é uma versão válida e compatível do sistema operacional, e espera-se que o CentOS 8 seja lançado antes que o 6 deixe de ser compatível.
Instalação
A instalação pode ser feita por fonte, ou usando repositórios mantidos pela distribuição Linux escolhida, ou melhor ainda, pelo PostgreSQL Global Development Group (PGDG), que mantém repositórios para sistemas baseados em Red Hat (Red Hat, Scientific Linux, CentOS, Amazon Linux AMI, Oracle Enterprise Linux e Fedora), bem como pacotes para Debian e Ubuntu. O uso dos pacotes PGDG garantirá que as atualizações do PostgreSQL estejam disponíveis para atualização após o lançamento, em vez de esperar que os repositórios integrados da distribuição Linux as aprovem e forneçam.
CPU
Atualmente, não é difícil ter vários núcleos disponíveis para um host de banco de dados. O próprio PostgreSQL só recentemente começou a adicionar recursos multi-threading no nível de consulta e ficará muito melhor nos próximos anos. Mas mesmo sem essas novas e futuras melhorias, o próprio PostgreSQL gera novas threads para cada conexão com o banco de dados por um cliente. Esses threads usarão essencialmente um núcleo quando estiverem ativos, portanto, o número de núcleos necessários dependerá do nível de conexões simultâneas e consultas simultâneas necessárias.
Uma boa linha de base para começar é um sistema de 4 núcleos para um pequeno aplicativo. Supondo que os aplicativos façam uma dança entre executar consultas e dormir, um sistema de 4 núcleos pode lidar com algumas dúzias de conexões antes de ser sobrecarregado. Adicionar mais núcleos ajudará a dimensionar com uma carga de trabalho crescente. Não é incomum que bancos de dados PostgreSQL muito grandes tenham mais de 48 núcleos para atender a muitas centenas de conexões.
Dicas de ajuste: Mesmo que o hyper-threading esteja disponível, as transações por segundo geralmente são mais altas quando o hyper-threading está desabilitado. Para consultas de banco de dados que não são muito complexas, mas com maior frequência, mais núcleos são mais importantes do que núcleos mais rápidos.
Memória
A memória é um aspecto extremamente importante para o desempenho geral do PostgreSQL. A principal configuração do PostgreSQL em termos de memória é shared_buffers, que é um pedaço de memória alocado diretamente ao servidor PostgreSQL para armazenamento em cache de dados. Quanto maior a probabilidade de os dados necessários estarem na memória, mais rápido as consultas retornam e consultas mais rápidas significam uma configuração de núcleo de CPU mais eficiente, conforme discutido na seção anterior.
As consultas também, às vezes, precisam de memória para realizar operações de classificação nos dados antes de serem devolvidos ao cliente. Isso usa memória ad-hoc adicional (separada de shared_buffers) ou arquivos temporários em disco, que é muito mais lento.
Dicas de ajuste: Um ponto de partida básico para configurar shared_buffers é configurá-lo para 1/4 do valor da memória RAM do sistema disponível. Isso permite que o sistema operacional também faça seu próprio cache de dados, bem como qualquer processo em execução que não seja o próprio banco de dados.
Aumentar work_mem pode acelerar as operações de classificação, no entanto, aumentá-lo demais pode forçar o host a ficar sem memória, pois o conjunto de valores pode ser emitido parcial ou totalmente várias vezes por consulta. Se várias consultas solicitarem vários blocos de memória para classificação, isso poderá adicionar rapidamente mais memória do que a disponível no host. Mantenha-o baixo e levante-o lentamente até que o desempenho seja o desejado.
Usando o comando 'free' (como 'free -h'), defina Effective_cache_size como a soma da memória que está livre e armazenada em cache. Isso permite que o planejador de consultas saiba o nível de cache do SO que pode estar disponível e execute melhores planos de consulta.
Disco
O desempenho do disco pode ser uma das coisas mais importantes a serem consideradas ao configurar um sistema. As velocidades de entrada/saída são importantes para grandes cargas de dados ou para buscar grandes quantidades de dados a serem processados. Ele também determina a rapidez com que o PostgreSQL pode sincronizar a memória com o disco para manter o pool de memória ideal.
Alguma preparação em discos pode ajudar a melhorar instantaneamente o desempenho potencial, bem como preparar o crescimento do sistema de banco de dados para o futuro.
-
Discos separados
Uma nova instalação do PostgreSQL criará o diretório de dados do cluster em algum lugar da unidade principal (e possivelmente única) disponível no sistema.
Uma configuração básica usando mais unidades seria adicionar uma unidade separada (ou conjunto de unidades via RAID). Ele tem a vantagem de ter todas as transferências de dados relacionadas ao banco de dados operando em um canal de E/S diferente do sistema operacional principal. Ele também permite que o banco de dados cresça sem medo de espaço insuficiente causando problemas e erros em outras partes do sistema operacional.
Para bancos de dados com uma quantidade extrema de atividade, o diretório PostgreSQL Transaction Log (xlog) pode ser colocado em outra unidade, separando E/S mais pesada para outro canal longe do SO principal, bem como do diretório de dados principal. Esta é uma medida avançada que ajuda a extrair mais desempenho de um sistema, que de outra forma pode estar perto de seus limites.
-
Usando RAID
A configuração de RAID para as unidades de banco de dados não apenas protege contra perda de dados, mas também pode melhorar o desempenho se estiver usando a configuração RAID correta. RAID 1 ou 10 são geralmente considerados os melhores, e 10 oferece paridade e velocidade geral. O RAID 5, no entanto, embora tenha níveis mais altos de redundância, sofre uma redução significativa no desempenho devido à maneira como distribui os dados em vários discos. Planeje a melhor opção disponível com muito espaço para crescimento de dados, e essa será uma configuração que não precisará ser alterada com frequência, se for necessário.
-
Usando SSD
As unidades de estado sólido são maravilhosas para o desempenho e, se atenderem ao orçamento, os SSDs corporativos podem tornar as cargas de trabalho pesadas de processamento de dados noite e dia mais rápidas. Bancos de dados menores a médios com cargas de trabalho menores a médias podem ser um exagero, mas ao lutar pelo menor aumento percentual em aplicativos grandes, o SSD pode ser a bala de prata.
Dicas de ajuste: Escolha uma configuração de unidade que seja melhor para o aplicativo em questão e tenha muito espaço para crescer com o tempo à medida que os dados aumentam.
Se estiver usando um SSD, definir random_page_cost como 1,5 ou 2 (o padrão é 4) será benéfico para o planejador de consulta, pois a busca de dados aleatórios é muito mais rápida do que a vista em discos giratórios.
Baixe o whitepaper hoje PostgreSQL Management &Automation with ClusterControlSaiba o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o PostgreSQLBaixe o whitepaper
Definições de configuração inicial
Ao configurar o PostgreSQL pela primeira vez, há algumas definições de configuração que podem ser facilmente alteradas com base no poder do host. À medida que o aplicativo consulta o banco de dados ao longo do tempo, ajustes específicos podem ser feitos com base nas necessidades do aplicativo. No entanto, esse será o tópico para um blog de ajuste separado.
Configurações de memória
shared_buffers:Defina para 1/4 da memória do sistema. Se o sistema tiver menos de 1 GB de memória total, defina para ~ 1/8 da memória total do sistema
work_mem:O padrão é 4MB, podendo até ser bastante para a aplicação em questão. Mas se os arquivos temporários estiverem sendo criados com frequência e esses arquivos forem bastante pequenos (dezenas de megabytes), pode valer a pena aumentar essa configuração. Uma configuração de nível de entrada conservadora pode ser (1/4 da memória do sistema / max_connections). Essa configuração depende muito do comportamento real e da frequência das consultas ao banco de dados, portanto, deve ser aumentada apenas com cautela. Esteja pronto para reduzi-lo de volta aos níveis anteriores se ocorrerem problemas.
Effective_cache_size:Defina a soma da memória que está livre e armazenada em cache relatada pelo comando 'free'.
Configurações do ponto de verificação
Para PostgreSQL 9.4 e abaixo:
checkpoint_segments:Um número de segmentos de checkpoint (16 megabytes cada) para fornecer o sistema Write Ahead Log. O padrão é 3 e pode ser aumentado com segurança para 64 para bancos de dados pequenos.
Para PostgreSQL 9.5 e superior:
max_wal_size:Isso substituiu checkpoint_segments como uma configuração. O padrão é 1 GB e pode permanecer aqui até precisar de mais alterações.
Segurança
listen_address:Esta configuração determina em quais endereços IP pessoais/placas de rede escutar as conexões. Em uma configuração simples, provavelmente haverá apenas um, enquanto redes mais avançadas podem ter vários cartões para se conectar a várias redes. * Significa ouvir tudo. No entanto, se o aplicativo que acessa o banco de dados deve residir no mesmo host que o próprio banco de dados, mantê-lo como 'localhost' é suficiente.
Registro
Algumas configurações básicas de log que não sobrecarregarão os logs são as seguintes.
log_checkpoints = on
log_connections = on
log_disconnections = on
log_temp_files = 0
