> On 15/07/2022, at 2:17 AM, Carlos T. Groero Carmona <cton...@gmail.com> wrote:
>
> Gracias a todos por sus comentarios.
>
> Horacio,
>
> Estoy usando Azure como proveedor, las MV estan en la misma subnet, mismo
> availability set y availability zone en la misma region.
Uff revisa los MTU eh tenido problemas con Azure, ellos trabajan con 1360 MTU
size en maquinas windows. ignoro como manejan ahora.
sin acceso a las maquinas es difícil saber por que anda mas lento o mas rápido
:(
Si quieres manda un email directo y hacemos un LAB esto problema se ve
interesante.
>
> Los discos que estoy usando son Premium SSD.
>
> Basicamente no hay mucho que pueda hacer sobre la administracion de las
> maquinas virtuales que hacerle rebuild y moverla hacia otro availability set.
>
> La herramienta que usa el eqipo de performance es una paga y la carga es de
> 2mil usuario, empezando por 50 y subiendo lentamente hasta 2mil usuarios, una
> vez que son dos mil usuarios se mantiene por una hora con 2mil usuarios si no
> mal recuerdo y despues termina.
>
> La cantidad de querys que se operan es es bastante grande, hay insert deletes
> updates y por supuesto selects, con trigger functiones en fin, es el systema
> funcionando con 2mil usuarios concurrentemente por una hora con 4 o 5 de las
> funcionidades mas importantes.
>
> Y se usa el mismo template para hacer las pruebas, la unica diferencia es que
> yo apunto a pgbouncer a las base de datos en 9.6 o 13 dependiendo de que
> vayamos a testear.
>
> Uso NewRelic como herramienta de monitoreo, y pgBadger para revisar los logs,
> pero desgraciadamente no nos percatamos que el Integration plugin de NewRelic
> para postgres no estaba reportando y entonces estamos resolviendo eso para
> volver a ejecutar los test y poder indagar con detalles que esta pasando a
> nivel de base de datos.
>
> Logre poner los tiempos de respuesta de 9.6 y 13 juntos en NewRelic y
> encontre que todo funciono un poco mas lento pero el mas critico fue postgres
> con un 27%, aproximadamente 90ms mas lento.
>
> Con 9.6 trazamos la baseline a 14.8k rpm average connpeaks de 16k rpm y con
> pg13 el avg fue 13.4k rpm con peaks de 14k rpm.
>
> Sobre la configuracion la revise detalladamente con diferentes dba, incluso
> use la herramienta de 2ndCuadrant para ceear un reporte y el Insight de EDB
> para revisarlo todo y solo me propuso incrementar el wrok_mem a 256MB y
> algunos detalles de cache/HughePage/HeadDisk si no mal recuerdo, pero eso
> mismo me lo recomento con el 9.6 es decir no son variables que alterarian el
> test creo.
>
> Mi esperanza para encontrar que pasa esta en NewRelic y pg_stat_statement.
>
> Una vez que tenga mss detalles comparto aca que encontre.
Los datos que tienes son datos de pruebas o son datos reales ? si son datos de
pruebas, trata de guardar los logs en alguna parte, me pregunto del thread
ignoro si podemos hacer una especie de workshop para revisar esto en linea en
un meeting, seria interesante. yo tengo tiempo los viernes de Chile ( Sabados
de New Zealand ).
La applicación que cosa es ? Java ?
