Re: Puede pg_basebackup afectar performace?

On 13/10/2019 1:19 PM, Carlos T. Groero Carmona wrote:
> Hola Lista,
Hola
>
> Dejenme introducir un porquito lo que esta pasando, en estos momentos
> estamos usando un DC, pero estamos estamos dando algunos pasos firmes
> para movernos para Azure, por lo que tengo 4 servidores en production
> y 3 mas en hold.
>
> Que significa esto:
> serv1 es mi servidor primario (location 1)
> serv2 es mi HA (location 1)
> serv3 va a ser mi servidor primario en Azure (Location 2)
> serv4 es mi DR (location3)
>
> Estoy replicando (SR) desde :
> * serv1->serv2
> Estoy Cascading replication:
> * serv2->serv3
> * serv2->serv4
>
> Pero cuando teniamos graves incidentes (P1) hace unos meses, se
> decidio rentar servidores nuevos con mayor capacidad, y por otras
> rasones se exagero en la capidad, los nuevos servidores tienen:
> CPU: 114 (74 cores, 2 Thread per Core)
> RAM: 790 Gb
> Disk 10 TB (RAID 10)
> OS: CentOS 7.x
>
> Mi actual servidor primario tiene:
> CPU: 48 (24 Cores * 2 thread)
> RAM: 790 GB
> Disk 5TB (RAID 10)
> OS: CentOS 7.x
>
> En todos los casos uso PostgreSQL 9.6
>
> En estos momentos estamos estables gracias a la correcta configuration
> de pgBouncer y solo en los momentos picos alcanzamos un 60% del uso
> del CPU, nuestro average es un 45%, asi que no se necesita utilizar
> los nuevos servidores, PERO, se ha decido ponerlos en hot standby por
> si se llega a necesitar en un futuro cercano, ya que como quiera se
> esta pagando por ellos.
>
> Asi que intente poner uno de estos nuevos servidores detrás de serv2 y
> se vio affectado el tiempo de respuesta del sistema, trate de ponerlo
> detras de serv1 y fue peor la affectation, en todo momento apenas que
> pg_basebackup empezo a copiar los datos se disparo el % de utilizaicon
> de l disco en serv1 o serv2 asi que detuve el pg_basebackup.

( estas usando compresion en los respaldos ? ), estas usando un arreglo
distindo al arreglo de discos de los datos vs los respaldos ?

Que te dice la cola de procesos y la los IO waits ?  del S.O. ? estas
usando XFS  como filesystem ?

>
> En un escenario pues lo deje correr detras de serv2 porque se affecto
> el tiempo de respuesta de postgres serca de 3 veces mas pero no
> impacto mucho el tiempo de respuesta del sistema, una vez que termino
> el pg_basebackup todo funciono correctamente y el tiempo de respuesta
> del sistema regreso a su normalidad.
A que te refieres con que afecto el tiempo de respuetsa de postgresql a
3 veces pero al mismo tiempo no impacto el tiempo de respuesta del
sistema ?  ( me tinca que tienes una cola en algun lado que esta
limitando el postgresql ), como estan tus parametros de open files ?
cuanta RAM tienes asignada al postgrsql ? y cuantos procesos al
postrgesql ?
>
> Mi hypotesis es que el monstrou de servidor nuevo esta chupandose todo
> el I/O a traves de pg_basebackup. Tienen ustedes alguna otra idea?
Que te dice el top ? lo mejor es correr un sysreport o sosreport para
saber que esta pasando justo en el momento de la falla o durante tu
problema para saber que esta pasando en la maquina.
>
> Si tienen alguna pregunta dejenme saber, tengo ulgunas imagenes de mi
> herramienta de monitoreo..
>
> Lo curioso es que las TPS no se vieron afectadas ni las queries por
> segundo.
Esto no lo entiendo, si el postrgresql esta mas lento tus TPS se veran
afectadas, esto esta raro.
>
> Como siempre cualquier sugerencia o explicacion sera apreciada.

En mi experiencia con bases de datos grandes, lo importante son los
canales entre las maquinas y el cypher que uses para conectarte entre
las bases de datos. Ejemplo sí usas un tunel SSH debes usar un tunel con
un cypher que no sea costoso, uncluso un NFS ( ahora los NFS son
peligrosos por que cuando se te pegan a nivel de kernel debes reiniciar
las maquinas no hay otra forma de recuperarse, NFSv4 soporta multipath.

yo revisaría los cuellos de botellas que tengas y los arreglaría uno por
uno, no hay otra forma, optimiza y estreza para saber donde esta tu
cuello de botella.

>
> Saludos,
> Carlos
>