> On 15/10/2019, at 5:10 AM, Carlos T. Groero Carmona <cton...@gmail.com> wrote: > > > > On Mon, Oct 14, 2019 at 10:59 AM Horacio Miranda <hmira...@gmail.com > <mailto:hmira...@gmail.com>> wrote: > > >> On 15/10/2019, at 4:49 AM, Carlos T. Groero Carmona <cton...@gmail.com >> <mailto: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 ? Si, tengo intalado el agente y tambien un plugin para > integrar y monitorear postgres y pgbouncer, estuve usando New Relic durante > todo el tiempo que pg_basebackup estuvo corriendo Si esta instalado que te dicen los graficos de latencia de los discos y revisa si el vacuum estaba corriendo o esta de forma automatica. puede que sea mejor desactivarlo y activarlo en la noche solamente o en baja carga. > > de casualidad has corrido el defrag del XFS ? No que yo sepa, el DC fue quien > monto y creo que el servidor y nosotros solo lo rentamos, tengo un hermano > del sevidor donde corry el pg_basebackup que no estoy usando ahora mismo, asi > que si me das mas detalles puedo correrlo ahi.
Ahh ahora entiendo, le llamar DC al Data Center y no Active Directory ( esa parte me tenia confundido ), el XFS defrag puede que no se haya corrido nunca. que te dice el comando, multipath -ll Que tipo de discos tienes ? mecanicos/ssd ,son multipath ? > > 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. Disculpa, creo qu eno me explique, cuando te hacia la pregunta sobre > los discos, como te comente estamos moviendonos hacia Azure, ali voy a > utilizar VMs y yo voy a administrar mis discos, no puedo usar RAID 10, asi > que solo puedo crear un volumen l'ogico stripped que practicamente suma los > I/O y el throughput como si fuera un solo disco, es decir si tengo los 5 > discos con los datos que te comentae, tendria un solo volumen logico stripped > como 2500*5 the I/O y 250 MB/s*5 the troughput, ahi tendria a postgres > corriendo, por lo que tendria data, pg_xlog, en fin todo lo de postgres, la > otra recomendacion que me hacen es separar discos un volumen de solo 4 discos > para pg_data y otro disco para pg_xlog. > > Voy a preguntar si el Raid es por software or hardware. Debe ser por hardware, AWS y Azure son plataformas comerciales con storage distribuidos a menos que compres los tiempos de un bare metal. Hace pruebas, los discos LVM debes tener en cuenta que si crear stripe 5, cuando crescas debes crecer de a 5 discos. NOTA Insisto que cuando tengas el problema de rendimiento saca un sosreport o un comando equivalente que saque una Foto del S.O. > > > 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 >> > >
