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.hernan...@etecsa.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.hernan...@etecsa.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

Reply via email to