Tuning do Linux para melhorar o desempenho do PostgreSQL. Ilya Kosmodemyansky

Transcrição do relatório de 2015 de Ilya Kosmodemyansky "Ajuste do Linux para melhorar o desempenho do PostgreSQL"

Isenção de responsabilidade: observo que este relatório é datado de novembro de 2015 - mais de 4 anos se passaram e muito tempo se passou. A versão 9.4 discutida no relatório não é mais suportada. Nos últimos 4 anos, 5 novas versões do PostgreSQL foram lançadas e 15 versões do kernel Linux foram lançadas. Se você reescrever essas passagens, acabará com um relatório diferente. Mas aqui consideramos o ajuste fundamental do Linux para PostgreSQL, que ainda é relevante hoje.

Meu nome é Ilya Kosmodemyansky. Eu trabalho na Consultoria PostgreSQL. E agora falarei um pouco sobre o que fazer com o Linux em relação aos bancos de dados em geral e ao PostgreSQL em particular, pois os princípios são bastante parecidos.

Sobre o que vamos conversar? Se você se comunica com o PostgreSQL, até certo ponto você precisa ser um administrador do UNIX. O que isso significa? Se compararmos Oracle e PostgreSQL, então no Oracle você precisa ser 80% administrador de banco de dados DBA e 20% administrador Linux.

Com o PostgreSQL é um pouco mais complicado. Com o PostgreSQL você precisa entender muito melhor como o Linux funciona. E ao mesmo tempo, corra um pouco atrás da locomotiva, porque ultimamente tudo está muito bem atualizado. E novos kernels são lançados e novas funcionalidades aparecem, o desempenho melhora, etc.

Por que estamos falando sobre Linux? Não porque estejamos na conferência Linux Peter, mas porque nas condições modernas um dos sistemas operacionais mais justificados para usar bancos de dados em geral e PostgreSQL em particular é o Linux. Porque o FreeBSD, infelizmente, está se desenvolvendo em uma direção muito estranha. E haverá problemas tanto de desempenho quanto de muitas outras coisas. O desempenho do PostgreSQL no Windows é geralmente um problema sério à parte, baseado no fato de que o Windows não possui a mesma memória compartilhada que o UNIX, enquanto o PostgreSQL está todo vinculado a isso, porque é um sistema multiprocesso.

E acho que todo mundo está menos interessado em exóticos como o Solaris, então vamos lá.

Uma distribuição Linux moderna tem mais de 1 opções de syctl, dependendo de como você constrói o kernel. Ao mesmo tempo, se olharmos para as diferentes porcas, podemos ajustar algo de várias maneiras. Existem parâmetros do sistema de arquivos sobre como montá-los. Se você tiver dúvidas sobre como iniciá-lo: o que habilitar na BIOS, como configurar o hardware, etc.

Este é um volume muito grande que pode ser discutido ao longo de vários dias, e não em um pequeno relatório, mas agora vou me concentrar em coisas importantes, como evitar aqueles rakes que com certeza impedirão você de usar bem seu banco de dados no Linux se você não os corrija. E, ao mesmo tempo, um ponto importante é que muitos parâmetros padrão não estão incluídos nas configurações corretas para o banco de dados. Ou seja, por padrão, funcionará mal ou não funcionará.

Quais alvos de ajuste tradicionais existem no Linux? Acho que, como todos vocês estão lidando com a administração do Linux, não há necessidade específica de explicar o que são os alvos.

Você pode sintonizar:

• CPU.
• Memória.
• Armazenamento.
• Outro. Falaremos sobre isso no final para um lanche. Mesmo, por exemplo, parâmetros como a política de poupança de energia podem afectar o desempenho de uma forma muito imprevisível e não muito agradável.

Quais são as especificidades do PostgreSQL e do banco de dados em geral? O problema é que você não pode ajustar nenhuma noz individual e ver que nosso desempenho melhorou significativamente.

Sim, existem tais gadgets, mas um banco de dados é algo complexo. Ele interage com todos os recursos que o servidor possui e prefere interagir ao máximo. Se você observar as recomendações atuais da Oracle sobre como usar um sistema operacional host, será como a piada sobre aquele cosmonauta mongol: alimente o cachorro e não toque em nada. Vamos dar todos os recursos ao banco de dados, o próprio banco de dados resolverá tudo.

Em princípio, até certo ponto a situação é exatamente a mesma com o PostgreSQL. A diferença é que o banco de dados ainda não é capaz de absorver todos os recursos para si, ou seja, em algum lugar no nível do Linux você precisa resolver tudo sozinho.

A ideia principal não é selecionar um único alvo e começar a ajustá-lo, por exemplo, memória, CPU ou algo parecido, mas analisar a carga de trabalho e tentar melhorar o rendimento o máximo possível para que a carga que bons programadores criaram para nós, incluindo nossos usuários.

Aqui está uma foto para explicar o que é. Existe um buffer do sistema operacional Linux, memória compartilhada e buffers compartilhados do PostgreSQL. O PostgreSQL, ao contrário do Oracle, funciona diretamente apenas através do buffer do kernel, ou seja, para que uma página do disco entre em sua memória compartilhada, ela deve passar pelo buffer do kernel e voltar, exatamente a mesma situação.

Os discos residem neste sistema. Eu desenhei isso como discos. Na verdade, pode haver um controlador RAID, etc.

E essa entrada-saída de uma forma ou de outra acontece por meio dessa matéria.

PostgreSQL é um banco de dados clássico. Há uma página dentro. E todas as entradas e saídas ocorrem por meio de páginas. Estamos levantando blocos na memória com páginas. E se nada aconteceu, apenas os lemos, aos poucos eles desaparecem desse cache, dos buffers compartilhados e voltam para o disco.

Se substituirmos algo em algum lugar, a página inteira será marcada como suja. Eu os marquei aqui em azul. E isso significa que esta página deve ser sincronizada com o armazenamento em bloco. Ou seja, quando sujamos, fizemos um lançamento no WAL. E em algum momento maravilhoso surgiu um fenômeno chamado checkpoint. E nesse registro ficou registrada a informação de que ele havia chegado. E isso significa que todas as páginas sujas que estavam aqui naquele momento nesses buffers compartilhados foram sincronizadas com o disco de armazenamento usando fsync através do buffer do kernel.

Por que isso está sendo feito? Se perdêssemos tensão, não chegaríamos à situação de perda de todos os dados. A memória persistente, sobre a qual todos nos falaram, ainda está na teoria dos bancos de dados - este é um futuro brilhante, pelo qual nós, é claro, nos esforçamos e gostamos, mas por enquanto eles vivem em menos de 20 anos. E, claro, tudo isso precisa ser monitorado.

E a tarefa de maximizar o rendimento é ajustar todos esses estágios para que tudo avance e retroceda rapidamente. A memória compartilhada é basicamente um cache de página. No PostgreSQL enviamos uma consulta select ou algo assim, ele recuperou esses dados do disco. Eles acabaram em buffers compartilhados. Conseqüentemente, para que isso funcione melhor, deve haver muita memória.

Para que tudo isso funcione bem e rapidamente, é necessário configurar corretamente o sistema operacional em todas as etapas. E escolha hardware balanceado, porque se você tiver um desequilíbrio em algum lugar, poderá gerar muita memória, mas não será atendida com velocidade suficiente.

E vamos passar por cada um desses pontos.

Para fazer com que essas páginas viajem de um lado para o outro com mais rapidez, você precisa fazer o seguinte:

• Em primeiro lugar, você precisa trabalhar de forma mais eficiente com a memória.
• Em segundo lugar, esta transição quando as páginas da memória vão para o disco deve ser mais eficiente.
• E em terceiro lugar, deve haver bons discos.

Se você tiver 512 GB de RAM no servidor e tudo isso acabar em um disco rígido SATA sem cache, todo o servidor de banco de dados se transformará não apenas em uma abóbora, mas em uma abóbora com interface SATA. Você o encontrará diretamente. E nada irá salvá-lo.

Em relação ao primeiro ponto da memória, há três coisas que podem dificultar muito a vida.

O primeiro deles é NUMA. NUMA é algo feito para melhorar o desempenho. Dependendo da carga de trabalho, coisas diferentes podem ser otimizadas. E em sua nova forma atual, não é muito bom para aplicativos como bancos de dados que usam buffers compartilhados de cache de página intensivamente.

Em poucas palavras. Como você pode saber se algo está errado com NUMA? Você recebe algum tipo de batida desagradável e, de repente, alguma CPU fica sobrecarregada. Ao mesmo tempo, você analisa consultas no PostgreSQL e vê que não há nada semelhante ali. Essas consultas não devem consumir tanto a CPU. Você pode pegar isso por muito tempo. É mais fácil usar a recomendação correta desde o início sobre como configurar o NUMA para PostgreSQL.

O que realmente está acontecendo? NUMA significa Acesso Não Uniforme à Memória. Qual é o objetivo? Você tem uma CPU, ao lado dela está sua memória local. E essas interconexões de memória podem extrair memória de outras CPUs.

Se você correr numactl --hardware, então você obterá uma folha tão grande. Entre outras coisas, haverá um campo de distâncias. Haverá números - 10-20, algo assim. Esses números nada mais são do que o número de saltos para pegar essa memória remota e usá-la localmente. Em princípio, uma boa ideia. Isso acelera bem o desempenho em uma variedade de cargas de trabalho.

Agora imagine que você tem uma CPU primeiro tentando usar sua memória local e depois tentando extrair outra memória via interconexão para alguma coisa. E esta CPU obtém todo o cache da página PostgreSQL - é isso, alguns gigabytes. Você sempre obtém o pior caso, porque na CPU geralmente há pouca memória no próprio módulo. E toda a memória atendida passa por essas interconexões. Acontece lento e triste. E o seu processador que atende esse nó está constantemente sobrecarregado. E o tempo de acesso dessa memória é ruim, lento. Esta é a situação que você não deseja se estiver usando isso para um banco de dados.

Portanto, uma opção mais correta para o banco de dados é o sistema operacional Linux não saber o que está acontecendo ali. Para que ele acesse a memória como o faz.

Por que é que? Parece que deveria ser o contrário. Isso acontece por um motivo simples: precisamos de muita memória para o cache da página - dezenas, centenas de gigabytes.

E se alocarmos tudo isso e armazenarmos nossos dados em cache lá, o ganho com o uso do cache será significativamente maior do que o ganho com um acesso tão complicado à memória. E assim nos beneficiaremos incomparavelmente em comparação com o fato de acessarmos a memória de forma mais eficiente usando NUMA.

Portanto, existem duas abordagens aqui no momento, até que o futuro brilhante chegue, e o próprio banco de dados não seja capaz de descobrir em quais CPUs está sendo executado e de onde precisa extrair algo.

Portanto, a abordagem correta é desabilitar completamente o NUMA, por exemplo, ao reiniciar. Na maioria dos casos, os ganhos são de tal ordem de magnitude que a questão de qual é o melhor nem sequer surge.

Existe outra opção. Usamos com mais frequência do que o primeiro, porque quando um cliente nos procura em busca de suporte, reiniciar o servidor é um grande problema para ele. Ele tem um negócio lá. E eles enfrentam problemas por causa do NUMA. Portanto, tentamos desabilitá-lo de maneiras menos invasivas do que reinicializar, mas tome cuidado para verificar se ele está desabilitado. Porque, como mostra a experiência, é bom desabilitarmos o NUMA no processo pai do PostgreSQL, mas não é necessário que funcione. Precisamos verificar se ela realmente desligou.

Há uma boa postagem de Robert Haas. Este é um dos committers do PostgreSQL. Um dos principais desenvolvedores de todos os miúdos de baixo nível. E se você seguir os links deste post, eles descrevem várias histórias interessantes sobre como a NUMA dificultou a vida das pessoas. Olha, estude o checklist do administrador do sistema sobre o que precisa ser configurado no servidor para que nosso banco de dados funcione bem. Essas configurações precisam ser anotadas e verificadas, caso contrário não ficará muito bom.

Observe que isso se aplica a todas as configurações das quais falarei. Mas normalmente os bancos de dados são coletados no modo mestre-escravo para tolerância a falhas. Não se esqueça de fazer essas configurações no escravo porque um dia você sofrerá um acidente e mudará para o escravo e ele se tornará o mestre.

Numa situação de emergência, quando tudo está muito ruim, seu telefone toca constantemente e seu chefe vem correndo com um porrete, você não terá tempo para pensar em verificar. E os resultados podem ser bastante desastrosos.

O próximo ponto são páginas enormes. Páginas enormes são difíceis de testar separadamente e não faz sentido fazê-lo, embora existam benchmarks que possam fazer isso. Eles são fáceis de pesquisar no Google.

Qual é o objetivo? Você tem um servidor não muito caro com muita RAM, por exemplo, mais de 30 GB. Você não usa páginas enormes. Isso significa que você definitivamente terá sobrecarga em termos de uso de memória. E essa sobrecarga está longe de ser a mais agradável.

Por que é que? Então o que está acontecendo? O sistema operacional aloca memória em pequenos pedaços. É tão conveniente, é como aconteceu historicamente. E se entrarmos em detalhes, o sistema operacional deve traduzir endereços virtuais em físicos. E esse processo não é dos mais simples, então o SO armazena em cache o resultado dessa operação no Translation Lookaside Buffer (TLB).

E como o TLB é um cache, todos os problemas inerentes ao cache surgem nesta situação. Em primeiro lugar, se você tiver muita RAM e estiver toda alocada em pequenos pedaços, esse buffer se tornará muito grande. E se o cache for grande, a pesquisa será mais lenta. A sobrecarga é saudável e ocupa espaço, ou seja, a RAM está sendo consumida por algo incorreto. Desta vez.

Dois - quanto mais o cache crescer em tal situação, maior será a probabilidade de você ter falhas de cache. E a eficiência desse cache diminui rapidamente à medida que seu tamanho aumenta. Portanto, os sistemas operacionais criaram uma abordagem simples. Ele é usado no Linux há muito tempo. Ele apareceu no FreeBSD não faz muito tempo. Mas estamos falando de Linux. Estas são páginas enormes.

E aqui deve-se notar que páginas enormes, como ideia, foram inicialmente promovidas por comunidades que incluíam Oracle e IBM, ou seja, fabricantes de bancos de dados pensaram fortemente que isso também seria útil para bancos de dados.

E como isso pode ser feito amigo do PostgreSQL? Em primeiro lugar, páginas enormes devem ser habilitadas no kernel do Linux.

Em segundo lugar, eles devem ser especificados explicitamente pelo parâmetro sysctl - quantos existem. Os números aqui são de algum servidor antigo. Você pode calcular quantos buffers compartilhados você tem para que páginas enormes caibam neles.

E se todo o seu servidor for dedicado ao PostgreSQL, então um bom ponto de partida é alocar 25% da RAM para buffers compartilhados ou 75% se você tiver certeza de que seu banco de dados caberá definitivamente nesses 75%. Ponto de partida um. E lembre-se, se você tiver 256 GB de RAM, terá 64 GB de buffers grandes. Calcule aproximadamente com alguma margem - como esse valor deve ser definido.

Antes da versão 9.2 (se não me engano, desde a versão 8.2), era possível conectar o PostgreSQL a páginas enormes usando uma biblioteca de terceiros. E isso sempre deve ser feito. Primeiro, você precisa do kernel para poder alocar páginas grandes corretamente. E, em segundo lugar, para que a aplicação que trabalha com eles possa utilizá-los. Não será usado apenas dessa forma. Como o PostgreSQL alocou memória no estilo do sistema 5, isso poderia ser feito usando libhugetlbfs - este é o nome completo da biblioteca.

Na versão 9.3, o desempenho do PostgreSQL foi melhorado ao trabalhar com memória e o método de alocação de memória do sistema 5 foi abandonado. Todos ficaram muito felizes, porque senão você tenta rodar duas instâncias do PostgreSQL em uma máquina, e ele diz que não tenho memória compartilhada suficiente. E ele diz que o sysctl precisa ser corrigido. E existe um sysctl que ainda precisa ser reinicializado, etc. Em geral, todos ficaram felizes. Mas a alocação de memória mmap interrompeu o uso de páginas enormes. A maioria dos nossos clientes usa grandes buffers compartilhados. E recomendamos fortemente não mudar para 9.3, porque o overhead ali começou a ser calculado em bons percentuais.

Mas a comunidade prestou atenção nesse problema e no 9.4 reformulou muito bem esse evento. E na versão 9.4 apareceu um parâmetro no postgresql.conf no qual você pode ativar o try, on ou off.

Tentar é a opção mais segura. Quando o PostgreSQL é iniciado, ao alocar memória compartilhada, ele tenta capturar essa memória das páginas enormes. E se não funcionar, ele volta para a seleção normal. E se você tem FreeBSD ou Solaris, então você pode tentar, é sempre seguro.

Se estiver ativado, ele simplesmente não será iniciado se não for possível selecionar entre as páginas enormes. Aqui já se trata de quem e o que é mais legal. Mas se você tentar, verifique se realmente tem o que precisa destacado, pois há muito espaço para erros. Atualmente esta funcionalidade só funciona no Linux.

Mais uma pequena nota antes de prosseguirmos. Páginas enormes e transparentes ainda não são sobre PostgreSQL. Ele não pode usá-los normalmente. E com páginas transparentes enormes para essa carga de trabalho, quando é necessária uma grande quantidade de memória compartilhada, os benefícios só vêm com volumes muito grandes. Se você tiver terabytes de memória, isso pode ser útil. Se estamos falando de aplicativos mais cotidianos, quando você tem 32, 64, 128, 256 GB de memória em sua máquina, então as páginas enormes de sempre estão OK, e simplesmente desabilitamos o Transparent.

E a última coisa sobre a memória não está diretamente relacionada à fruta, ela pode realmente arruinar a sua vida. Todo o rendimento será bastante afetado pelo fato de o servidor estar em constante troca.

E isso será muito desagradável em vários aspectos. E o principal problema é que os kernels modernos se comportam de maneira um pouco diferente dos kernels Linux mais antigos. E é bastante desagradável pisar nisso, porque quando falamos em algum tipo de trabalho com swap, termina com a chegada prematura do assassino OOM. E o assassino OOM, que não chegou em tempo hábil e descartou o PostgreSQL, é desagradável. Todos saberão disso, ou seja, até o último usuário.

O que está acontecendo? Você tem uma grande quantidade de RAM aí, tudo funciona bem. Mas por algum motivo o servidor trava no swap e fica lento por causa disso. Parece que há muita memória, mas isso acontece.

Anteriormente, recomendamos definir vm.swappiness como zero, ou seja, desabilitar a troca. Anteriormente, parecia que 32 GB de RAM e buffers compartilhados correspondentes eram uma quantidade enorme. O principal objetivo da troca é ter um lugar para jogar a crosta caso caiamos. E não foi mais particularmente cumprido. E então o que você vai fazer com essa crosta? Esta é uma tarefa em que não está muito claro por que a troca é necessária, especialmente neste tamanho.

Mas nas versões mais modernas, ou seja, na terceira versão do kernel, o comportamento mudou. E se você definir o swap para zero, ou seja, desligá-lo, mais cedo ou mais tarde, mesmo que ainda haja alguma RAM, um assassino OOM virá até você para matar os consumidores mais intensivos. Porque ele vai considerar que com tanta carga de trabalho ainda nos resta um pouco e vamos pular, ou seja, não para acertar o processo do sistema, mas para acertar algo menos importante. Este menos importante será o consumidor intensivo de memória partilhada, nomeadamente o postmaster. E depois disso será bom se a base não precisar ser restaurada.

Portanto, agora o padrão, pelo que me lembro, a maioria das distribuições está em torno de 6, ou seja, em que ponto você deve começar a usar swap dependendo de quanta memória resta. Agora recomendamos definir vm.swappiness = 1, porque isso praticamente o desliga, mas não produz os mesmos efeitos de um OOM-killer que chegou inesperadamente e matou tudo.

Qual é o próximo? Quando falamos sobre o desempenho dos bancos de dados e gradualmente avançamos para os discos, todos começam a se preocupar. Porque a verdade de que o disco é lento e a memória rápida é familiar a todos desde a infância. E todo mundo sabe que o banco de dados terá problemas de desempenho de disco.

O principal problema de desempenho do PostgreSQL associado a picos de pontos de verificação não ocorre porque o disco está lento. Provavelmente, isso se deve ao fato de que a memória e a largura de banda do disco não estão equilibradas. No entanto, eles podem não estar equilibrados em locais diferentes. PostgreSQL não está configurado, o sistema operacional não está configurado, o hardware não está configurado e o hardware está incorreto. E esse problema não acontece apenas se tudo acontecer como deveria, ou seja, ou não há carga, ou as configurações e o hardware estão bem selecionados.

O que é e como é? Normalmente as pessoas que trabalham com PostgreSQL já abordaram esse assunto mais de uma vez. Eu vou explicar. Como eu disse, o PostgreSQL faz pontos de verificação periodicamente para despejar páginas sujas da memória compartilhada no disco. Se tivermos uma grande quantidade de memória compartilhada, o ponto de verificação começa a ter um impacto intenso no disco, porque despeja essas páginas com o fsync. Ele chega no buffer do kernel e é gravado nos discos usando fsync. E se o volume deste negócio for grande, então podemos observar um efeito desagradável, nomeadamente uma utilização muito grande de discos.

Aqui tenho duas fotos. Vou agora explicar o que é. Estes são dois gráficos correlacionados com o tempo. O primeiro gráfico é a utilização do disco. Aqui chega a quase 90% neste momento. Se você tiver uma falha no banco de dados com discos físicos, com utilização do controlador RAID em 90%, isso é uma má notícia. Isso significa que um pouco mais e chegará a 100 e a E/S irá parar.

Se você tiver uma matriz de disco, a história é um pouco diferente. Depende de como está configurado, que tipo de array é, etc.

E paralelamente, um gráfico da visualização interna do postgres é configurado aqui, que informa como ocorre o ponto de verificação. E a cor verde aqui mostra quantos buffers, essas páginas sujas, naquele momento chegaram a esse ponto de verificação para sincronização. E esta é a principal coisa que você precisa saber aqui. Vemos que temos muitas páginas aqui e em algum momento batemos no quadro, ou seja, escrevemos e escrevemos, aqui o sistema de disco está claramente muito ocupado. E nosso ponto de verificação tem um impacto muito forte no disco. O ideal é que a situação fosse mais parecida com esta, ou seja, tivemos menos gravações aqui. E podemos consertar com as configurações para que continue assim. Ou seja, a reciclagem é pequena, mas em algum lugar estamos escrevendo algo aqui.

O que precisa ser feito para superar esse problema? Se você interrompeu o IO no banco de dados, isso significa que todos os usuários que vieram atender suas solicitações aguardarão.

Se você olhar do ponto de vista do Linux, se você pegou um bom hardware, configurou-o corretamente, configurou o PostgreSQL normalmente para que ele faça esses pontos de verificação com menos frequência, espalhe-os entre si ao longo do tempo, então você entra nos parâmetros padrão do Debian. Para a maioria das distribuições Linux, esta é a imagem: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

O que isso significa? Um demônio de descarga apareceu no kernel 2.6. Pdglush, dependendo de quem está usando qual, que está envolvido no descarte em segundo plano de páginas sujas do buffer do kernel e no descarte quando for necessário descartar páginas sujas de qualquer maneira, quando o descarte em segundo plano não ajuda.

Quando chega o fundo? Quando 10% da RAM total disponível no servidor é ocupada por páginas sujas no buffer do kernel, uma função especial de eliminação é chamada em segundo plano. Por que isso é pano de fundo? Como parâmetro, leva em consideração quantas páginas serão baixadas. E, digamos, ele escreve N páginas. E por um tempo essa coisa adormece. E então ela volta e copia mais algumas páginas.

Esta é uma história extremamente simples. O problema aqui é como o de uma piscina: quando flui para um cano, flui para outro. Nosso ponto de verificação chegou e se ele enviou algumas páginas sujas para serem descartadas, então gradualmente tudo será resolvido a partir do buffer do kernel pgflush.

Se essas páginas sujas continuarem a se acumular, elas acumulam até 20%, após o que a prioridade do sistema operacional é gravar tudo no disco, porque a energia falhará e tudo ficará ruim para nós. Perderemos esses dados, por exemplo.

Qual é o truque? O truque é que esses parâmetros no mundo moderno são 20 e 10% do total de RAM que está na máquina, eles são absolutamente monstruosos em termos de rendimento de qualquer sistema de disco que você tenha.

Imagine que você tem 128 GB de RAM. 12,8 GB chegam ao seu sistema de disco. E não importa qual cache você tenha, não importa qual array você tenha, eles não durarão tanto.

Portanto, recomendamos que você ajuste imediatamente esses números com base nas capacidades do seu controlador RAID. Imediatamente fiz uma recomendação aqui para um controlador que tenha 512 MB de cache.

Tudo é considerado muito simples. Você pode colocar vm.dirty_background em bytes. E essas configurações cancelam as duas anteriores. Qualquer uma das proporções é padrão ou aquelas com bytes estão ativadas, então aquelas com bytes funcionarão. Mas como sou consultor DBA e trabalho com diversos clientes, procuro tirar palhinhos e portanto, se em bytes, então em bytes. Ninguém deu qualquer garantia de que um bom administrador não adicionaria mais memória ao servidor, reinicializá-lo-ia e o número permaneceria o mesmo. Basta calcular esses números para que tudo caiba lá com garantia.

O que acontece se você não se encaixar? Escrevi que qualquer rubor é efetivamente interrompido, mas na verdade isso é uma figura de linguagem. O sistema operacional tem um grande problema - ele tem muitas páginas sujas, então o IO que seus clientes geram está efetivamente parado, ou seja, a aplicação chegou para enviar uma consulta sql ao banco de dados, ela está aguardando. Qualquer entrada/saída é de prioridade mais baixa, porque o banco de dados está ocupado por um ponto de verificação. E quando ela terminará, não está totalmente claro. E quando você consegue a limpeza sem segundo plano, significa que todo o seu IO está ocupado por ele. E até que termine, você não fará nada.

Há mais dois pontos importantes aqui que estão além do escopo deste relatório. Essas configurações devem corresponder às configurações do postgresql.conf, ou seja, configurações de pontos de verificação. E seu sistema de disco deve estar configurado adequadamente. Se você tiver um cache em um RAID, ele deverá ter uma bateria. As pessoas compram RAID com bom cache sem bateria. Se você tiver SSDs em RAID, então eles devem ser de servidor, deve haver capacitores lá. Aqui está uma lista de verificação detalhada. Este link contém meu relatório sobre como configurar um disco de desempenho no PostgreSQL. Existem todas essas listas de verificação lá.

O que mais pode tornar a vida muito difícil? Estes são dois parâmetros. Eles são relativamente novos. Por padrão, eles podem ser incluídos em diferentes aplicativos. E eles podem tornar a vida igualmente difícil se forem ativados incorretamente.

Existem duas coisas relativamente novas. Eles já apareceram nos terceiros núcleos. Isso é sched_migration_cost em nanossegundos e sched_autogroup_enabled, que é um por padrão.

E como eles arruínam sua vida? O que é sched_migration_cost? No Linux, o agendador pode migrar um processo de uma CPU para outra. E para o PostgreSQL, que executa consultas, a migração para outra CPU não é totalmente clara. Do ponto de vista do sistema operacional, quando você alterna janelas entre openoffice e terminal, isso pode ser bom, mas para um banco de dados isso é muito ruim. Portanto, uma política razoável é definir o migração_cost com um valor grande, pelo menos vários milhares de nanossegundos.

O que isso significará para o agendador? Será considerado que durante este tempo o processo ainda está quente. Ou seja, se você tiver uma transação de longa duração que esteja fazendo algo há muito tempo, o escalonador entenderá isso. Ele assumirá que até que esse tempo limite passe, não há necessidade de migrar esse processo para lugar nenhum. Se ao mesmo tempo o processo fizer alguma coisa, ele não será migrado para lugar nenhum, ele funcionará silenciosamente na CPU que lhe foi alocada. E o resultado é excelente.

O segundo ponto é o grupo automático. Há uma boa ideia para cargas de trabalho específicas que não estão relacionadas aos bancos de dados modernos - agrupar processos pelo terminal virtual a partir do qual eles são iniciados. Isto é conveniente para algumas tarefas. Na prática, o PostgreSQL é um sistema multiprocesso com um pré-fork que roda a partir de um único terminal. Você tem um gravador de bloqueio, um ponto de verificação e todas as solicitações do seu cliente serão agrupadas em um agendador, por CPU. E eles vão esperar ali em uníssono até que ele se liberte, para interferir um no outro e mantê-lo ocupado por mais tempo. Esta é uma história completamente desnecessária no caso de tal carga e por isso precisa ser desligada.

Meu colega Alexey Lesovsky fez testes com um pgbench simples, onde aumentou o migração_cost em uma ordem de magnitude e desativou o autogrupo. A diferença em hardware ruim foi de quase 10%. Há uma discussão na lista de discussão do postgres onde as pessoas fornecem resultados de alterações semelhantes na velocidade da consulta influenciou 50%. Existem muitas dessas histórias.

E, finalmente, sobre a política de economia de energia. O bom é que o Linux agora pode ser usado em um laptop. E supostamente consumirá bem a bateria. Mas de repente acontece que isso também pode acontecer no servidor.

Além disso, se você alugar servidores de algum hoster, os “bons” hosters não se importarão se você tiver melhor desempenho. A sua tarefa é garantir que o seu ferro seja utilizado da forma mais eficiente possível. Portanto, por padrão, eles podem ativar o modo de economia de energia do laptop no sistema operacional.

Se você usar esse material em um servidor com banco de dados sob carga pesada, sua escolha será acpi_cpufreq + permormance. Mesmo com ondemand haverá problemas.

Intel_pstate é um driver ligeiramente diferente. E agora dá-se preferência a este, pois é posterior e funciona melhor.

E, conseqüentemente, governador é apenas atuação. Ondemand, powersave e tudo mais não são sobre você.

Os resultados da explicação e análise do PostgreSQL podem diferir em várias ordens de magnitude se você ativar o powerave, porque praticamente a CPU do seu banco de dados estará funcionando de maneira completamente imprevisível.

Esses itens podem ser incluídos por padrão. Observe com atenção para ver se eles o ativaram por padrão. Isso pode ser um problema muito grande.

E no final, gostaria de agradecer ao pessoal da nossa equipe de DBA da PosgreSQL-Consulting, nomeadamente Max Boguk e Alexey Lesovsky, que estão avançando neste assunto todos os dias. E tentamos fazer o melhor que podemos pelos nossos clientes para que tudo funcione para eles. É como acontece com as instruções de segurança da aviação. Tudo aqui está escrito com sangue. Cada uma dessas nozes é encontrada no processo de algum tipo de problema. Estou feliz em compartilhá-los com você.

Perguntas:

Obrigado! Se, por exemplo, uma empresa quiser economizar dinheiro e colocar o banco de dados e a lógica da aplicação em um servidor, ou se a empresa seguir a tendência da moda das arquiteturas de microsserviços, nas quais o PostgreSQL roda em um contêiner. Qual é o truque? Sysctl afetará todo o kernel globalmente. Nunca ouvi falar de sysctls sendo virtualizados de alguma forma para que funcionem separadamente em um contêiner. Existe apenas um cgroup e apenas parte do controle nele. Como você pode viver com isso? Ou se você quiser desempenho, execute o PostgreSQL em um servidor de hardware separado e ajuste-o?

Respondemos à sua pergunta de três maneiras. Se não estamos falando de um servidor de hardware que pode ser ajustado, etc., então relaxe, tudo funcionará bem sem essas configurações. Se você tiver uma carga tão grande que precise fazer essas configurações, você chegará ao servidor Iron antes dessas configurações.

Qual é o problema? Se esta for uma máquina virtual, provavelmente você terá muitos problemas, por exemplo, com o fato de que na maioria das máquinas virtuais a latência do disco é bastante inconsistente. Mesmo que a taxa de transferência do disco seja boa, então uma transação de E/S com falha que não afeta muito a taxa de transferência média que ocorreu no momento do ponto de verificação ou no momento da gravação no WAL, o banco de dados sofrerá muito com isso. E você notará isso antes de se deparar com esses problemas.

Se você tiver o NGINX no mesmo servidor, também terá o mesmo problema. Ele lutará pela memória compartilhada. E você não chegará aos problemas descritos aqui.

Mas, por outro lado, alguns desses parâmetros ainda serão relevantes para você. Por exemplo, defina dirty_ratio com sysctl para que não seja tão louco - em qualquer caso, isso ajudará. De uma forma ou de outra, você terá interação com o disco. E será de acordo com o padrão errado. Geralmente, esse é um padrão para os parâmetros que mostrei. E em qualquer caso é melhor alterá-los.

Mas pode haver problemas com o NUMA. O VMware, por exemplo, funciona bem com NUMA com configurações exatamente opostas. E aqui você tem que escolher - um servidor ferro ou não.

Tenho uma pergunta relacionada ao Amazon AWS. Eles têm imagens pré-configuradas. Um deles é chamado Amazon RDS. Existem configurações personalizadas para o sistema operacional?

Existem configurações lá, mas são configurações diferentes. Aqui configuramos o sistema operacional em termos de como o banco de dados usará isso. E há parâmetros que determinam para onde devemos ir agora, como a modelagem. Ou seja, precisamos de tantos recursos que agora vamos consumi-los. Depois disso, o Amazon RDS restringe esses recursos e o desempenho cai. Existem histórias individuais de como as pessoas estão começando a mexer com esse assunto. Às vezes até com bastante sucesso. Mas isso não tem nada a ver com as configurações do sistema operacional. É como hackear a nuvem. Essa é uma história diferente.

Por que as páginas enormes transparentes não têm efeito em comparação com o TLB enorme?

Não dê. Isso pode ser explicado de várias maneiras. Mas na verdade eles simplesmente não dão. Qual é a história do PostgreSQL? Na inicialização, ele aloca uma grande quantidade de memória compartilhada. Se são transparentes ou não, é completamente irrelevante. O fato de se destacarem no início explica tudo. E se houver muita memória e você precisar reconstruir o segmento shared_memory, então páginas transparentes enormes serão relevantes. No PostgreSQL, ele é simplesmente alocado em uma grande parte no início e pronto, e então nada de especial acontece lá. Você pode, é claro, usá-lo, mas há uma chance de corromper a memória compartilhada quando ela realocar algo. O PostgreSQL não sabe disso.

Fonte: habr.com