Re: Urgente, postgres down

On 14/02/2019 6:18 AM, Carlos T. Groero Carmona wrote:
> Horacio gracia spor su respuesta, abajo los comentarios despues de
> revisar cada uno de sus puntos.
>
> On Mon, Feb 11, 2019 at 4:35 AM Horacio Miranda <hmiranda(at)gmail(dot)com
> <mailto:hmiranda(at)gmail(dot)com>> wrote:
>
> Creo que hay varios problemas aquí, podemos ver los más basicos.
>
> Estoy de acuerdo, tratando de figurar cuales, y super agradecido por
> la ayuda brindada
>
> Revisa que las llaves Foraneas tengan indices.
> https://dba.stackexchange.com/questions/121976/discover-missing-foreign-keys-and-or-indexes
>
> Despues de usar la informaci'on en el link que me mandas y hacer una
> comparaci'on entre el uso de sequencias y de indeces, puedo decir que
> no tenemos falta de indices en la base de datos, o al menos solo 3
> tablas han usado mas secuencias que indexes y el tamano de estas
> tablas es inferior a 10MB. Asi que creo que no es el uso de indices,
> tenemos de sobra, eso si puedo asegurarle, estoy tratando de revisar
> con el equipo de desarrollo y me aprueben quitar aquellos donde no se
> requieren o no se usan, tratando de aumentar la velocidad de escritura.
>
> Dices que tienes tablas particionadas, esto solo sirve si las
> consultas tienen en el Where el criterio de la particion, si son
> por fechas que las consultas en la tabla gigantesca sean por
> fechas. de lo contrario no te va a ayudar mucho.
>
> Si, las consultas que usamos utilizan los indices correctamente, lcomo
> quiera estoy usando pgBadger para identificar las queries mas lentas y
> analizar como puedo mejorar su rendimiento.
>
> Los parametros el S.O. los ajustaste para manejar una base de
> datos grande ? Usas un Filesystem como XFS ? ( me gusta más que
> ext3 o ext4 ) pero es algo personal.
>
> El kernel del SO me permite usar hasta 137 GB of sahed memory, solo
> estoy utilizando 24 GB en el shared_bufer.
>
> Sobre los IO. iostat -m -x /dev/sd? 3 ( que te dice, contención ? ).
>
> avg-cpu:%user %nice %system %iowait%steal %idle
>
> 16.900.006.391.540.00 75.17
>
>
> Device: rrqm/s wrqm/s r/s w/srMB/swMB/s avgrq-sz avgqu-sz await
> r_await w_awaitsvctm%util
>
> dm-50.00 0.005.94 41.94 0.22 0.1616.47 0.010.17 11.463.76 0.31 1.48
>
> sar ( que te dice sobre las contenciones ? ).
>
> 07:30:01 AM CPU %user %nice %system %iowait%steal %idle
>
> 07:40:01 AM all 28.480.00 12.282.410.00 56.83
>
> 07:50:01 AM all 27.730.00 11.982.210.00 58.07
>
> 08:00:01 AM all 28.740.00 12.382.060.00 56.82
>
> 08:10:01 AM all 32.540.00 14.272.260.00 50.93
>
> 08:20:01 AM all 31.960.00 13.952.250.00 51.84
>
> 08:30:01 AM all 33.870.00 14.662.410.00 49.06
>
> 08:40:01 AM all 33.180.00 14.452.570.00 49.80
>
> 08:50:01 AM all 33.350.00 14.682.580.00 49.38
>
> 09:00:01 AM all 33.900.00 14.962.430.00 48.71
>
> 09:10:01 AM all 38.930.00 17.022.720.00 41.33
>
> 09:20:01 AM all 38.840.00 16.942.370.00 41.85
>
> Average:all 16.450.007.211.180.00 75.16
>
> Los discos en la maquina real estan todos sanos ?
>
> Si, lo unico que no contribuye mucho es que usamos SAN, por eso vamos
> a cambiar a otro servidor para usar SSD.
No veo contención a nivel de disco, revisa de forma continua que le
ocurre a la maquina ( mira datadog para monitoreo ) o si usas otra
herramienta conecta el SO para capturar los IO de disco.
>
> La fuente de poder estan las dos activas ? ( una fuente puesta en
> un servidor pero desenchufada va a desabilitar los cache de las
> controladora.
>
> El servidor esta en RackSpace, voy a preguntar, aunque no creo que eso
> sea posible, ese servicio cuesta bien caro.
no importa este punto, no hay contención de discos.
>
> Los cache estan funcionando ? ( supongo que tienes algo como HP o
> DELL, o alguna marga que no sea un PC armado corriendo aquí ).
>
> Tenemos un Dell Inc. PowerEdge R720. CPU:24 RAM:512
>
> el shmmax esta reajustado de acuerdo al shared buffers ? ( no
> puedes tener un shared buffer grande si no tienes el S.O. en
> sintonía con la base de datos. ( elimina el Swap si puedes ), y no
> asignes más del 80% a la base de datos si es lo unico que corre ahi ).
>
Si tienes una maquina con 512G RAM usa la RAM para porgres lo que más
puedas.

Usa este link para estimar los parámetros. https://pgtune.leopard.in.ua/#/

> cat /proc/sys/kernel/shmmax = 137438953472 = ~137GB
>
> postgres=# show shared_buffers;
>
> shared_buffers
>
> ----------------
>
> 24GB
>
> (1 row)
>
> Sobre python ( lee sobre pool y postgresql ).
>
> Si usas jdbc ( pasa el parametro
> /-Djava.security.egd=file:/dev/./urandom )//
> /http://ruleoftech.com/2016/avoiding-jvm-delays-caused-by-random-number-generation
> ).
>
> He estado leyendo sobre como y la importancia de usar un connection
> pool, en estos momentos no es una opcion cambiar la arquitectura ni
> modificar el codigo de los sistemas para manejar mas eficiente la
> forma de escribir en la BD, por eso propuse revisar la configuracion
> del connection pool que trae implementado Ruby/Rails, que si se esta
> utilizando se esta usando la configuration por defecto, que es 5, pero
> hay varios parametros que afentan el numero final de conectiones por
> servidores, no solo dependiendo del valor especificado en la
> configuarion del pool, he estado leyendo bastante al respecto desde
> que hablamos hace como 6 semanas atras de la necesidad de usar
> pgBouncer. Esto resume bastante bien como funciona Ruby/Rails:
> https://devcenter.heroku.com/articles/concurrency-and-database-connections#connection-pool
>
> Puede que no sea importante, pero /dev/random es super malo para
> muchas conexiones sobre todo si no usas pooling con java.
>
> Una pregunta, cuando dices /dev/random te refires al FS? este es el
> mio: /dev/mapper/X-X
No, en Linux todo es un archivo, /dev/random es un dispositivo que crea
numeros random en base a entropia ( para tener numeros realmente randoms
) ahora el problema es que la entropia no esta disponible siempre, para
mejorar el rendimientos en programas que usan cryptografia yo uso
/dev/urandom, apache /dev/urandom, etc. Hay varios articulos que hablan
sobre que es un mito urbano que /dev/random es mejor que /dev/urandom ya
que ambos usan la misma libreria para generar los numeros aleatorios.
>
> Es super raro que la base template1 este tan fragmentada, algo
> debe estar escribiendo y borrando cosas. revisa que tabla es,
> puede que sea alguna de estadisticas.
>
> Analizando el crecimiento diaria (cada 24H) he visto que el promedio
> diario de crecimiento del XID es alrededor de 44millones, esto afecta
> todas las base de datos en el servidor por igual, es decir todas
> crecen con el mismo indice, incluyendo template1 y template0. La unica
> que me preocupa seriamente es template0, pues no puedo ejecutar un
> vacuum y no estoy seguro si esta "base de datos" podria dejarme el
> servidor fuera de servicio nuevamente, actualmente el XID de template1
> es 1 562 227 160 representando el 74% de 2.1 billon.
>
> Seria bueno saber si existe alguna manera de hacerle vacuum a
> template0 o en el caso que template1 alcance los 2.1billon que pasaria?
>
Template1 es como decirlo el corazón de postgres, si esa base esta
muerta, todo lo medas muere con ella ( en realidad puedes copiar los
directorios por debajo en terioría pero solo me toco hacer una
chancheria como esa una sola vez en mi vida con postgres 6.2 y ResiserFS
o algo como eso, se recupero, nunca perdi un dato de producción con
postgres y por eso toco madera.

Este problema se ve super interesante, hay alguna forma de generar tu
data de forma random ? ( tengo maquinas en mi ambiente de pruebas
grandes para jugar ).

>