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
