Skip site navigation (1) Skip section navigation (2)

Re: [arpug] Consulta sobre degradación de performan?==?UTF-8?Q?ce

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 performan?==?UTF-8?Q?ce
Date: 2010-10-07 15:36:37
Message-ID: AANLkTimoszp0y_esBiU81JS2=szgN2+vWpNpso=0cEpb@mail.gmail.com (view raw or flat)
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

In response to

arpug by date

Next:From: Mariano ReingartDate: 2010-10-11 15:15:48
Subject: == PostgreSQL: Noticias semanales - 10 de Octubre de 2010 ==
Previous:From: Federico SansoneDate: 2010-10-06 20:50:39
Subject: Consulta sobre degradación de performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group