Re: Inserts lentos

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Guillermo Schulman <gschulman(dot)pg(at)gmail(dot)com>
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Inserts lentos
Date: 2009-02-06 23:06:15
Message-ID: 20090206230615.GD3089@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Hola,

Guillermo Schulman escribió:

> Desde hace un tiempo vengo mejorando la calidad de las consultas que
> nuestra aplicación web hace a la DB que administro. Logré bajar muy
> exitosamente la carga de nuestro servidor de base de datos a partir de esas
> mejoras (reescribiendo SQL, creando índices, etc).
> Ahora, a partir de los análisis que hago (ayudado principalmente por la
> herrmienta pgfouine), hemos llegado a un punto en que lo que más está
> cargando a la base son las acciones de escritura, particularmente los
> insert, y más particularmente los insert en una tabla que tiene continuos
> inserts y casi nula lectura (es una especie de log). Esta tabla no tiene
> foreign keys (ni desde ni hacia ella) ni triggers, es apenas una tabla de
> dos columnas por lo que intuyo que no hay más actividad que el propio insert
> y nada que se desencadene a partir de él. Es decir, no veo que pueda mejorar
> nada desde un "nivel sql": es un insert simple y llano.

¿Cuantos indices tiene la tabla? Mientras más índices, más lento.
Además, si las columnas que son llave en los índices son muy anchos,
también es más lento ocasionalmente por la necesidad de hacer "page
splits".

Lo otro es que recuerdo que había un bug que hacía que una transacción
no podía comprometer (commit) durante un checkpoint. No me acuerdo en
qué versión fue corregido esto, pero deberías actualizar a 8.1.16 para
asegurarte que no es ese tu problema.

Ahora, otra cosa a tener en cuenta es que durante un checkpoint la
actividad va a ser mucho más lenta debido a la utilización del I/O por
parte del checkpoint. Creo que tu checkpoint_segments es demasiado
bajo; considera incrementarlo a 10 por lo menos. Las desventajas de
aumentarlo son

1. WAL (pg_xlog) ocupará más espacio en disco
2. en caso de haber una caída, la recuperación demorará más.

> #EH: Allow at least 1 prepared statement by connection,
> #EH: because we intend to use them intensively
> max_prepared_transactions = 1000 # can be 0 or more

¿Realmente tienes 1000 max_connections? Estás loco. Considera disminuir
las conexiones que tienes abiertas. Un valor más cercano a 20 puede ser
razonable; usa un pooler (pgBouncer quizás). Esto se ha conversado
antes en la lista; busca en los archivos.

--
Alvaro Herrera http://www.advogato.org/person/alvherre
"Crear es tan difícil como ser libre" (Elsa Triolet)

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Alvaro Herrera 2009-02-06 23:22:11 Re: Carga frecuentede"$libdir/plugins/plugin_debugger.dll"
Previous Message Guido Barosio 2009-02-06 19:45:31 Re: pgagent