Re: Puede pg_basebackup afectar performace?

> On 15/10/2019, at 4:49 AM, Carlos T. Groero Carmona <ctonetg(at)gmail(dot)com> wrote:
>
> Hola Horacio como siempre agradecido por tus comentarios, mis respuestas las encontraras en rojo

Hola si usas New Relic, instalaste el agente del S.O. ? para monitorear los IO de los discos ?

de casualidad has corrido el defrag del XFS ?

Sobre bajar la cantidad de los discos en RAID 10 ( es mi idea o estas usando raid por software ? ). Las maquinas de producción deben ser discos con raid por hardware.
NOTA: En arreglos de discos grandes en un sistema de 500 TB hice unas pruebas y el cache termine desactivandolo, bajo IO intenso el cache era el cuello de botella.

Cuando estes haciendo el proceso saca un sosreport ( es una foto al S.O. con todo lo necesario para diargnosticar la maquina, RedHat lo usar para diagnosticos de hecho ).

>
> On Mon, Oct 14, 2019 at 12:19 AM Horacio Miranda <hmiranda(at)gmail(dot)com <mailto: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
> >