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 <hmira...@gmail.com
<mailto:hmira...@gmail.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 ).
