Eu executo o PostgreSQL 15 no Kube. Portanto, em cargas pesadas, quando o uso de RAM chega a 100%, o gravador WAL é esmagado e abortado. Devido à existência pid, nunca mais surge sem intervenção. Então, idealmente, eu gostaria de limitar sua RAM (como podemos fazer com cgroups no linux), digamos para 90% de uso. Portanto, gostaria de saber qual é a melhor maneira de limitar o uso de CPU e RAM de um cluster PostgreSQL em um pod. Acho que aqui os cgroups não seriam uma boa solução, pois sem a reinicialização do pod, a reinicialização do PostgreSQL pode ser perigosa.
relate perguntas
-
Posso ativar o PITR depois que o banco de dados foi usado
-
Práticas recomendadas para executar a replicação atrasada do deslocamento de tempo
-
Os procedimentos armazenados impedem a injeção de SQL?
-
Sequências Biológicas do UniProt no PostgreSQL
-
Qual é a diferença entre a replicação do PostgreSQL 9.0 e o Slony-I?
Não, cgroups é uma maneira extremamente ruim de gerenciar memória para PostgreSQL. Dá-lhe duas opções:
processos que excedem o limite são eliminados pelo OOM killer
processos que excedem o limite congelam até que outros processos liberem memória
O primeiro travará o PostgreSQL (mas voltará a funcionar, a menos que você o tenha configurado incorretamente) e o segundo também não é uma solução viável.
O truque é configurar
shared_buffers
,work_mem
, e paramax_connections
que o PostgreSQL nunca toque no limite. A memória "não utilizada" não é problema, pois o PostgreSQL a usará para armazenamento em cache.maintenance_work_mem
hash_mem_multiplier
Não existe uma regra segura para dimensionar esses parâmetros, mas uma regra prática que funciona na maioria dos casos é
shared_buffers
+2 *
work_mem
*max_connections
+maintenance_work_mem
*autovacuum_max_workers
≤ RAM