From: | Emanuel Calvo Franco <postgres(dot)arg(at)gmail(dot)com> |
---|---|
To: | Federico Sansone <fsansone(at)gmail(dot)com> |
Cc: | arpug(at)postgresql(dot)org |
Subject: | Re: [arpug] Consulta sobre degradación de performance |
Date: | 2010-10-07 15:36:37 |
Message-ID: | AANLkTimoszp0y_esBiU81JS2=szgN2+vWpNpso=0cEpb@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | arpug |
El día 6 de octubre de 2010 22:50, Federico Sansone
<fsansone(at)gmail(dot)com> escribió:
> Saludos a todos! espero me puedan dar una mano con lo siguiente:
>
Fede!
> En los últimos días note que nuestra base de producción esta perdiendo
> performance. Hay consultas que historicamente no generaron
> inconvenientes y comenzaron a quedar como colgadas, ocupando capacidad
> y encolando otras transacciones generando a nivel usuario lentitud en
> la aplicación y superando el nro. máximo de conexiones.
>
> La versión es 8.1.20 (corriendo en un IBM Xseries 225 de doble xeon
> 3ghz con 6gb de ram con fedora).
>
El fierro (dependiendo de la cantidad de datos) en parte de procesamiento
y memoria está relativamente bien. El tema es: como andamos de disco?
Porque 'calculo' que tenemos un RAID, no?
> En Julio hicimos un dump/restore. En los log de messages tengo una
> recomendacion de hacer un e2fsck.
>
Y vacuums? cada cuanto? como esta configurado el autovacuum?
> Quisiera antes de ejecutar algún comando en producción, validar con
> ustedes para que lado creen conveniente apuntar, si a realizar otro
> dump restore y reindexar la base, o tomar alguna acción sobre el
> sistema operativo.
>
Recuerden que la version 8.1 está en linea de quedar EOL, así que
yo lo que haria seria ir descartando los 8.1 y poner >8.3.
> Estamos analizando una inversión para recambio tecnológico pero entro
> en juego algún tema de hosting/housing en un datacenter lo que atraso
> el cambio de hard y nos apareció este problema...
>
Es una cuestión de ver si las consultas son optimas tambien. Sacá las
consultas más lentas y haceles EXPLAIN para ver los costes. Si no te
convence, un EXPLAIN ANALYZE y podes ver como viene.
Creo que monitorear el servidor durante un tiempo es lo recomendable.
> Se agradecen las recomendaciones. La verdad que no se que información
> puede ser útil postear para orientar la ayuda...
>
Configuracion,
explain,
detalles integros del hard,
tamaño de datos y discos....
Saludos!
--
Emanuel Calvo Franco
Independient DBA
www.emanuelcalvofranco.com.ar
From | Date | Subject | |
---|---|---|---|
Next Message | Mariano Reingart | 2010-10-11 15:15:48 | == PostgreSQL: Noticias semanales - 10 de Octubre de 2010 == |
Previous Message | Federico Sansone | 2010-10-06 20:50:39 | Consulta sobre degradación de performance |