Re: El rendimiento de postgres puede ser afectado por checkpoint_segments?

Carlos.

On Mon, Apr 1, 2019 at 10:05 PM Carlos T. Groero Carmona
<ctonetg(at)gmail(dot)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.