Re: Cuantos locks son muchos locks?

On Mon, 19 Jul 2010 18:44:16 -0300
<msileone(at)easymail(dot)net(dot)ar> wrote:

> Alvaro, gracias por tu respuesta:
> Las actividades de los clientes están limitadas a lo que nosotros
> montamos en la página web, por otro lado, los inserts por minuto que
> menciono están dados por equipos que transmiten desde vehículos,
> por lo que la parte cliente en caso que estén arruinándolo, la
> culpa seguiría siendo nuestra. Hemos optimizado hasta donde pudimos
> el postgres para dar lugar a las consultas que se realizan, pero
> apartentemente puede que estemos errados en alguna consulta al inicio
> de sesión que nos produce el problema planteado en la hora pico de
> la mañana.
>
> Saludos y gracias
>
> Mario .
>

Puede que actualizar los indices al hacer los updates te este dando
problemas. ¿Como los creaste? Algunas ideas que se me ocurren son:

a) Probar a bajar el FILLFACTOR a la mitad, 45 o incluso 30, de todos
los indices btree.
b) ¿Que indices estas usando realmente y necesitas alguno mas?

Con pgadmin yo hago lo siguiente (para tablas con gran numero de filas):

b1) Voy a la tabla y pido sus estadisticas en la pestaña de la derecha.
b2) Si el numero de barridos secuenciales es muy alto es que me falta
algun indice.
b3) Voy, dentro de la tabla, a la seccion de los indices y saco las
estadisticas de cada uno.
b4) Si el valor de busqueda por indices es muy bajo o cero, el indice no
me sirve de nada o casi nada y lo elimino.
b5) Si el valor es muy alto, el indice esta bien.

Cuando me falta algun indice creo uno por columna y despues de unos
dias miro cual se usa y cual no. Elimino los que no.

c) Igual el tipo de indice que usas no es el correcto. Puede
que necesites uno de tipo hash para algunos indices (aunque no es tan
versatil como un btree)

d) Usas la version 8.2.x Sube a la version 8.3 como minimo para poder
hacer CLUSTER sobre un indice, por ejemplo el de fecha a las tablas.
e) ¿Las tablas de meses anteriores modifican sus datos? ¿Necesitas
realmente hacer un VACUUM a dichas tablas cada noche?
f) Has comentado que haces un TRUNCATE TABLE, acuerdate de hacer un
REINDEX de la tabla despues.

Sobre tu pregunta de TRUNCATE, en el manual de 8.4 (supongo que
aplicable a la 8.2) vienen 2 warnings, el primero de los cuales creo que
es aplicable a tu caso:

TRUNCATE is not MVCC-safe (see Chapter 13 for general information about
MVCC). After truncation, the table will appear empty to all concurrent
transactions, even if they are using a snapshot taken before the
truncation occurred. This will only be an issue for a transaction that
did not access the truncated table before the truncation happened — any
transaction that has done so would hold at least an ACCESS SHARE lock,
which would block TRUNCATE until that transaction completes. So
truncation will not cause any apparent inconsistency in the table
contents for successive queries on the same table, but it could cause
visible inconsistency between the contents of the truncated table and
other tables in the database.

Corregidme si me equivoco, viene a ser que si alguna otra transaccion
de escritura empieza durante el truncate, esta bloquea el truncate
hasta que termina.

P.S. Antes de que nadie diga nada y me tire un monton de bits
sucios a la cabeza, lo que hago para saber que indices uso y cuales no
de esta manera es por que la aplicacion que desarrollamos usa hibernate
por medio, el cual es un oscuro pozo que no se sabe como funciona... y
no crea ningun indice.

HTH