Re: Urgente, postgres down

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.

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

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

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