Rendimiento servidor nuevo

Buenas Gente.

Tengo instalado un servidor (Intel® Core™ i3-2120 Processor (3M Cache, 3.30 GHz) 16 GB RAM) con Pilaga 2.3. Como últimamente estaba consumiendo bastantes recursos optamos por actualizar el servidor. Y ahora estamos haciendo pruebas antes de ponerlo en producción.
El servidor nuevo es un IBM System x3500 M4 con dos procesadores Intel® Xeon® Processor E5-2609 (10M Cache, 2.40 GHz, 6.40 GT/s Intel® QPI). En este caso instalamos el servidor de vmware para tener posibilidad de varias virtualizaciones adentro, con 32 GB de RAM.

Cuestión que suponía una gran mejora en el rendimiento del pilaga. Sin embargo en consultas como la de “Resumen cuenta bancaria” que es una consulta que suele demorar. Está tardando lo mismo en ambos servidores. 30 segundos. Hago la consulta del mes de agosto por ejemplo.

Donde noto el cuello de botella es en los procesadores que con esta consulta los nucleos suelen llegar al 95% o 100%

Tengo forma de mejorar el rendimiento?

Probé con aumentar shared buffers pero sigue igual.

Se les ocurre algo?

Saludos!

Leandro E. Rodriguez
Untref

Hasta donde tengo entendido postgres, por default, maneja un solo proceso por session a la base.(puede fallar) con el equipo nuevo tienen mas nucleos pero menos velocidad de reloj, en teoria hasta podria funcionar mas lento para una sola consulta, pero mas rápido para muchas aplicaciones al mismo tiempo.

Igual, la mayoria de los tuneos de postgres son contra el manejo de memoria
En la wiki de postgres hay un articulo copado.
https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server/es

¿Qué versión de postgres? Se que la 9.2 tiene un par de tuneos de multiproceso https://wiki.postgresql.org/images/e/e8/FOSDEM2012-Multi-CPU-performance-in-9.2.pdf
¿Cuánto le pusieron al shared?
¿Le cambiaron algo mas al postgresql.conf?

Saludos!

Muchas gracias por la respuesta.

La versión de postgres en el servidor nuevo es 9.1. Asi que voy a probar esto que me decis con la versión 9.2 a ver si logro una diferencia.

En el shared buffer primero probé con 2048 y por descarte fui a 4096. Pero no sirvió.

A postgresql.conf también le modifiqué la parte del autovacuum para que quede habilitado. Me faltó algo más para mejorar el rendimiento en este tipo de consultas?

Saludos

Fijate de aumentarle el shared un poco mas, quizas tenes que tocar unas variables de sistema

Unos cuantos parametros mas se pueden tocar, por ejemplo
effective_cache_size
work_mem maintainance_work_mem
default_statistics_target
checkpoint_segments checkpoint_completion_target
random_page_cost
Usá el link que te mandé de machete
https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server/es

Buenas, sigo con este tema. Con los distintos seteos gané entre 5 y 15 segundos de diferencia. También instalé la versión 9.4 por el tema de multiprocesos pero no noté diferencias.

El seteo que más me sirvió fue work_mem maintainance_work_mem. Asi que ya saben en caso de consultas grandes.

Si saben algo más que pueda hacer, estaría agradecido.

Nuevamente muchas gracias!

Saludos!

Hola

Otro enfoque puede ser mirando el query que hay detras del repote (si es que hay un solo query que demore)

Cuando esta corriendo el reporte, para identificar el query que demora podes hacer:

1- una forma es haciendo un select * from pg_stat_activity ; durante el reporte

2- la otra forma se seteando un parametro del postgresql.conf que es el log_min_duration en 10 miliseg, y fijarte que queries se ejecutan durante el reporte. (acordate de apagar el log_min_duration)

Una vez identificado el query, podes probarlo desde pgadmin, o psql y ver cuanto tarda.

ahi le antepones un explain analyze y vemos que es lo que pasa con el query, y volvemos a revisarlo

saludos