Si, hemos estudiado en ese intervalo crítico el servidor con pgstat, vmstat, ps, etc. No tenemos Swap, la memoria está utilizada casi completa, el nivel de hits es alto a mi entender (promedio de 85%) y baja un poco en el momento crítico. Llegamos a tener casi 150 conexiones simultáneas en este horario. tenemos los valores analizados, y de ahi notamos la cantidad de locks, pero aparentemente no viene por ese lado de acuerdo a otras colaboraciones que me han brindado aqui. las tablas mensuales de 12 millones de registros no se editan, solo se inserta, y a la mañana cuando los clientes ingresan se produce una consulta sobre estas tablas del ultimo día solamente, y allí es donde se descompensa todo. Mi temor era por las 4 aplicaciones que trabajan asincronamene, pero durante el resto del día no se producen problemas, y el sistema se comporta muy bien. Las tablas de móviles si reciben updates continuamente, pero en las horas de la mañana tienen realizado un vacuum y si este fuera el problema, continuaría hasta alguna acción nuestra en el servidor .La consulta inicial del sistema es bastante compleja, pero no debería generar mayores inconvenientes, ya que es un select solamente. las vistas que utilizamos sobre las tablas con mayor carga de updates podrán ser un problema?
desde ya muchisimas gracias por tu ayuda e interés. Mario On Tue, 20 Jul 2010 13:54:38 -0400, Alvaro Herrera <alvhe...@commandprompt.com> wrote: > Excerpts from msileone's message of lun jul 19 17:44:16 -0400 2010: >> Alvaro, gracias por tu respuesta: >> Las actividades de los clientes están limitadas a lo que nosotros >> montamos >> en la página web, > > ¿en qué consisten? ¿Han estudiado su comportamiento? > - > 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 - 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
