Me alegra que este andando todo mejor. muchas gracias por compartir la
información.
Recuerda que puedes mejorar un más las comunicaciones de los WAL cuando
usas compression en los canales.
Ahora un truco, la compression solo usa una CPU. para tener compression
con varios canales puedes hacer balanceo de carga con varios canalaes (
proxy reversos ).
-C ( para comprimir ) .
Ejemplo.
HA proxy (port 2222) ===== (port
2231,2232,2233,2234,2235,2236,2237,2238,2239) ( igualas la cantidad de
cpu ) y con esto tienes tantos canales como WAL en paralelo o streams
tengas, revisa los puertos usados al mismo tiempo ), debiera mejorar la
velocidad de transmissión). Se que algunos SDWAN hacen algo similar.
Hace la prueba de concepto y puede que te gusten los resultados.
Recuerda que estan las zonas locales en Chile con eso la latencia es
mucho menor.
Habilitar MTU 9000 en el enlace directo a AWS y con eso estas con todas
las mejoras que puedo imaginar.
A nivel de redes puedes hacer offload de los checksum.
No se me ocurre otra cosa que pueda mejorar tu velocidad.
On 27/04/2023 12:51 am, Fernando Monjes wrote:
Hola Horacio.,
Te comento que finalmente encontramos la solución , y se
debió al parámetro de Postgresql "logical_decoding_work_mem", si bien
suena lógico modificarlo, solo después de un arduo trabajo de empezar
a acotar llegamos que estaba muy bajo y lo aumentamos a 16GB y
funcionaron los consumidores de la replicación sin problemas,
te agradezco tu apoyo y si bien la solución estaba en pg, tus
recomendación en el ámbito de networking ayudaron a mejorar y poner en
la mesa varios temas que debemos abordar.
Atte.,
El mié, 19 abr 2023 a las 0:05, Horacio Miranda (<hmira...@gmail.com>)
escribió:
On 19/04/2023, at 2:07 AM, Fernando Monjes <ing.bo...@gmail.com>
wrote:
Hola Horacio , gracias por la respuesta y disposición de ayudar ,
estamos revisando con personal de redes lo que mencionas.,
de igual forma forma me interesa chequear que mi configuración de
replicación lógica este correcta, vi en este hilo
PostgreSQL: Re: Retraso de replicación debido al retraso
restart_lsn
<https://www.postgresql.org/message-id/CACG9ogw%2BNaq08%2BosrYxc-6Skbp3QMeQ6aZ2%3DmFcy5HJ1Hr2U0g%40mail.gmail.com>
que
"el número máximo de cambios guardados en la memoria por
transacción es de 4 MB" esto me llama la atención es modificable,
se puede aumentar ?
Depende de como estén replicando, pégale una mirada a esto.
https://www.migops.com/blog/setting-up-streaming-replication-in-postgresql-13-and-streaming-replication-internals/
Esto debiera decirte como vas con la replicación.
psql -x -c "select * from pg_stat_replication"
y dejando el tema de red aun lado, cual seria un tunning de BD
correcto para soportar este escenario, que al recibir un aumento
de carga la replicación queda atrasada y no transmite los datos
(replicación lógica nativa), estoy con Postgresql versión 13.8
Quieres que la replicación tenga un delay ? o tu pregunta esta
relacionada a que esta atrazada y te interesa que este menos
trasada ( casí syncronica ?)
Gracias
El mar, 11 abr 2023 a las 18:34, Horacio Miranda
(<hmira...@gmail.com>) escribió:
En Amazon en tu security group activa el ICMP type 3 : type 4
asegúrate que el pmtud funciona. Desde tu máquina onPrem hace
un tracepath
Si te entiendo bien el problema lo tienes cuando hay muchos
datos y algo pasa que deja de funcionar. Si es lo que
sospecho en AWS estas con MTU 9000 o en tu datacenter y como
PMTUD no esta activado por que los ICMP los bloquean los de
seguridad hay fragmentación esta fragmentación no es buena en
internet sobre todo si paquetes salen con flag DF que es no
fragmentar y los servidores terminan configurando un mss
mínimo maximo de 536 bytes. Si esto es complicado hay un par
de vídeos buenos que explican este tema. En palabras simples
hace que tracepath pmtud salga y vas a estar bien
Regards,
Horacio Miranda
> On 12/04/2023, at 9:57 AM, Fernando Monjes
<ing.bo...@gmail.com> wrote:
>
>
> Hola Amigos
>
> Tengo un problema, estoy con una instancia amazon aws donde
tengo postgres v13.8 y onpremise un postgres 14.7, tengo
configurado una réplica lógica nativa de 4 tablas usando slot
plugin pgoutput, usando publicador en aws y subscriptor en
onpremise postgres , la bd en aws tiene total de 30 tablas ,
el problema que ocurre es que en un estado de mucha carga a
las restantes tablas en aws, la réplica de las 4 tablas del
publicador deja de funcionar y no sigue transmitiendo datos,
esto hace que crezca el slot, siendo esto otro problema, pero
el punto es por que deja de transmitir datos. no se si
alguien ha tenido un problema similar
>
> --
> Gracias cualquier aporte
>
> Fernando Monjes B.
> Consultor DBA
> Cel: +56 9 7852 1024
--
Atentamente,
Fernando Monjes B.
Consultor DBA
Ingeniero en Informática
Cel: 09 -78521024
--
Atentamente,
Fernando Monjes B.
Consultor DBA
Ingeniero en Informática
Cel: 09 -78521024
