El 11 de septiembre de 2012 17:17, Miguel Beltran R. <[email protected]>escribió:
> > El 11 de septiembre de 2012 04:37, Cesar Martin <[email protected]>escribió: > >> Buenas Miguel Angel, >> >> A la BBDD le hago un vaccum verbose analyze todos los dias y todos los >> mensajes son del tipo: >> >> *INFO: <AB>dossier<BB>: se procesaron 924 de 924 p<E1>ginas, que >> conten<ED>an 74652 filas vigentes y 0 filas no vigentes; 3000 filas en la >> muestra, 74652 total de filas estimadas* >> >> Entiendo que al haber 0 filas no vigentes, no es necesario correr el full >> vacuum, es correcto? >> >> Cuando se bloqueaba, analizamos las consultas del pg_stat_activity, pero >> eran todas normales. >> A mi lo que me sigue sin cuadrar, es que cuando postgres ocupa la CPU, el >> tipo de carga es user, no system... >> >> Otra cosa que tambien he comprobado, es que sin estar en el momento >> critico con todas las cpu al 100%, la BBDD da timeouts a la hora de >> conectarse a ella, cuando deberia tener conexiones de sobra, ya que tengo >> un munin2 puesto y en ningun caso las conexiones suben de 200. >> >> Un saludo >> >> > Podría ser que alguna computadora se encienda a cierta hora y te haga > conflicto de IP? que el switch este fallando? puede ser problema por otro > lado. si el problema es de conexión, prueba hacer una consulta localmente > en el servidor. El conflicto de IP no es posible, ya que el servidor esta en un CPD, con red propia y son todo servidores permanentemente encedidos. Lo del switch lo valore en un primer momento, pero lo descate, porque a nivel local iba igualmente lento y un ifconfig no mostraba nada en el contador de errores. El problema añadido es la aleatoriedad del problema, ya que cuando pasaba, solo ocurria dos o tres de veces al día, siempre coincidiendo por la mañana, pero nunca a una misma hora. Un saludio. > > > -- > ________________________________________ > Lo bueno de vivir un dia mas > es saber que nos queda un dia menos de vida > -- César Martín Pérez [email protected]
