Re: Puede pg_basebackup afectar performace?

Hola Horacio como siempre agradecido por tus comentarios, mis respuestas
las encontraras en rojo

On Mon, Oct 14, 2019 at 12:19 AM Horacio Miranda <hmiranda(at)gmail(dot)com> wrote:

>
> 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 ? Yo uso New Relic para monitorear todo el sistema y tambien uso
> el New Relic Postgres Integration Plugin, antes de empezar el pg_basebackup
> el tiempo de respuesta por request de postgres era 1.96 ms y cuando el
> pg_basebackup encontro el checkpoint y empezo a copiar los archivos el
> tiempo de respuesta aumento a 489ms per request ( 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 ?
>
Durante el tiempo en que se ejecuto el pg_basebackup estaba
monitoreando todo, pgbouncer pool, Tiempo de Respuesta del sistema, tiempo
de respuesta de postgres, utilizacion de discos, RAM, CPU en mi servidor
primario y mi servidor secundario del cual se estaban copiando los archivos.
CPU: el uso del CPU en ambos servidores estaban or debajo del uso promedio
Pgbouncer pool: el numero de clientes activos aumentaba al mismo tiempo el
tiempo de respuesta de todo el systema aumentaba
Ram: no se vio affectada
Discos: el uso de disco en el servidor secundario aumento considerablemente
(de este servidor es de donde yo estaba copiando los archivos con el
ph_basebackup), cuando aumentaba el uso del disco en el servidor secundario
entonces aumentaba el tiempo de respuesta tambien. Los discos del sevidor
primario no se vio afectado.

Esos servidores tienen 790GB of RAM, asi que le tengo asignada alrededor
del 30%

Algo que debo resaltar, es cuando use pg_basebackup anteriormente, este
necesito alrededor de 18 horas para terminar, sin embargo ahora lo hizo
solo en 8 horas y medias, casi la mitad del tiempo y ahora tengo mas data
que cuando pg_basebackup necesito mas tiempo, lo qu eme hace pensar que
como el servidor que esta copiando tiene 3 veces mas CPU que el servidor
del cual se esta copiando esto afecta mas drasticamente el comportamiento
de esos servidores.

>
> > 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. Estuve monitoriando el TPS que estaban pasando
> y comparandolas con las de la semana anterior utilizando un Chart, por lo
> que podia ver el comportamiento que tenia el sistema con el que tubo al
> mismo tiempo una semana anterior, y si decrecio un poco las TPS pero no
> drasticamente.
> >
> > 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. En estos momento diria que mi cuello de botella
> estaria en los discos, porque es cierto que tengo RAID 10, pero los discos
> utilizados quizas eran de 1GB con bajos I/O y throughput, pero eso es algo
> que no podre arreglar por ahora. Todos los servidores usan XFS en los
> discos donde postgres tiene Data Directory

Horacio, una pregunta, supon que tienen 5 discos para postgres cierto, yo
estoy pensando en crear un volumen logico stripped y tener todo lo de
postgres ahi, sin embargo, hay personas que me estan recomendando utilizar
quizas 4 para pg_data y uno para pg_xlog, creo que dividiendo los discos
voy a perder I/O y Throughput, todos los discos son iguales 2TB cada uno
con 2500 I/O y 250 MB/s throughput. Cual es tu opinion?

> >
> > Saludos,
> > Carlos
> >
>