Re: Urgente, postgres down

Carlos:

On Thu, Feb 14, 2019 at 6:22 AM Carlos T. Groero Carmona
<ctonetg(at)gmail(dot)com> wrote:
> 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.

Os veo comentar mucho sobre template0/1 y no se si teneis claro lo que
son. En un cluster ( servidor ) de postgres cada BD es una coleccion
de archivos en un directorio. Cuando creas una base de datos nueva,
necesitas unos datos minimos ( los catalogos del sistema y similares
). Postgres obtiene esos datos copiando una base de datos patron, un
template ( por eso puedes hacer "create database XX template YY", que
funciona incluso como una forma rapida de hacer backup).

Eso deja el problema del bootstrapping. Cuando inicializas el cluster,
con initdb, postgres usa un modo especial del servidor que permite
acceso a bajo nivel (busca BKI por la doc) para crear las tablas
globales y la base de datos template0, template0 no se debe en general
tocar, por eso la deja en modo no conectar. Tras ello crea template1
copiando template0, y esa es la que copia por defecto cuando creas tus
bases de datos. template1 se puede tocar, pero hay que tener en cuenta
que todo lo que metas en ella se copia a las BD nuevas y que conviene
pegarle vacuums despues de tocarla. Yo normalmente no las toco nunca,
lo que hago si quiero BD con contenidos pregargados es hacer un
"create database my_master" y luego hacer las mias con "template
my_master".

A lo que voy es que esas BD normalmente no se tocan nunca,
especialmente template0 ( no hay razon ninguna para tocarla, su uso
principal es poder reconstruir template1 si te la cargas ) y que no
deberian tener problemas con los vacuums ( si no recuerdo mal el
servidor las deja "frozen total" al hacer initdb ).

Francisco Olarte.

>
> 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.
>
> 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> 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> 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.90 0.00 6.39 1.54 0.00 75.17
>>
>>
>> Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
>>
>> dm-5 0.00 0.00 5.94 41.94 0.22 0.16 16.47 0.01 0.17 11.46 3.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.48 0.00 12.28 2.41 0.00 56.83
>>
>> 07:50:01 AM all 27.73 0.00 11.98 2.21 0.00 58.07
>>
>> 08:00:01 AM all 28.74 0.00 12.38 2.06 0.00 56.82
>>
>> 08:10:01 AM all 32.54 0.00 14.27 2.26 0.00 50.93
>>
>> 08:20:01 AM all 31.96 0.00 13.95 2.25 0.00 51.84
>>
>> 08:30:01 AM all 33.87 0.00 14.66 2.41 0.00 49.06
>>
>> 08:40:01 AM all 33.18 0.00 14.45 2.57 0.00 49.80
>>
>> 08:50:01 AM all 33.35 0.00 14.68 2.58 0.00 49.38
>>
>> 09:00:01 AM all 33.90 0.00 14.96 2.43 0.00 48.71
>>
>> 09:10:01 AM all 38.93 0.00 17.02 2.72 0.00 41.33
>>
>> 09:20:01 AM all 38.84 0.00 16.94 2.37 0.00 41.85
>>
>> Average: all 16.45 0.00 7.21 1.18 0.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 ).
>>
>>
>>