> On 15/10/2019, at 4:49 AM, Carlos T. Groero Carmona <cton...@gmail.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 <hmira...@gmail.com 
> <mailto:hmira...@gmail.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
> >

Reply via email to