Re: Consulta

2011/5/7 Ezequiel Lovelle <elovelle(at)dialdata(dot)com(dot)ar>

> Me voy a fijar, aunque la prueba la hice en los dos postgres de los
> nodos, siendo practicamente idéntico en ambos.
>
Perdon, revisando me doy cuenta que interprete mal el vmstat. Tu sistema
esta idle exceptuando por un nivel de context-switches notable. Que mas
corre en ese equipo? Mejor ejecuta el script en el mismo server con la base
para descartar factores externos.

> Y si ese fuese el caso, ¿porque cuando hago la query en la consola de
> postgres me la ejecuta en cuestión de 1 segundo y escribió bien los datos en
> disco? yo creo que estoy teniendo mal algo en postgres.conf
>
Los dos tipos de inserts son muy distintos. En el script haces un insert por
transaccion mientras que en el otro haces todos los inserts en una unica
transaccion. Aparte del ahorro en cpu en parseo hay un gran ahorro en
escritura aleatoria sobre el disco, que es el que hace la diferencia.
Una seteo que te deberia acelerar el script es ejecutar un SET LOCAL
synchronous_commit TO OFF antes de hacer los inserts.

> te pego lo que tengo modificado aver si se te ocurre algo.
>
> listen_addresses = '*'
> wal_level = archive
> fsync = on
> archive_mode = on
> archive_command = 'exit 0'
>
Donde estas escribiendo los archives? Deshabilita el archive_mode a ver como
afecta tu prueba.

>
> maintenance_work_mem = 480MB
> checkpoint_completion_target = 0.7
>
Algun motivo por el cual modificaste el checkpoint_completion_target? Lo
dejaria en 0.5 y en todo caso lo iria bajando en caso de tener un sistema
OLAP con inserts intensivos.

> effective_cache_size = 5632MB
> work_mem = 40MB
> wal_buffers = 4MB
>
Para scripts como el que estas ejecutando quiza convenga duplicar
wal_buffers.

> checkpoint_segments = 8
>
Es bajo. Subilo a 30.

> shared_buffers = 1920MB
> max_connections = 400
>
Totalmente al margen: 400 conexiones es excesivo para cualquier sistema.
Mantene max_connections entre 20 y 50. Mas si estas usando un connection
pooler.

Slds.,
Fernando.