El 5 de abril de 2010 12:10, Diego Ayala <[email protected]> escribió:
> Mejor explicado imposible, muchas gracias Fernando, la verdad me ahora > entiendo mejor el funcionamiento..!! y realmente lo que siempre me parece > extraño es q casi nunca se supera las 100 conexiones concurrentes, el > problema podrian ser los select que se ejecutan varios sort...!!! ya que hay > ocaciones mirando con vmstat se pueden ver valores 1, 2 o hasta 3 en so, > pero que son casuales.. vere como encarlo ahora.. Gracias de nuevo..!!! > > El 5 de abril de 2010 13:17, Fernando Hevia <[email protected]>escribió: > > >> >> > -----Mensaje original----- >> > De: Fernando Hevia >> > >> > > -----Mensaje original----- >> > > De: Diego Ayala [mailto:[email protected]] >> > > >> > > Fernando y lista, perdon por introducir tambien mi cosulta >> > aqui, pero >> > > tengo un caso muy parecido al problema que tiene Ramon, la >> > diferencia >> > > es que tengo 10 GB de RAM, y utilizo PostgreSQL 8.4.1 64 >> > bits, Proc. >> > > Quad Core 64 bits INTEL, RAID >> > > 1+0, utilizando el comando TOP veo los siguientes datos. >> > > >> > > Mem: 10485760k total, 10309328k used, 176432k free, >> > > 188228k buffers >> > > Swap: 2129912k total, 38708k used, 2091204k free, >> > > 9029704k cached, >> > > >> > > existen momentos en los que swapea, como puede verse, mi >> > configuracion >> > > es shared_buffers=2GB , effective_cache_size=4GB y >> > work_mem=8MB, que >> > > podria estar mal configurado, por q trate de basarme en las >> > > recondaciones dadas..!!! el servidor es dedicado. >> > > >> > >> > Diego, que top te muestre 38MB de swap utilizados en un >> > equipo con 10GB de RAM debes tomarlo como que NO hay swap. >> > Es un valor insignificante y no debe preocuparte. >> > Si el equipo es dedicado a Postgres y con los seteos que >> > pusiste, la única situación que podría llegar a generarte >> > swap es que se conecten simultáneamente cientos de clientes y >> > ejecuten sorts sobre datasets grandes, o que Postgres tenga >> > algún memory leak grave. >> > >> > Por otra parte, no se qué actividad habrá tenido Postgres >> > antes de que tires ese top pero en este momento te está >> > indicando que puedes subir effective_cache_size a 8GB sin >> > miedo a errarle. >> > >> >> Perdón, releí el post y me parece requiere una explicación adicional como >> para que no quede en el misterio porqué están esos 38MB swapeados. >> >> 1º Que el kernel decida swapear algun proceso que está inactivo es >> perfectamente normal. Pues aunque haya suficiente memoria libre prefiere >> utilizar esa memoria como caché de disco en lugar de que esté ocupada por >> una aplicación que no hace nada. >> >> 2º La cantidad de SWAP utilizado no es realmente un indicador de que haya >> un >> problema. Supongamos levantaste un juego que ocupa 2GB de RAM y lo dejaste >> en segundo plano hace 2 días para trabajar un poco. Esos 2GB son un buen >> candidato para residir en swap al menos hasta que decidas retomar el >> juego. >> Un top te mostrará 2GB de swap utilizados y ello no debiera preocuparte en >> absoluto. >> >> 3º El verdadero indicador de si el equipo está swapeando es vmstat. Las >> columnas si y so (swap-in/swap-out) te indican la cantidad de kb que están >> siendo transferidos de la memoria al disco (swap). si = SWAP->RAM y so = >> RAM->SWAP. El que es grave es so ya que indica que la memoria es >> insuficiente y se debe escribir en disco. >> Cuando vmstat te indique que se está swapeando regularmente ahí es donde >> debes analizar que acciones seguir. >> >> Espero esto haya aclarado un poco más el panorama. >> >> Saludos, >> Fernando. >> >> > > > -- > Diego Ayala > A mi tambien me sirvio, ¡¡¡Excelente explicación!!!, desconocia todo eso. -- ________________________________________ Lo bueno de vivir un dia mas es saber que nos queda un dia menos de vida
