On Mon, 19 Jul 2010 18:44:16 -0300 <msile...@easymail.net.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 - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
