Re: Puede pg_basebackup afectar performace?

On Mon, Oct 14, 2019 at 11:43 AM Horacio Miranda <hmiranda(at)gmail(dot)com> wrote:

>
>
> On 15/10/2019, at 5:10 AM, Carlos T. Groero Carmona <ctonetg(at)gmail(dot)com>
> wrote:
>
>
>
> On Mon, Oct 14, 2019 at 10:59 AM Horacio Miranda <hmiranda(at)gmail(dot)com>
> wrote:
>
>>
>>
>> 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 ? 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. Interesante,
> tengo autovacuum activado y de manera agresiva, y mi systema tiene un alto
> por ciento de update/delete, por lo que podria ser la causa, voy a espear
> al proximo fin de semana (Sabado Noche) para tratar de adicionar mi nuevo
> DR, por lo que el domingo les dejare saber como fue todo desactivando
> autovacuum y un cronjob que tengo para ejecutar un vacuum a toda la base de
> datos cada noche.
>
>
>> 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
> [root(at)db_serv9 ~]# multipath -ll
> Oct 14 13:24:43 | DM multipath kernel driver not loaded
> Oct 14 13:24:43 | /etc/multipath.conf does not exist, blacklisting all
> devices.
> Oct 14 13:24:43 | A default multipath.conf file is located at
> Oct 14 13:24:43 |
> /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf
> Oct 14 13:24:43 | You can run /sbin/mpathconf --enable to create
> Oct 14 13:24:43 | /etc/multipath.conf. See man mpathconf(8) for more
> details
> Oct 14 13:24:43 | DM multipath kernel driver not loaded
>

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