Re: 8.0.4 Super Lento

El 16/11/05, Alvaro Herrera<alvherre(at)commandprompt(dot)com> escribió:
> Miguel escribió:
>
> > SHARED BUFFERS: Asumiendo 30% del total de 3G
> > El 30% de 3 GB: (3145728 KB/30) = 104858 KB
> > shared_buffers: (104858 KB/8 KB) = 13107
> >
> > SHMMAX: Asumiendo que quiero 300 conexiones maximo
> > shmmax = 250 kB + 8.2 kB * 13107 + 14.2 kB * 300
> > shmmax = 111989
> >
> > Pasando a bytes:
> > 111989*1024 = 114676777 (ceiling)
>
> Bueno, la ecuacion esta algo desviada, los requerimientos de memoria han
> aumentado ultimamente. Mirando el error:
>
> > DETAIL: Failed system call was shmget(key=5432001, size=120381440, 03600).
>
> deberia haber sido evidente que bastaba con poner shmmax en 120381440.
>
>
> > shiva1 napv2 # sysctl kernel.shmmax
> > kernel.shmmax = 114676777
> > shiva1 napv2 # sysctl kernel.shmall
> > kernel.shmall = 114676777
>
> Hum, el articulo dice que hay que poner shmall en lo mismo que shmmax?
> Eso es incorrecto -- en general, shmall se mide en paginas, no en bytes.

La información la saqué de la propia documentación de postgres:
http://developer.postgresql.org/docs/postgres/kernel-resources.html

"SHMALL Total amount of shared memory available (bytes or pages)
if bytes, same as SHMMAX;
if pages, ceil(SHMMAX/PAGE_SIZE)"

De acuerdo con la misma, se puede representar tanto en nº de bytes
como en nº de páginas. Si se representa en bytes (opción del
artículo), el valor es el mismo que SHMMAX.

Escribí este articulo con el ánimo de entender (yo mismo) y compartir
con la comunidad hispanoparlante una parte oscura, aunque no por ello
menos importante de postgres, como es la afinación hardware.
Agradeceré mucho cualquier aportación que ayude a ambos fines.

>
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 7: no olvides aumentar la configuración del "free space map"
>

--
Juanky Moral - www.juancarlosmoral.es