Assim, a abordagem correta \u00e9 desativar completamente o NUMA.<\/strong>, por exemplo, durante a reinicializa\u00e7\u00e3o. Na maioria dos casos, os ganhos s\u00e3o t\u00e3o evidentes que n\u00e3o h\u00e1 d\u00favida sobre qual \u00e9 a melhor op\u00e7\u00e3o. <\/p>\n<\/p>\n
H\u00e1 outra op\u00e7\u00e3o. Usamos essa com mais frequ\u00eancia do que a primeira, porque, quando um cliente nos procura para suporte, reiniciar o servidor \u00e9 um grande problema. O neg\u00f3cio deles depende disso. E eles enfrentam problemas devido ao NUMA. Portanto, tentamos desativ\u00e1-lo de maneiras menos invasivas do que uma reinicializa\u00e7\u00e3o, mas \u00e9 preciso ter cuidado para verificar se realmente foi desativado. Porque, como a experi\u00eancia mostra, desativar o NUMA no processo pai do PostgreSQL \u00e9 bom, mas n\u00e3o \u00e9 garantido que funcione. \u00c9 necess\u00e1rio verificar e assegurar que foi realmente desativado. <\/p>\n
<\/p>\n
H\u00e1 um bom post de Robert Haas. Ele \u00e9 um dos colaboradores do PostgreSQL. Um dos principais desenvolvedores de todos os meandros de baixo n\u00edvel. E se voc\u00ea seguir os links deste post, encontrar\u00e1 v\u00e1rias hist\u00f3rias interessantes sobre como o NUMA complicou a vida das pessoas. Veja, estude a lista de verifica\u00e7\u00e3o para administradores que precisa ser configurada no servidor para que nossa base de dados funcione bem. Essas configura\u00e7\u00f5es devem ser anotadas e verificadas, pois, do contr\u00e1rio, a situa\u00e7\u00e3o pode n\u00e3o ser boa. <\/p>\n
<\/p>\n
Ressalto que isso se aplica a todas as configura\u00e7\u00f5es das quais falarei. Mas normalmente, as bases de dados s\u00e3o configuradas em modo master-slave para garantir a toler\u00e2ncia a falhas. N\u00e3o se esque\u00e7a de aplicar essas configura\u00e7\u00f5es no slave, porque em um determinado momento, voc\u00ea ter\u00e1 uma falha e ir\u00e1 mudar para o slave, que se tornar\u00e1 o master. <\/p>\n
<\/p>\n
Em uma situa\u00e7\u00e3o de emerg\u00eancia, quando tudo est\u00e1 muito mal, com seu telefone tocando incessantemente e o chefe vindo at\u00e9 voc\u00ea com um grande bast\u00e3o, voc\u00ea n\u00e3o ter\u00e1 tempo para pensar em verificar. E os resultados podem ser bastante desastrosos.<\/p>\n
<\/p>\n
<\/p>\n
O pr\u00f3ximo ponto s\u00e3o as huge pages. As huge pages s\u00e3o dif\u00edceis de testar separadamente, e n\u00e3o faz muito sentido, embora existam benchmarks que conseguem fazer isso. Eles s\u00e3o facilmente encontrados na internet. <\/p>\n
<\/p>\n
Qual \u00e9 o problema? Voc\u00ea tem um servidor que n\u00e3o \u00e9 muito caro e possui muita mem\u00f3ria RAM, por exemplo, mais de 30 GB. Voc\u00ea n\u00e3o utiliza huge pages. Isso significa que voc\u00ea tem um overhead claro no uso da mem\u00f3ria. E esse overhead n\u00e3o \u00e9 nem um pouco agrad\u00e1vel. <\/p>\n
<\/p>\n
<\/p>\n
Por que isso acontece? O que est\u00e1 ocorrendo? O sistema operacional aloca mem\u00f3ria em pequenos peda\u00e7os. \u00c9 conveniente assim, \u00e9 como as coisas se desenvolveram historicamente. E se aprofundando nos detalhes, o SO precisa traduzir endere\u00e7os virtuais para endere\u00e7os f\u00edsicos. E esse processo n\u00e3o \u00e9 o mais simples, por isso o SO armazena o resultado dessa opera\u00e7\u00e3o em um Translation Lookaside Buffer (TLB).<\/p>\n
<\/p>\n
E como o TLB \u00e9 um cache, nessa situa\u00e7\u00e3o surgem todos os problemas t\u00edpicos de cache. Primeiro, se voc\u00ea tem uma grande quantidade de mem\u00f3ria RAM e ela \u00e9 toda alocada em pequenos peda\u00e7os, o buffer se torna muito grande. E se o cache \u00e9 grande, a busca nele se torna mais lenta. O overhead \u00e9 significativo e consome espa\u00e7o, ou seja, algo errado est\u00e1 utilizando a mem\u00f3ria. Isso \u00e9 um problema. <\/p>\n
<\/p>\n
Dois \u2013 quanto maior o cache se expande nessa situa\u00e7\u00e3o, maior a probabilidade de voc\u00ea ter faltas de cache. E a efici\u00eancia desse cache cai rapidamente \u00e0 medida que seu tamanho aumenta. Portanto, os sistemas operacionais idearam uma abordagem simples. No Linux, isso j\u00e1 \u00e9 utilizado h\u00e1 muito tempo. No FreeBSD, surgiu n\u00e3o faz muito. Mas estamos falando do Linux. Isso s\u00e3o huge pages.<\/p>\n
<\/p>\n
E aqui vale a pena destacar que huge pages, como ideia, foi inicialmente promovida por comunidades que inclu\u00edam Oracle e IBM, ou seja, os fabricantes de bancos de dados pensaram fortemente que isso seria \u00fatil, especialmente para bancos de dados. <\/p>\n
<\/p>\n
<\/p>\n
E como integrar isso ao PostgreSQL? Primeiro, as huge pages devem estar habilitadas no n\u00facleo do Linux.<\/p>\n
<\/p>\n
Em segundo lugar, elas devem ser especificadas explicitamente no par\u00e2metro sysctl \u2013 quantas delas. Os n\u00fameros aqui v\u00eam de algum servidor antigo. Voc\u00ea pode calcular aproximadamente quantos shared buffers voc\u00ea tem, para que as huge pages possam ser alocadas adequadamente. <\/p>\n
<\/p>\n
E se todo o seu servidor estiver dedicado ao PostgreSQL, um bom ponto de partida \u00e9 dedicar 25% da mem\u00f3ria RAM para os buffers compartilhados, ou 75% se voc\u00ea tem certeza de que sua base de dados caber\u00e1 nesses 75%. Esse \u00e9 o primeiro ponto de partida. E calcule, se voc\u00ea tiver 256 GB de mem\u00f3ria RAM, ent\u00e3o, respectivamente, ter\u00e1 64 GB de buffers compartilhados. Calcule aproximadamente com uma margem de seguran\u00e7a \u2013 qual deve ser esse valor.<\/p>\n
<\/p>\n
At\u00e9 a vers\u00e3o 9.2 (se n\u00e3o me engano, a partir da vers\u00e3o 8.2) era poss\u00edvel integrar o PostgreSQL com huge pages usando uma biblioteca de terceiros. E isso sempre precisa ser feito. Primeiro, voc\u00ea precisa que o n\u00facleo saiba alocar huge pages corretamente. E, em segundo lugar, que o aplicativo que trabalha com elas possa utiliz\u00e1-las. Apenas assim n\u00e3o funcionar\u00e1. Como o PostgreSQL alocava mem\u00f3ria no estilo do sistema 5, isso poderia ser feito com a libhugetlbfs \u2013 esse \u00e9 o nome completo da biblioteca.<\/p>\n
<\/p>\n
Na vers\u00e3o 9.3, melhoramos o desempenho do PostgreSQL ao trabalhar com mem\u00f3ria e abandonamos o m\u00e9todo de aloca\u00e7\u00e3o de mem\u00f3ria do sistema 5. Todos ficaram muito felizes, pois caso contr\u00e1rio, ao tentar iniciar duas inst\u00e2ncias do PostgreSQL em uma \u00fanica m\u00e1quina, ele diz que n\u00e3o h\u00e1 mem\u00f3ria compartilhada suficiente. E afirma que \u00e9 necess\u00e1rio ajustar o sysctl. E nesse caso, o sysctl \u00e9 t\u00e3o complicado que \u00e9 preciso reiniciar, etc. Enfim, todos ficaram aliviados. Mas a aloca\u00e7\u00e3o de mem\u00f3ria mmap quebrou o uso de huge pages. A maioria dos nossos clientes utiliza grandes buffers compartilhados. E recomendamos fortemente n\u00e3o atualizar para a vers\u00e3o 9.3, pois a sobrecarga come\u00e7ava a ser significativa.<\/p>\n
<\/p>\n
No entanto, a comunidade prestou aten\u00e7\u00e3o a esse problema e na vers\u00e3o 9.4 fez grandes melhorias nesse aspecto. E na vers\u00e3o 9.4, surgiu um par\u00e2metro no postgresql.conf, onde \u00e9 poss\u00edvel ativar o try, on ou off.<\/p>\n
<\/p>\n
Try \u00e9 o par\u00e2metro mais seguro. Ao iniciar o PostgreSQL, quando ele aloca mem\u00f3ria compartilhada, tenta capturar essa mem\u00f3ria a partir de huge pages. Se n\u00e3o conseguir, volta para a aloca\u00e7\u00e3o normal. E se voc\u00ea estiver usando FreeBSD ou Solaris, pode optar pelo try, pois isso \u00e9 sempre seguro. <\/p>\n
<\/p>\n
Se on, ele simplesmente n\u00e3o inicia se n\u00e3o conseguir alocar a partir de huge pages. Aqui j\u00e1 \u00e9 uma quest\u00e3o de prefer\u00eancia. Mas se voc\u00ea optar por try, verifique se realmente foi alocada a mem\u00f3ria necess\u00e1ria, pois h\u00e1 muito espa\u00e7o para erro. Atualmente, essa funcionalidade funciona apenas no Linux.<\/p>\n
<\/p>\n
Mais uma pequena observa\u00e7\u00e3o antes de avan\u00e7armos. Transparent huge pages ainda n\u00e3o se aplica ao PostgreSQL. Ele n\u00e3o consegue us\u00e1-las de maneira adequada. E ao usar Transparent huge pages para essa carga de trabalho que requer um grande bloco de mem\u00f3ria compartilhada, os benef\u00edcios aparecem apenas em volumes muito grandes. Se voc\u00ea tem terabytes de mem\u00f3ria, isso pode fazer diferen\u00e7a. Se falarmos de aplica\u00e7\u00f5es mais cotidianas, onde voc\u00ea tem 32, 64, 128, 256 GB de mem\u00f3ria na m\u00e1quina, ent\u00e3o huge pages normais s\u00e3o suficientes, e simplesmente desativamos o Transparent. <\/p>\n
<\/p>\n
<\/p>\n
E a \u00faltima coisa relacionada \u00e0 mem\u00f3ria, que n\u00e3o est\u00e1 diretamente ligada ao throughput, pode complicar muito a vida. Toda a largura de banda pode ser severamente afetada pela constante troca de mem\u00f3ria do servidor. <\/p>\n
<\/p>\n
E isso ser\u00e1 muito desagrad\u00e1vel em v\u00e1rios momentos. E o principal problema \u00e9 que o comportamento dos n\u00facleos modernos difere um pouco do dos n\u00facleos mais antigos do Linux. E essa \u00e9 uma quest\u00e3o dif\u00edcil de lidar, porque, quando falamos sobre alguma opera\u00e7\u00e3o com o swap, isso resulta na chegada n\u00e3o oportuna do OOM-killer. E o OOM-killer que n\u00e3o chegou a tempo e derrubou o PostgreSQL \u00e9 algo indesej\u00e1vel. Todos ficar\u00e3o sabendo disso, ou seja, at\u00e9 o \u00faltimo usu\u00e1rio. <\/p>\n
<\/p>\n
<\/p>\n
O que est\u00e1 acontecendo? Voc\u00ea tem uma grande quantidade de mem\u00f3ria RAM, tudo funciona bem. Mas, por algum motivo, o servidor est\u00e1 travado no swap e isso o est\u00e1 desacelerando. \u00c0 primeira vista, parece que h\u00e1 muita mem\u00f3ria, mas isso acontece. <\/p>\n
<\/p>\n
<\/p>\n
Antes, aconselh\u00e1vamos a configurar vm.swappiness para zero, ou seja, desativar o swap. Anteriormente, parecia que 32 GB de mem\u00f3ria RAM e os buffers adequados compartilhados eram uma quantidade enorme. A principal fun\u00e7\u00e3o do swap \u00e9 ter um espa\u00e7o para jogar a carga se algo falhar. E isso j\u00e1 n\u00e3o estava sendo muito utilizado. E o que voc\u00ea far\u00e1 com essa carga depois? \u00c9 um problema em que n\u00e3o est\u00e1 muito claro por que o swap \u00e9 necess\u00e1rio, especialmente de tal tamanho. <\/p>\n
<\/p>\n
Mas em n\u00facleos mais modernos, ou seja, nas vers\u00f5es tr\u00eas, o comportamento mudou. E se voc\u00ea definir o swap como zero, ou seja, desativ\u00e1-lo, mais cedo ou mais tarde, mesmo com alguma mem\u00f3ria RAM ainda dispon\u00edvel, o OOM-killer vir\u00e1 para eliminar os consumidores mais intensivos. Porque ele entender\u00e1 que, com essa carga de trabalho, ainda nos resta um pouco e vamos exceder, ou seja, n\u00e3o matar um processo do sistema, mas eliminar algo menos importante. E esse algo menos importante ser\u00e1 o consumidor intensivo de mem\u00f3ria compartilhada, especificamente o postmaster. E depois disso, ser\u00e1 bom se voc\u00ea n\u00e3o precisar restaurar o banco de dados. <\/p>\n
<\/p>\n
Portanto, agora, por padr\u00e3o, pelo que me lembro, a maioria das distribui\u00e7\u00f5es est\u00e1 em torno de 6, ou seja, em que momento come\u00e7ar a usar o swap dependendo da quantidade de mem\u00f3ria restante. Atualmente, recomendamos configurar vm.swappiness = 1, porque isso praticamente o desativa, mas n\u00e3o causa os efeitos que ocorrem com a chegada inesperada do OOM-killer, que acaba eliminando tudo.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
E agora? Quando falamos sobre o desempenho de bancos de dados e come\u00e7amos a nos aprofundar nos discos, todos ficam preocupados. Pois a verdade de que o disco \u00e9 lento e a mem\u00f3ria \u00e9 r\u00e1pida \u00e9 um conhecimento de longa data para todos. E todos sabem que haver\u00e1 problemas de desempenho em disco nos bancos de dados.<\/p>\n
<\/p>\n
O principal problema de desempenho do PostgreSQL, relacionado aos picos de checkpoints, n\u00e3o \u00e9 causado pela lentid\u00e3o do disco. Na verdade, isso acontece porque a taxa de transfer\u00eancia da mem\u00f3ria e do disco n\u00e3o est\u00e1 balanceada. Al\u00e9m disso, esse desequil\u00edbrio pode ocorrer em diferentes \u00e1reas. O PostgreSQL n\u00e3o est\u00e1 configurado corretamente, o sistema operacional n\u00e3o est\u00e1 otimizado, o hardware n\u00e3o est\u00e1 ajustado e o hardware \u00e9 inadequado. Esse problema n\u00e3o ocorre apenas quando tudo est\u00e1 funcionando como deveria, ou seja, ou n\u00e3o h\u00e1 carga ou as configura\u00e7\u00f5es e o hardware est\u00e3o bem ajustados. <\/p>\n
<\/p>\n
<\/p>\n
O que \u00e9 isso e como se parece? Geralmente, as pessoas que trabalham com o PostgreSQL j\u00e1 passaram por isso v\u00e1rias vezes. Deixe-me esclarecer. Como eu mencionei, o PostgreSQL periodicamente faz checkpoints para despejar as p\u00e1ginas sujas na mem\u00f3ria compartilhada no disco. Se temos um grande volume de mem\u00f3ria compartilhada, o checkpoint come\u00e7a a impactar intensamente o disco, porque despeja essas p\u00e1ginas usando fsync. Ele vai para o buffer do kernel e \u00e9 gravado nos discos com fsync. E se o volume desse processo for grande, podemos observar um efeito indesejado, ou seja, uma utiliza\u00e7\u00e3o muito alta dos discos.<\/p>\n
<\/p>\n
Aqui eu tenho duas imagens. Vou explicar o que s\u00e3o. Estas s\u00e3o duas gr\u00e1ficas correlacionadas no tempo. O primeiro gr\u00e1fico mostra a utiliza\u00e7\u00e3o do disco. Neste momento, ela chega a quase 90%. Se voc\u00ea est\u00e1 vendo uma utiliza\u00e7\u00e3o de quase 90% nos discos f\u00edsicos de um banco de dados com um controlador RAID, \u00e9 uma m\u00e1 not\u00edcia. Isso significa que se atingir 100%, a leitura e grava\u00e7\u00e3o ir\u00e3o parar. <\/p>\n
<\/p>\n
Se voc\u00ea tem um array de discos, a situa\u00e7\u00e3o \u00e9 um pouco diferente. Isso depende de como ele est\u00e1 configurado, que tipo de array \u00e9, etc. <\/p>\n
<\/p>\n
E paralelamente, aqui \u00e9 configurado um gr\u00e1fico a partir de uma view interna do PostgreSQL, que mostra como o checkpoint ocorre. E em verde, \u00e9 mostrado quantos buffers, essas p\u00e1ginas sujas, chegaram neste checkpoint para sincroniza\u00e7\u00e3o. E isso \u00e9 o principal que voc\u00ea precisa saber. Vemos que recebemos muitas p\u00e1ginas e, em algum momento, esbarramos no limite, ou seja, continuamos escrevendo aqui e claramente o sistema de disco est\u00e1 muito ocupado. E nosso checkpoint tem um impacto significativo no disco. Idealmente, a situa\u00e7\u00e3o deveria ser mais assim, ou seja, ter\u00edamos menos grava\u00e7\u00e3o. E podemos corrigir isso com as configura\u00e7\u00f5es, para que continue sendo assim. Ou seja, a utiliza\u00e7\u00e3o \u00e9 baixa, mas ainda estamos escrevendo alguma coisa. <\/p>\n
<\/p>\n
O que precisa ser feito para resolver esse problema? Se a IO do seu banco de dados parou, significa que todos os usu\u00e1rios que chegaram para executar suas consultas ficar\u00e3o esperando. <\/p>\n
<\/p>\n
<\/p>\n
Se observarmos do ponto de vista do Linux, se voc\u00ea pegou um bom hardware, o configurou corretamente e ajustou o PostgreSQL para que ele fizesse checkpoints com menos frequ\u00eancia, espa\u00e7ando-os ao longo do tempo, voc\u00ea acaba utilizando os par\u00e2metros padr\u00e3o do Debian. Para a maioria das distribui\u00e7\u00f5es Linux, a situa\u00e7\u00e3o \u00e9: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
O que isso significa? Desde o n\u00facleo 2.6, surgiu um daemon de flushing. O pdglush, dependendo de quem o utiliza, \u00e9 respons\u00e1vel pelo descarte em segundo plano de p\u00e1ginas sujas do buffer do kernel e pelo descarte, quando necess\u00e1rio, das p\u00e1ginas sujas, quando o descarte em segundo plano j\u00e1 n\u00e3o \u00e9 suficiente. <\/p>\n
<\/p>\n
Quando ocorre o background? Quando 10% de toda a mem\u00f3ria RAM do servidor est\u00e1 ocupada por p\u00e1ginas sujas no buffer do kernel, uma fun\u00e7\u00e3o especial de descarte em background \u00e9 chamada. Por que \u00e9 em background? Ela recebe como par\u00e2metro quantas p\u00e1ginas descartar. E, digamos, descarta N p\u00e1ginas. E por um tempo, essa opera\u00e7\u00e3o dorme. Depois, ela volta e descarta mais uma certa quantidade de p\u00e1ginas. <\/p>\n
<\/p>\n
\u00c9 uma hist\u00f3ria extremamente simples. A situa\u00e7\u00e3o \u00e9 como em uma piscina, quando algo \u00e9 despejado em um tubo e recebido em outro. Nosso checkpoint chegou e, se ele enviou poucas p\u00e1ginas sujas para descarte, isso ser\u00e1 gradualmente processado do buffer do kernel pelo pgflush. <\/p>\n
<\/p>\n
Se essas p\u00e1ginas sujas continuam se acumulando, elas podem chegar a 20%, ap\u00f3s o que o sistema operacional prioriza registrar isso no disco, pois a energia pode falhar e tudo ficar\u00e1 comprometido. Podemos perder esses dados, por exemplo. <\/p>\n
<\/p>\n
Qual \u00e9 o truque? O truque consiste no fato de que esses par\u00e2metros, que s\u00e3o 20% e 10% de toda a mem\u00f3ria RAM dispon\u00edvel na m\u00e1quina, s\u00e3o absolutamente insustent\u00e1veis do ponto de vista da capacidade de qualquer sistema de disco que voc\u00ea possui.<\/strong> <\/p>\n<\/p>\n
Imagine que voc\u00ea tem 128 GB de mem\u00f3ria RAM. 12,8 GB s\u00e3o processados pelo seu sistema de disco. E, independentemente do cache que voc\u00ea tenha ou do array que voc\u00ea possui, eles n\u00e3o conseguir\u00e3o suportar isso. <\/p>\n
<\/p>\n
<\/p>\n
Portanto, recomendamos que esses n\u00fameros sejam ajustados de acordo com a capacidade do seu controlador RAID.<\/strong> Aqui, eu forne\u00e7o uma recomenda\u00e7\u00e3o para um controlador que possui 512 MB de cache. <\/p>\n<\/p>\n
Para isso, basta definir vm.dirty_background em bytes. Essas configura\u00e7\u00f5es anulam as duas anteriores. Ou o ratio padr\u00e3o \u00e9 usado, ou aqueles ativados em bytes, ent\u00e3o funcionam os que est\u00e3o em bytes. Mas, como sou um consultor DBA e trabalho com diferentes clientes, procuro ser cauteloso, portanto, se em bytes, ent\u00e3o em bytes mesmo. Ningu\u00e9m deu garantias de que um bom administrador n\u00e3o aumentar\u00e1 a mem\u00f3ria do servidor, n\u00e3o o reiniciar\u00e1, enquanto o n\u00famero permanece o mesmo. Apenas calcule esses n\u00fameros para garantir que tudo se encaixa. <\/p>\n
<\/p>\n
O que acontece se voc\u00ea n\u00e3o se encaixar? Est\u00e1 registrado que qualquer flushing \u00e9 efetivamente interrompido, mas na verdade isso \u00e9 uma express\u00e3o figurativa. O sistema operacional enfrenta um grande problema \u2013 h\u00e1 muitas p\u00e1ginas sujas, portanto, efetivamente se interrompe todo IO gerado por seus clientes, ou seja, se o aplicativo SQL enviar uma consulta ao banco de dados, ele ficar\u00e1 aguardando. Qualquer input-output nela tem a mais baixa prioridade, pois o banco est\u00e1 ocupado com o checkpoint. E quando isso terminar, \u00e9 totalmente incerto. E quando voc\u00ea alcan\u00e7ar o flushing n\u00e3o em segundo plano, isso significa que todo IO est\u00e1 ocupado com isso. E enquanto n\u00e3o terminar, voc\u00ea n\u00e3o poder\u00e1 fazer nada. <\/p>\n
<\/p>\n
Existem tamb\u00e9m dois pontos importantes que est\u00e3o al\u00e9m do escopo deste relat\u00f3rio. Essas configura\u00e7\u00f5es devem corresponder \u00e0s configura\u00e7\u00f5es em postgresql.conf, ou seja, as configura\u00e7\u00f5es de checkpoints. E seu sistema de disco deve ser adequadamente configurado. Se voc\u00ea tem cache em RAID, deve haver uma bateria nele.<\/strong> As pessoas compram RAID com bom cache sem bateria. Se voc\u00ea tem SSD em RAID, eles devem ser de servidor, deve haver capacitores.<\/strong> Aqui est\u00e1 uma lista detalhada. Neste link est\u00e1 meu relat\u00f3rio sobre como configurar o desempenho do disco no PostgreSQL. Todos esses checklists est\u00e3o l\u00e1. <\/p>\n<\/p>\n
<\/p>\n
O que mais pode complicar muito a vida? S\u00e3o dois par\u00e2metros. Eles s\u00e3o relativamente novos. Por padr\u00e3o, podem estar ativados em diferentes aplicativos. E podem complicar a vida tanto quanto se forem ativados incorretamente. <\/p>\n
<\/p>\n
<\/p>\n
Existem duas coisas relativamente novas. Elas j\u00e1 apareceram nos n\u00facleos tr\u00eas. S\u00e3o sched_migration_cost em nanosegundos e sched_autogroup_enabled, que por padr\u00e3o \u00e9 um. <\/p>\n
<\/p>\n
E como eles complicam a vida? O que \u00e9 sched_migration_cost? O scheduler do Linux pode migrar um processo de uma CPU para outra. E para o PostgreSQL, que executa consultas, a migra\u00e7\u00e3o para outra CPU n\u00e3o faz sentido. Do ponto de vista do sistema operacional, quando voc\u00ea alterna janelas entre o openoffice e o terminal, isso pode ser bom, mas para o banco de dados \u2013 isso \u00e9 muito ruim.<\/strong> Portanto, uma pol\u00edtica razo\u00e1vel \u00e9 definir migration_cost como um valor alto, pelo menos alguns milhares de nanosegundos.<\/strong> <\/p>\n<\/p>\n
O que isso significar\u00e1 para o scheduler? Ele vai considerar que, durante esse tempo, esse processo ainda est\u00e1 quente. Ou seja, se voc\u00ea tiver uma transa\u00e7\u00e3o longa que est\u00e1 ocupada, o scheduler vai entender isso. Ele considerar\u00e1 que enquanto n\u00e3o passar esse timeout, n\u00e3o h\u00e1 necessidade de migrar esse processo. Se, nesse \u00ednterim, o processo estiver fazendo algo, ele n\u00e3o ser\u00e1 migrado, e continuar\u00e1 trabalhando na CPU que lhe foi designada. E o resultado ser\u00e1 excelente. <\/p>\n
<\/p>\n
O segundo ponto \u00e9 o autogroup. H\u00e1 uma boa ideia para cargas de trabalho espec\u00edficas, que n\u00e3o t\u00eam rela\u00e7\u00e3o com bancos de dados modernos \u2013 agrupar processos pelo terminal virtual de onde foram iniciados. Isso \u00e9 conveniente para algumas tarefas. Na pr\u00e1tica, o PostgreSQL \u00e9 um sistema multiprocessado com prefork que \u00e9 iniciado a partir de um \u00fanico terminal. Voc\u00ea ter\u00e1 um bloqueio para escrita, ponto de verifica\u00e7\u00e3o e todas as suas solicita\u00e7\u00f5es de cliente ser\u00e3o agrupadas em um \u00fanico scheduler, em uma \u00fanica CPU. E l\u00e1, elas v\u00e3o aguardar pacientemente at\u00e9 que ela fique livre, causando interfer\u00eancia entre si e ocupando-a por mais tempo. Essa \u00e9 uma situa\u00e7\u00e3o que n\u00e3o \u00e9 necess\u00e1ria diante de essa carga e, portanto, precisa ser desativada.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Meu colega Alexey Lesovsky fez testes com o pgbench padr\u00e3o, onde aumentou a ordem de migration_cost e desativou o autogroup. A diferen\u00e7a em uma m\u00e1quina fraca foi de quase 10%.<\/strong>. H\u00e1 uma discuss\u00e3o na lista de discuss\u00e3o do PostgreSQL, onde as pessoas apresentam resultados sobre como essas altera\u00e7\u00f5es afetaram a velocidade das consultas. impactaram em 50%.<\/strong>. H\u00e1 muitas dessas hist\u00f3rias.<\/p>\n<\/p>\n
<\/p>\n
E por \u00faltimo, sobre a pol\u00edtica de economia de energia. \u00c9 bom que agora o Linux possa ser utilizado em laptops. E supostamente ele ir\u00e1 consumir a bateria de forma eficiente. Mas de repente, descobre-se que em servidores isso tamb\u00e9m pode acontecer. <\/p>\n
<\/p>\n
Al\u00e9m disso, se voc\u00ea alugar servidores de algum provedor, os 'gentis' hospedagem<\/a> n\u00e3o se preocupam em garantir que voc\u00ea tenha um desempenho melhor. O objetivo deles \u00e9 maximizar a efici\u00eancia da utiliza\u00e7\u00e3o do hardware. Assim, por padr\u00e3o, podem ativar o modo de economia de energia da vers\u00e3o para laptop no sistema operacional.<\/p>\n<\/p>\n
Se voc\u00ea estiver usando isso em um servidor com banco de dados sobre alta carga, sua escolha deve ser acpi_cpufreq + performance. Mesmo com ondemand, j\u00e1 haver\u00e1 problemas.<\/strong> <\/p>\n<\/p>\n
Intel_pstate \u00e9 um driver um pouco diferente. E agora a prefer\u00eancia \u00e9 dada a este, pois \u00e9 mais recente e funciona melhor.<\/p>\n
<\/p>\n
E, consequentemente, o governor deve ser apenas performance. Ondemand, powersave e outras op\u00e7\u00f5es n\u00e3o s\u00e3o para voc\u00ea. <\/p>\n
<\/p>\n
Os resultados do explain analyze no PostgreSQL podem variar em v\u00e1rios ordens de magnitude se voc\u00ea ativar o powersave, porque o CPU sob seu banco de dados ser\u00e1 agendado de forma totalmente imprevis\u00edvel.<\/p>\n
<\/p>\n
Essas configura\u00e7\u00f5es podem ser ativadas por padr\u00e3o. Verifique atentamente se elas foram ativadas por padr\u00e3o. Isso pode ser realmente um grande problema. <\/p>\n
<\/p>\n
<\/p>\n
E no final, eu gostaria de agradecer aos membros da nossa equipe de DBA da PosgreSQL-Consulting, especificamente ao Max Boguk e ao Alexey Lesovsky, que aprendem com as dificuldades todos os dias. E para nossos clientes, tentamos fazer o melhor para que tudo funcione perfeitamente. \u00c9 como com as instru\u00e7\u00f5es de seguran\u00e7a de avia\u00e7\u00e3o. Tudo est\u00e1 escrito com sangue. Cada um desses problemas foi descoberto durante alguma dificuldade. Fico feliz em compartilh\u00e1-los com voc\u00eas.<\/p>\n
<\/p>\n
Perguntas:<\/p>\n
<\/p>\n
Obrigado! Se, por exemplo, uma empresa deseja economizar e hospedar tanto o banco de dados quanto a l\u00f3gica de aplica\u00e7\u00e3o em um \u00fanico servidor, ou se a empresa segue a tend\u00eancia da arquitetura de microservi\u00e7os, onde o PostgreSQL \u00e9 executado em um cont\u00eainer. Qual \u00e9 o ponto? O sysctl afeta globalmente todo o n\u00facleo. Nunca ouvi dizer que sysctl possa ser virtualizado para funcionar separadamente em cont\u00eaineres. Existem apenas cgroups e l\u00e1 s\u00f3 h\u00e1 controle parcial. Como podemos conviver com isso? Ou se voc\u00ea deseja desempenho, deve executar o PostgreSQL em um servidor f\u00edsico separado e otimiz\u00e1-lo?<\/em><\/p>\n<\/p>\n
Respondemos \u00e0 sua pergunta de aproximadamente tr\u00eas maneiras. Se n\u00e3o estamos falando de um servidor f\u00edsico que pode ser ajustado, ent\u00e3o relaxe, tudo funcionar\u00e1 bem sem essas configura\u00e7\u00f5es. Se voc\u00ea estiver enfrentando uma carga que exija tais ajustes, ent\u00e3o voc\u00ea chegar\u00e1 a um servidor f\u00edsico antes mesmo de precisar dessas configura\u00e7\u00f5es.<\/p>\n
<\/p>\n
Qual \u00e9 o problema? Se for uma m\u00e1quina virtual, voc\u00ea provavelmente ter\u00e1 muitos problemas, por exemplo, a lat\u00eancia dos discos em muitas m\u00e1quinas virtuais \u00e9 bastante inconsistente. Mesmo que a largura de banda dos discos seja boa, uma transa\u00e7\u00e3o falhada durante opera\u00e7\u00f5es de entrada e sa\u00edda, que n\u00e3o afeta muito a m\u00e9dia da largura de banda, pode causar s\u00e9rios problemas durante o checkpoint ou ao gravar no WAL, e voc\u00ea notar\u00e1 isso antes de se deparar com esses problemas. <\/p>\n
<\/p>\n
Se voc\u00ea tiver o NGINX no mesmo servidor, tamb\u00e9m ter\u00e1 o mesmo problema. Ele competir\u00e1 pela mem\u00f3ria compartilhada. E voc\u00ea n\u00e3o chegar\u00e1 aos problemas descritos aqui.<\/p>\n
<\/p>\n
Mas por outro lado, alguns desses par\u00e2metros ainda ser\u00e3o relevantes para voc\u00ea. Por exemplo, configurar o dirty_ratio com sysctl para que n\u00e3o fique t\u00e3o alto \u2013 de qualquer forma, isso ajudar\u00e1. De qualquer jeito, voc\u00ea ter\u00e1 intera\u00e7\u00e3o com o disco. E essa intera\u00e7\u00e3o seguir\u00e1 um padr\u00e3o inadequado. Esses par\u00e2metros que mostrei s\u00e3o, na verdade, os padr\u00f5es. E, de qualquer forma, \u00e9 melhor alter\u00e1-los. <\/p>\n
<\/p>\n
Com NUMA podem surgir problemas. O VmWare, por exemplo, funciona bem com NUMA com configura\u00e7\u00f5es exatamente opostas. E aqui \u00e9 preciso escolher \u2013 servidor f\u00edsico ou n\u00e3o f\u00edsico. <\/p>\n
<\/p>\n
Tenho uma pergunta relacionada ao Amazon AWS. Eles t\u00eam imagens pr\u00e9-configuradas. Uma delas se chama Amazon RDS. Existem configura\u00e7\u00f5es personalizadas para o sistema operacional deles?<\/em><\/p>\n<\/p>\n
Existem configura\u00e7\u00f5es l\u00e1, mas s\u00e3o configura\u00e7\u00f5es diferentes. Aqui estamos configurando o sistema operacional do ponto de vista de como o banco de dados vai usar isso. E l\u00e1 h\u00e1 par\u00e2metros que determinam para onde devemos ir agora, como um shaping. Ou seja, precisamos de tantos recursos, e agora vamos consumi-los. Depois disso, o Amazon RDS ajusta esses recursos, e a performance cai. H\u00e1 hist\u00f3rias separadas de como as pessoas come\u00e7am a manipular isso. \u00c0s vezes, at\u00e9 de forma bastante bem-sucedida. Mas isso n\u00e3o tem rela\u00e7\u00e3o com as configura\u00e7\u00f5es do SO. \u00c9 como se fosse uma hackea\u00e7\u00e3o na nuvem. \u00c9 outra hist\u00f3ria.<\/p>\n
<\/p>\n
Por que as Transparent Huge Pages n\u00e3o t\u00eam efeito em compara\u00e7\u00e3o com as Huge TLB?<\/em><\/p>\n<\/p>\n
N\u00e3o t\u00eam. Isso pode ser explicado de v\u00e1rias maneiras. Mas, na pr\u00e1tica, elas simplesmente n\u00e3o produzem efeito. Qual \u00e9 a hist\u00f3ria do PostgreSQL? Ao iniciar, ele aloca um grande bloco de mem\u00f3ria compartilhada. Se s\u00e3o Transparent ou n\u00e3o Transparent \u2013 isso n\u00e3o importa. O fato de serem alocadas na inicializa\u00e7\u00e3o explica tudo. E se houver muita mem\u00f3ria e for necess\u00e1rio reconstruir o segmento de shared_memory, ent\u00e3o as Transparent Huge Pages se tornar\u00e3o relevantes. No PostgreSQL, elas simplesmente s\u00e3o alocadas como um bloco grande no in\u00edcio e \u00e9 isso, depois nada de muito especial acontece. Claro, pode-se usar, mas h\u00e1 a chance de ocorrer corrup\u00e7\u00e3o de shared_memory quando ele tentar realocar algo. O PostgreSQL n\u00e3o sabe disso.<\/p>\n
Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 2015 \u0433\u043e\u0434\u0430 \u0418\u043b\u044c\u0438 \u041a\u043e\u0441\u043c\u043e\u0434\u0435\u043c\u044c\u044f\u043d\u0441\u043a\u043e\u0433\u043e "Linux tuning to improve PostgreSQL performance" Disclaimer: \u0417\u0430\u043c\u0435\u0447\u0443 \u0447\u0442\u043e \u0434\u043e\u043a\u043b\u0430\u0434 \u044d\u0442\u043e\u0442 \u0434\u0430\u0442\u0438\u0440\u043e\u0432\u0430\u043d \u043d\u043e\u044f\u0431\u0440\u0435\u043c 2015 \u0433\u043e\u0434\u0430 \u2014 \u043f\u0440\u043e\u0448\u043b\u043e \u0431\u043e\u043b\u044c\u0448\u0435 4 \u043b\u0435\u0442 \u0438 \u043f\u0440\u043e\u0448\u043b\u043e \u043c\u043d\u043e\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438. \u0420\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u043c\u0430\u044f \u0432 \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0432\u0435\u0440\u0441\u0438\u044f 9.4 \u0443\u0436\u0435 \u043d\u0435 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442\u0441\u044f. \u0417\u0430 \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0438\u0435 4 \u0433\u043e\u0434\u0430 \u0432\u044b\u0448\u043b\u043e 5 \u043d\u043e\u0432\u044b\u0445 \u0440\u0435\u043b\u0438\u0437\u043e\u0432 PostgreSQL \u0432\u044b\u0448\u043b\u043e \u0438 15 \u0432\u0435\u0440\u0441\u0438\u0439 \u044f\u0434\u0440\u0430 Linux. \u0415\u0441\u043b\u0438 \u043f\u0435\u0440\u0435\u043f\u0438\u0441\u044b\u0432\u0430\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84083,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84082","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Ajuste](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n