Re: Urgente, postgres down

Horacio, crea una tabla en una de esas base de datos, insertale algunos
numeros sin utilizar transaction (begin-commit) y veras que los numeros
aumentan parejo.
Realizale algunos update ondelete a esa tabla.
y despues ejecutale el vacuum a esa tabla y veras que solo va a disminuir
los numeros en esa base de datos dejando el resto alto.

Saludos,

On Thu, Feb 14, 2019, 4:31 PM Horacio Miranda <hmiranda(at)gmail(dot)com wrote:

> Ehh acabo de hacer una prueba pequeña en mi ambiente de prueba, borre una
> table y se creo la tabla y todos los numeritos cambiaron en todas las bases
> de datos... ( solo hice el cambio en una de ella, como mensione antes esto
> se ve interesante para investigar ( por que este problema no lo eh tenido
> antes ).
>
> datname | max | percentage_transaction_ids_used
> -----------+---------+---------------------------------
> template0 | 4486633 | 0.214
> template1 | 4486633 | 0.214
> postgres | 4486633 | 0.214
> horacio | 4486633 | 0.214
> hmiranda | 4486633 | 0.214
> adempiere | 1545016 | 0.074
>
> Despues de recrear la tabla, tengo esto.
> datname | max | percentage_transaction_ids_used
> -----------+---------+---------------------------------
> template0 | 4486635 | 0.214
> template1 | 4486635 | 0.214
> postgres | 4486635 | 0.214
> horacio | 4486635 | 0.214
> hmiranda | 4486635 | 0.214
> adempiere | 1545018 | 0.074
>
> Y despues de hacer un vacuumdb -a me da los mismo numeros.
>
> datname | max | percentage_transaction_ids_used
> -----------+---------+---------------------------------
> template0 | 4486635 | 0.214
> template1 | 4486635 | 0.214
> postgres | 4486635 | 0.214
> horacio | 4486635 | 0.214
> hmiranda | 4486635 | 0.214
> adempiere | 1545018 | 0.074
>
> Voy a leer un rato sobre como bajar esto. pero no creo que tu problema
> vaya por el vaccumdb.
>
> On Fri, 15 Feb 2019 at 09:59, Carlos T. Groero Carmona <ctonetg(at)gmail(dot)com>
> wrote:
>
>>
>>
>> On Thu, Feb 14, 2019 at 3:09 AM Horacio Miranda <hmiranda(at)gmail(dot)com>
>> wrote:
>>
>>>
>>> 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 ?
>>>
>> Actualmente me encuentro trabajando con New Relic para obtener el pluging
>> y activarlo, esta es la web donde hablan del procedimiento:
>>
>> https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/postgresql-monitoring-integration
>>
>> Ah, muchas gracia spor la aclaracion sobre los billion (ingles) y el
>> billon (espanol), me estaba volviendo loco con lo que estudie cuando nino y
>> los numeros que encontraba en la documentacion escrita en ingles...jaja
>>
>>> 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>
>>> 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 ).
>>>>
>>>>
>>>>
>>>>
>>>>
>
> --
> Saludos,
> Horacio Miranda Aguilera.
>