Overflow UDP / Drops UDP no Serviço Postgres em Espera

Question

Estou perplexo ao tentar impedir um buffer UDP transbordante em um serviço Postgres de reserva. Qualquer ajuda seria muito apreciada.

Essencialmente, um buffer UDP associado ao processo pg_standby na minha interface localhost é preenchido gradualmente depois que eu inicio o Postgres até que ele atinja sua capacidade máxima e depois continue soltando pacotes. Um reinício do Postgres (claro) limpa o buffer, mas depois começa a encher novamente.

Tanto quanto eu posso dizer, isso não está realmente causando problemas. (Isso está acontecendo apenas no serviço em espera e a recuperação de dados de failover não mostra nada ausente.) No entanto, não quero que nenhum buffer seja excedido.

Pontos importantes:

a) consultando as informações "/ proc" para o UDP, consigo ver buffers não vazios; e a porta UDP para o único buffer não vazio (hex E97B - > dec 59771) nos permite usar o netstat para mostrar a interface (localhost) e PID (438), o que confirma que o processo "pg_standby" é o culpado :

# cat /proc/net/udp | grep -v '00000000:0000'
sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops
16: 0100007F:E97B 0100007F:E97B 01 00000000:01000400 00:00000000 00000000   600        0 73123706 2 ffff880026d64ac0 0

# netstat -anp | grep 59771
udp   16778240      0 127.0.0.1:59771             127.0.0.1:59771             ESTABLISHED 438/pg_standby

# ps -F -p 438
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
postgres   438 29613  0  1016   496   0 11:18 ?        00:00:00 /usr/pgsql-9.1/bin/pg_standby -t /archive_wals/stoprecovery.trigger -c /archive_wals 000000010000000A000000C8 pg_xlog/RECOVERYXLOG 000000010000000A000000C6

b) o estouro ocorre mesmo quando meus firewalls em ambos os servidores (iptables) são desligados

c) meus buffers UDP parecem mais do que grandes o suficiente. Eu poderia torná-los maiores, mas isso apenas mascararia o problema

# grep rmem /etc/sysctl.conf  | grep -v tcp
net.core.rmem_max = 26214400
net.core.rmem_default = 16777216

d) discussões on-line sobre problemas semelhantes parecem mostrar versões mais antigas do Postgres ou do Statistics Collector; Para descartar isso, tentei desativar todas as coletas de estatísticas, mas o problema continua:

# egrep '(track)' postgresql.conf | grep -v '^\s*#'
track_activities = off
track_counts = off

e) o pacote UDP recebido não é muito informativo; um sniff verboso tshark mostra algo assim para cada novo pacote UDP descartado:

Data (72 bytes)
0000  0b 00 00 00 48 00 00 00 01 00 00 00 00 00 00 00   ....H...........
0010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0040  00 00 00 00 00 00 00 00                           ........
Data: 0B0000004800000001000000000000000000000000000000...
[Length: 72]

f) não há muita atividade de banco de dados (por exemplo, aproximadamente um arquivo WAL de 16 MB é replicado do serviço primário para o secundário a cada 45 minutos)

g) Eu anteriormente executei o Postgres 8.3.5, com uma configuração idêntica; este problema só começou quando eu atualizei para 9.1.9

Antecedentes na minha configuração:

1. dois sistemas CentOS 6.4 x86_64 bit (VMs), cada um executando o Postgres 9.1.9, cada um em um datacenter separado geograficamente (< 50 milhas)
2. O Postgres está ativo no meu servidor principal e em execução no modo de espera no meu backup:
3. o serviço Postgres de backup está recebendo seus dados de duas maneiras:
   • como um processamento em modo de espera warm WAL via envio de logs ( consulte as seções 25.2.1-25.2.4 aqui )
   • no failover, o arquivo WAL atual no primário (ainda não enviado) é recuperado de uma partição DRBD sincronizada da caixa principal ( sem procedimento padrão aqui, mas aqui está uma discussão
4. nada mais (de conseqüência) é executado nessas caixas, exceto o Postgres