Tenho o PostgreSQL 15 em execução em um pod do Kubernetes usando a imagem Zalando Spilo, gerenciada pelo Patroni. O contêiner tem um limite de memória de 16 GB e o tamanho do banco de dados é de 40 GB (diretório de dados no disco). Quando reinicializo uma réplica com o Patroni, ele executa "basebackup.sh", que por sua vez executa o comando "pg_basebackup":
/usr/lib/postgresql/15/bin/pg_basebackup --pgdata=/home/postgres/pgdata/pgroot/data -X none --dbname='dbname=postgres user=standby host=<Leader IP> port=5432'
Percebi que os primeiros 16 GB são copiados rapidamente, mas o processo fica significativamente mais lento depois (observei que, após a cópia, o tamanho é aproximadamente igual aos limites de memória do contêiner). Aumentar o limite de memória do contêiner para 32 GB mostrou um padrão semelhante: os primeiros 32 GB foram copiados rapidamente e, em seguida, o processo ficou mais lento.
Executando o comando manualmente:
/usr/lib/postgresql/15/bin/pg_basebackup --pgdata=/home/postgres/pgdata/pgroot/dummy_dir -X none --dbname='dbname=postgres user=standby host=<Leader IP> port=5432'
o problema foi reproduzido. Quando a memória total do contêiner (incluindo cache de páginas e arquivos inativos, que representam uma grande parte da memória RAM do contêiner) atinge o limite, o 'pg_basebackup' fica lento. Outras operações de gravação em disco (por exemplo, gerar e copiar arquivos grandes com 'dd') não são afetadas pelo limite de memória e permanecem rápidas.
Quando 'pg_basebackup' está lento e o limite de memória do contêiner é atingido, tentei descartar o cache de página com: " sync && echo 3 > /proc/sys/vm/drop_caches
" e isso tornou 'pg_basebackup' rápido novamente.
O desempenho do 'pg_basebackup' é limitado pelo cache da página de arquivos? Você precisa de alguma informação adicional? Alguma sugestão? Obrigado pela ajuda!
Responderei minha própria pergunta aqui: (Depois de brincar com o contêiner bruto e o cgroup bruto (systemd-run) e observar o mesmo problema)
Parece que é um bug no Oracle Linux (OL) 9.2 RHCK Kernel "kernel-5.14.0-284.11.1" (veja a tabela: https://docs.oracle.com/en/operating-systems/oracle-linux/9/boot/oracle_linux9_kernel_version_matrix.html )
Mudar para o Kernel UEK da mesma versão do OL (9.2) resolveu o problema, mas o UEK não é suportado por alguns SW (por exemplo, Vertica DB), então tentei atualizar os Kernels RHCK: somente o Kernel e as dependências do OL9.4 (kernel-5.14.0-427) e OL9.5 (kernel-5.14.0-503.11.1) - ambos corrigiram o problema, com a observação: suspeita-se que a atualização do RHCK usando um do OL9.5 tenha alguns problemas de compatibilidade de HW (sob investigação). Mais alguns detalhes discutidos aqui: https://www.linuxquestions.org/questions/linux-containers-122/performance-degradation-with-rsync-in-container-or-cgroupv2-with-mem-limit-on-oracle-linux-9-2-rhck-5-14-vs-uek-5-15-a-4175749063/