El día 29 de abril de 2009 21:50, Alvaro Herrera
<[email protected]> escribió:
> Angelo Astorga escribió:
>> Hola lista, tenemos un conjunto de aplicaciones bajo linux en un sistema con
>> php, apache, ejecutables via odbc, samba e integrados con bd postgresql
>> 8.3... el problema que hemos notado hace ya un tiempo, es que hay muchos
>> procesos postgresql (consultas, insert, delete y update) que por esas cosas
>> de la vida, quedan permanentes en linux (# ps aux) y pueden permanecer todo
>> el dia, utilizando cpu del servidor que podria llegar a colapsarlo, es
>> decir, servidor con cpu usada 100%... esta pasando frecuentemente a medida
>> que crece la bd y hemos notado que se da en la mezcla de postgresql, odbc de
>> programas ejecutables y samba... alguna experiencia equivalente que puedan
>> aportar para terminar con el problema... Se agradece....
>
> Seguramente algún usuario apreta el botón para mostrar un reporte, el
> cual se demora mucho, así que apreta el botón de nuevo (F5 "refrescar" o
> como sea en tu aplicación), se vuelve a demorar mucho, y así hasta que
> tiene el servidor lleno de procesos ejecutando lo mismo que saturan el
> servidor y lo hace más lento.
>
> Posibles soluciones:
> 1. educar a los usuarios (los garrotes con clavo funcionan bien)
Ya lo probé y he llegado a la conclusión que hay usuarios sadomasoquistas.
> 2. buscar las consultas lentas y optimizarlas
Angelo: loguea las consultas lentas para empezar a ver de que manera
se puede optimizar. Cuando tengas la/s consultas postealas así vemos
de que manera se puede mejorar los tiempos.
> 3. si los garrotes no son convincentes, implementar un sistema que
> impida que los usuarios ejecuten muchas veces las mismas consultas
>
En este punto podrías hacer que el proceso que actualiza la consulta
tenga una consulta previa para verificar que no se este corriendo esta
consulta.
Otra cosa uqe podrías facilitar es: un iostat, un free, vmstat y todo
otro dato para
ver el comportamiento del SO. También un resumen de stat_activity y
resultados de querys en las tablas problemáticas.
Después de eso se puede empezar a analizar :)
--
Emanuel Calvo Franco
Sumate al ARPUG !
( www.arpug.com.ar)
ArPUG / AOSUG Member
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
http://archives.postgresql.org/pgsql-es-ayuda
