Re: Urgente, postgres down

On 14/02/2019 6:21 PM, Carlos T. Groero Carmona wrote:
> Horacio gracias por sus comentarios.
> Dejame comentar que en mi caso tengo template0 y template1, pude
> conectarme a template1 y hacerle vacuum a toda la base de datos, pero
> no puedo conectarme a template0, esta situacion me preocupa.
template1 esta abierto para conectarse y template0 no lo esta, es normal
que no te puedas conectar al template0.
>
> datname|max | percentage
>
> -----------+------------+-----------
>
> template0 | 1586628037 | 75.55
>
> template1 |277797489 |13.22
>
> (2 rows)
>
>
> La base de datos de production esta al 28%, como le dije, las base de
> datos a las cuales puedo conectarme no me preocupan, solo template0
> porque no puedo hacerle vacuum.
>
Estas usando el plugin de new relic para postgresql ?

https://newrelic.com/plugins/boundless-production/109

https://www.youtube.com/watch?v=iYPFLKh1vP4

> Estaba pensando en disminuir la configuracion de
> autovacuum_freeze_max_age a 1 billon forzando autovacuum a encargarse
> de esa base de datos.
>
>
> Sobre el uso de I/O adjunto 2 screenshoot tomados en NewRelic el
> viernes pasado, que fue cuando tuve que desactivar autovacuum por casi
> 2 horas esperando que el sistema volviera a su normalidad, despues de
> estar dos horas estabilizado lo volvi a activar y desminui el
> cost_limit, desde entonces no hemos tenido mas problema con la base de
> datos.
>
>
> Saludos,
>
> Carlos.
>
>
>
>
> On Wed, Feb 13, 2019 at 4:06 PM Horacio Miranda <hmiranda(at)gmail(dot)com
> <mailto:hmiranda(at)gmail(dot)com>> wrote:
>
>
> 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 ).
>
>>