Carlos. On Mon, Apr 1, 2019 at 10:05 PM Carlos T. Groero Carmona <cton...@gmail.com> wrote: > Mi servidor tiene 512GB de RAM, mi shmmax es 276 GB, mi shared_buffer is 128 > GB. > Utilizando este comando puse ver: > # free -g > total used free shared buffers > cached > Mem: 504 499 5 129 0 > 466 > -/+ buffers/cache: 31 472 > La herramienta que utilizo es NewRelic y como usted dice solo esta mostrando > cuanto se ha utilizado y queda disponible por processos.
Viendo la cabecera de NewRelic, que parece una herramienta gorda, a saber a que llaman con cada nombre. Lo que te da ahi es un servidor sano trabajando con una disco gordo con una version un poco antigua del free. El cache esta en uso, y en buen uso. La linea de abajo, como muy bien has leido en ... ... > https://www.linuxatemyram.com Te dice cuanta memoria puedes tener disponible. Si ejecuto, p.e., el mismo comando en mi maquina da: :~$ free -g total used free shared buff/cache available Mem: 1 0 0 0 0 0 Swap: 1 0 1 ;-> Parece que no es un servidor, ahora en plan modesto: $ free -m total used free shared buff/cache available Mem: 2019 1015 453 70 550 678 Swap: 1905 33 1872 ¿ Que nos dice eso ?, que llevo un rato trabajando ligerito, y de los 2019Mb que tiene el kernel disponible esta usando 1015 en programas y 550 en cache, y me sobran aun 453. Si hubiera estado trabajando mucho tiempo, un valor tan alto de free es MALO, quiere decir que he metido demasiada memoria. Esta maquin, p.e., tiene 2G de RAM y 40G de disco. Si le pongo 512G, dudo que llegue a usar mas de 128G por mucho que lo intente, y tendria 400+G libre que es malo, solo estan gastando luz, pero 40G de cache, que es muy bueno, tendria todo el disco cacheado, mucho mas rapido que un SSD. Un valor alto de memoria libre, sin usar, solo es correcto cuando aun no has "calentado" la maquina o, si tu maquina hace como alguna de las mias, que lanza procesos que necesitan mucha RAM pero acaban, justo cuando acaba uno de esos ( tengo p.e. un indexador uno de cuyos parametros es "cuantos gigas quieres usar", mas gigas, mas rapido, y los usa todos, pero cuando termina los deja libres de golpe, hasta que otro proceso los coja. Pero si no los coge nadie el sistema los usa para cache, no los deja pudriendose en free. > Ahora 472 es ~94% de la RAM, y NewRelic solo me muestra el otro ~6% de > utilizacion. > Este es un servidor fisico dedicado solo a postgres, por supuesto hay algunos > otros procesos corriendo all'i pero nada de gran medida. > alguna idea de como poder decir, cuanto postgres esta usando realmente? prueba con top y ps tras leerte un rato los manuales. > En su comentario anterior dice: "...la mayor > parte de la RAM debería ir a shared_buffers y al cache de filesystem por > parte del kernel...." Eso lo decia otro, y es mas o menos correcto. Asi estan USADOS para que el pg vaya rapido. Si estan en free no se estan usando. En segunda derivada, segun tu workload, debes tener en cuenta el work_mem y otras cosas, pero en general eso es correcto. La memoria libre total , el free en regimen permanente, no vale para nada, no se usa nunca, lo unico que hace es gastar luz ( y pasta cuando la compras ). La available es otra cosa, pero en uso ideal de tu ordenador el free minimo seria 0. > Cree que deba incrementar el shared_buffer por encima del 25% de la RAM? Actualmente, con las salvajadas que se ponen de RAM, no se recomienda tirar demasiado de shared buffers porque ocupan doble. Cuando Pg trabaja con una pagina lo hace en shared-buffers, por lo que interesa tener suficientes para que los procesos no se queden sin ellas. Por otro lado cuando una pagina esta en shared buffers es porque se ha leido de disco ( y esta en el cache ) o se va a escribir ( y estara en el cache ), por lo que funciona como una especie de "cache del cache de disco" ( ma o meno, no es exacto ), y compiten por la memoria. Por eso si tu pones, p.e., 450G de shared tendras problemas porque el SO no tiene cache para manejar agilmente la carga de I/O del postgres ( depende de tu carga de trabajo exacta, pero te haces una idea ). Ten en cuenta que ademas el problema mas gordo es tener demasiadas paginas "sucias" en shared-buffers, pero estas no suelen ser demasiadas. Las limpias se traen del cache del disco del SO muy rapido en estos dias. Francisco Olarte.
