> 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 > >
