Re: [MASSMAIL]bajo rendimiento en vmware

Estimados (as) de la lista

Recibí una atención inicial sobre el tema de Francisco Olarte, miembro
de la lista y al que debo agradecer por su prontitud. Por un "pequeño"
error, no nos dimos cuenta de que estábamos intercambiando fuera de la
lista, pongo a disposición de la lista un resumen de lo que
intercambiamos por si a alguien le sirve como referencia:

/Gustavo: On Tue, Jul 23, 2019 at 3:04 PM Gustavo Hernández //<gustavo(dot)hernandez(at)etecsa(dot)cu>//wrote: /

> /tengo el siguiente problema: sistema operativo: ubuntu: 18.04 sobre
> vmware Postgresql: versión 10 La situación es que tengo un
> procedimiento almacenado que en una PC con ubuntu 18.04 funciona sin
> problemas específicamente el segmento siguiente: /

/... ... /

> /la tabla, para luego insertar los nuevos datos, como decía esto en
> una PC , para unos 70000 artículos demora unos 4 minutos, sin embargo
> en el servidor con las características dadas al principio,
> prácticamente se hace infinito /

/De caracteristicas del servidor, dices ubuntu sobre vmware, es decir,
en principio se puede suponer mismo postgres mismo ubuntu en los dos
casos, sobre hierro real y virtual, peeero, convendria quizas saber..
1.- Caracteristicas de hardware de las dos maquinas. 2.- ... y
configuracion de la maquina virtual 3.- ....asi como que mas cosas hace
el servidor del vmware 4.- Y que es "se hace infinito" ( i.e. "lo aborto
a las dos horas cansado de esperar") 5.- Y algo de la configuracion del
postgres en ambas maquinas. que no creo que sea asi, pero igual estas
comparando un pc de gaming contra una particion sobrecargada y has
abortado a los 10 minutos. ademas, de lo poco que veo, eso parece
ejecutar un solo articulo, no 70000, convendria tambien asegurarse de si
es asi y si lo es de como es la latencia entre las maquinas involucradas
en la prueba ( porque si haces 70000 transacciones, p.e., cada
milisegundo de latencia extra es un minuto diez de ejecucion ).
Francisco Olarte.////------- //Francisco /
Gracias por responder, dentro de las conjeturas que te hacías, te puedo
asegurar que por ejemplo el hard, es muy bueno, son servidores blade
donde están las máquinas virtuales montadas sobre vmware, lo que te
mostré es solo la parte donde se pone lento el proceso, pero eso es
parte de un procedimiento más grande, ese código está dentro de un ciclo
FOR, lo extraño es eso que en las pc configuradas como servidores
independientes, este proceso demora 4 o 5 minutos y aquí demora una hora
y media aproximadamente, hasta ahora los demás aspectos en la BD se
comportan adecuadamente, por ejemplo una búsqueda de 200 artículos en
esta BD que llega a alcanzar los 2 millones de artículos, se demora 1,2
a 1,3 segundos. De todos modos sigo buscando cualquier detalle en el
postgresql.conf.

gracias de todas formas y si se te ocurre algo, por favor me dices

sdos

------------

Gustavo, un par de cosas.

Primero, cometi un error mandandote la respuesta SIN COPIA a la lista,
error mio, debi usar reply-all, e imagino que eso ha provocado tu
respuesta solo a mi.

No voy a mandar esto a la lista porque lo que voy a decir no creo
tenga interes general, no parece adecuado, de todos modos si algo te
parece adecuado consultar algo en general, recuerda añadir la lista en
copia.

On Tue, Jul 23, 2019 at 7:28 PM Gustavo Hernández
<gustavo(dot)hernandez(at)etecsa(dot)cu> wrote:

> Gracias por responder, dentro de las conjeturas que te hacías, te puedo
> asegurar que por ejemplo el hard, es muy bueno, son servidores blade
> donde están las máquinas virtuales montadas sobre vmware,
No lo dudo, pero la cosa es la comparativa en los standalone <-> vmware.
La cosa es que igual tienes un mas que adecuado servidor que ejecuta un
procedimiento en 30 minutos, pero lo pruebas en una mega-pepino-gaming
con ssd-raid10 o similar que es mucho mas rapido.
> lo que te
> mostré es solo la parte donde se pone lento el proceso, pero eso es
> parte de un procedimiento más grande, ese código está dentro de un ciclo
> FOR, lo extraño es eso que en las pc configuradas como servidores
> independientes, este proceso demora 4 o 5 minutos y aquí demora una hora
> y media aproximadamente,
El FOR quiere decir que los 4 o 5 minutos son 1 query que llama a un
procedimiento gordo que tiene un FOR que hace 70000 vueltas? ( eso
implica 1 query, una transaccion, 1 roundtrip que descartaria los
problemas de red ). Eso esta muy bien, ya tenemos una escala, 90/ 4 o 5,
pongamos 20 veces mas lento. Eso da un idea de las cosas que se pueden
buscar, e indica que la BD no esta funcionando mal en vmware sino que
puede ser algun parametro de ajuste.
> hasta ahora los demás aspectos en la BD se
> comportan adecuadamente, por ejemplo una búsqueda de 200 artículos en
> esta BD que llega a alcanzar los 2 millones de artículos, se demora 1,2
> a 1,3 segundos. De todos modos sigo buscando cualquier detalle en el
> postgresql.conf.
> gracias de todas formas y si se te ocurre algo, por favor me dices
Yo miraria los temas de cache y buffers, asegurarte de que estan bien
puestos en las dos maquinas y son similares ( una diferencia de 20 puede
deberse sin problema a un working set que cachea en las maquinas sueltas
pero no en las virtuales ), asi como el fsync. Yo no uso vmware, pero si
que se que hay gente que tiene problemas en virtualizacion y servers
porque por lo que sea va por un path lento. Lo que te comentaba, aunque
yo no sea capaz de ayudarte mucho en vmware, es que la gente de la lista
sabe solo lo que has contado, sin tener algunos datos de ram/tamaño de
tablas/tipo de discos/resultados es muy dificil de diagnosticar. En la
primera version ni siquiera sabemos lo que quieres decir por "casi
infinito", aqui se ve que parece algo como "20 veces mas lento", y no
seria la primera vez que alguien dice "va lentisimo", cuando quiere
decir "en una tarda 4 o 5 minutos, en otra lo pare a los 7 porque iba mu
lento".

Saludos. Francisco Olarte.

bueno seguimos aquí, luego hago algo para la lista, jaja, nos fuimos
completo

Yo hice algunos cambios en el postgresql.conf, como parámetros de
buffers, memoria, etc y eso mejoró mucho el rendimiento , la diferencia
es solo 18 minutos, pero es verdad, a veces no vale la comparación, en
definitiva, estos tiempos para lo que hago, son buenos, pues la base de
datos se actualiza diariamente en horas de la madrugada para evitar el
alto tráfico de consulta durante el día, son varios tipos de
actualizaciones ejecutadas por un mismo procedimiento, lo que varía es
la procedencia y tipo de datos, ya hoy me gustan los números que obtuve
en la actualización durante esta madrugada, en definitiva lo que si no
podía alterarse eran los tiempos en la consulta y esos inlcuso mejoraron
un poco con el cambio de servidor, solo que seguiré probando pues no
teníamos referencia de postgres en producción sobre vmware. Cualquier
cosa que amerite te lo hago saber.

nuevamente muchas gracias por tú atención

saludos

NOTA:

Realizamos también correciones en el procedimiento almacenado, sobre
requerimientos que ya no son y que mejoran el rendimiento al minimizar
las consultas

saludos a todos