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
