SHMALL y PAGE_SIZE

Hola, he estado revisando tanto el articulo sobre afinación del
postgres (mencionado hace un par de días en un largo thread) y la
nueva documentación de postgres sobre la gestión de recursos del
kernel ( http://developer.postgresql.org/docs/postgres/kernel-resources.html
).

Veo claramente que:
- la documentación ha cambiado: ya no aparece la fórmula que
publicaron en su día para calcular un tamaño razonable para SHMMAX, en
función del número de conexiones y del nº de shared_buffers.
- que el tamaño de SHMALL se mide en páginas, como ya adelantó Alvaro
(al menos, en Linux).
- que el tamaño de SHMALL puede obtenerse con la expresión:
ceil(SHMMAX/PAGE_SIZE)

También tengo algunas dudas:
- ¿Cómo puedo saber exactamente el tamaño de página (PAGE_SIZE) en mi
kernel?. Uso kernel de linux 2.6. Creo que en 2.4 el tamaño era de
4KB, ¿aquí es el mismo tamaño?
- ¿puedo deducirlo planteando esta ecuación?:
DEFAULT_SHMALL=ceil(DEFAULT_SHMMAX/PAGE_SIZE).
(Los valores default se pueden conocer fácilmente a través del
programa sysctl -a)

Con estas aclaraciones, me gustaría modificar el artículo corrigiendo
los errores y de modo que resultara más claro y útil para cualquiera.
Gracias.
--
Juanky Moral - www.juancarlosmoral.es

Juanky Moral escribió:

> - la documentación ha cambiado: ya no aparece la fórmula que
> publicaron en su día para calcular un tamaño razonable para SHMMAX, en
> función del número de conexiones y del nº de shared_buffers.

Bueno, todavia la formula sigue dependiendo exclusivamente de
max_connections y shared_buffers, pero las constantes han crecido.
Es facil hacer una investigacion modificando esos valores para obtener
varios puntos de la recta y calcular las constantes. Observa que
Postgres te indica cual es el tamaño del segmento que esta pidiendo, si
no logra crearlo (hint: bajar SHMMAX hasta un numero ridiculamente
pequeño)

Hmm, ahora que lo pienso probablemente tambien depende de
max_locks_per_transaction.

> También tengo algunas dudas:
> - ¿Cómo puedo saber exactamente el tamaño de página (PAGE_SIZE) en mi
> kernel?. Uso kernel de linux 2.6. Creo que en 2.4 el tamaño era de
> 4KB, ¿aquí es el mismo tamaño?

Ni idea.

> - ¿puedo deducirlo planteando esta ecuación?:
> DEFAULT_SHMALL=ceil(DEFAULT_SHMMAX/PAGE_SIZE).
> (Los valores default se pueden conocer fácilmente a través del
> programa sysctl -a)

No creo. SHMALL es un limite que aplica al total de procesos, mientras
que SHMMAX aplica a cada proceso individualmente, AFAIK.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

El 19/11/05, Alvaro Herrera<alvherre(at)commandprompt(dot)com> escribió:
> Juanky Moral escribió:
>
> > - la documentación ha cambiado: ya no aparece la fórmula que
> > publicaron en su día para calcular un tamaño razonable para SHMMAX, en
> > función del número de conexiones y del nº de shared_buffers.
>
> Bueno, todavia la formula sigue dependiendo exclusivamente de
> max_connections y shared_buffers, pero las constantes han crecido.
> Es facil hacer una investigacion modificando esos valores para obtener
> varios puntos de la recta y calcular las constantes. Observa que
> Postgres te indica cual es el tamaño del segmento que esta pidiendo, si
> no logra crearlo (hint: bajar SHMMAX hasta un numero ridiculamente
> pequeño)
Bueno, tengo que confesar que molaba más aquello de la fórmula...
pero en fin, supongo que éso es lo que hay.
>
> Hmm, ahora que lo pienso probablemente tambien depende de
> max_locks_per_transaction.
>
>
> > También tengo algunas dudas:
> > - ¿Cómo puedo saber exactamente el tamaño de página (PAGE_SIZE) en mi
> > kernel?. Uso kernel de linux 2.6. Creo que en 2.4 el tamaño era de
> > 4KB, ¿aquí es el mismo tamaño?
>
> Ni idea.
>
> > - ¿puedo deducirlo planteando esta ecuación?:
> > DEFAULT_SHMALL=ceil(DEFAULT_SHMMAX/PAGE_SIZE).
> > (Los valores default se pueden conocer fácilmente a través del
> > programa sysctl -a)
>
> No creo. SHMALL es un limite que aplica al total de procesos, mientras
> que SHMMAX aplica a cada proceso individualmente, AFAIK.
He probado a mantener SHMALL en su valor original (default) y todo
parece ir bien, incluso guardando un 10% de la memoria para
shared_buffers, como dice Momjian.
Creo que es lo que recomendaré (si no me dices lo contrario).
Gracias.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>

--
Juanky Moral - www.juancarlosmoral.es

Juanky Moral escribió:
> El 19/11/05, Alvaro Herrera<alvherre(at)commandprompt(dot)com> escribió:
> > Juanky Moral escribió:
> >
> > > - la documentación ha cambiado: ya no aparece la fórmula que
> > > publicaron en su día para calcular un tamaño razonable para SHMMAX, en
> > > función del número de conexiones y del nº de shared_buffers.
> >
> > Bueno, todavia la formula sigue dependiendo exclusivamente de
> > max_connections y shared_buffers, pero las constantes han crecido.
> > Es facil hacer una investigacion modificando esos valores para obtener
> > varios puntos de la recta y calcular las constantes. Observa que
> > Postgres te indica cual es el tamaño del segmento que esta pidiendo, si
> > no logra crearlo (hint: bajar SHMMAX hasta un numero ridiculamente
> > pequeño)
> Bueno, tengo que confesar que molaba más aquello de la fórmula...
> pero en fin, supongo que éso es lo que hay.

Bueno, lo que trataba de decirte era que construyeras la fórmula :-)

Claro que la fórmula es dependiente de la versión, por lo que si quieres
hacer investigación periodística te costará un poco :-) Siempre puedes
pedirle a alguien de la lista que contribuya ...

Si quieres ser absolutamente riguroso con el calculo, ve
CreateSharedMemoryAndSemaphores() en src/backend/storage/ipc/ipci.c

> > No creo. SHMALL es un limite que aplica al total de procesos, mientras
> > que SHMMAX aplica a cada proceso individualmente, AFAIK.
> He probado a mantener SHMALL en su valor original (default) y todo
> parece ir bien, incluso guardando un 10% de la memoria para
> shared_buffers, como dice Momjian.
> Creo que es lo que recomendaré (si no me dices lo contrario).

Claro que eso fallará cuando llegue alguien con un servidor con 64 GB de
memoria ...

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

El 19/11/05, Alvaro Herrera<alvherre(at)commandprompt(dot)com> escribió:
> Juanky Moral escribió:
> > El 19/11/05, Alvaro Herrera<alvherre(at)commandprompt(dot)com> escribió:
> > > Juanky Moral escribió:
> > >
> > > > - la documentación ha cambiado: ya no aparece la fórmula que
> > > > publicaron en su día para calcular un tamaño razonable para SHMMAX, en
> > > > función del número de conexiones y del nº de shared_buffers.
> > >
> > > Bueno, todavia la formula sigue dependiendo exclusivamente de
> > > max_connections y shared_buffers, pero las constantes han crecido.
> > > Es facil hacer una investigacion modificando esos valores para obtener
> > > varios puntos de la recta y calcular las constantes. Observa que
> > > Postgres te indica cual es el tamaño del segmento que esta pidiendo, si
> > > no logra crearlo (hint: bajar SHMMAX hasta un numero ridiculamente
> > > pequeño)
> > Bueno, tengo que confesar que molaba más aquello de la fórmula...
> > pero en fin, supongo que éso es lo que hay.
>
> Bueno, lo que trataba de decirte era que construyeras la fórmula :-)
>
> Claro que la fórmula es dependiente de la versión, por lo que si quieres
> hacer investigación periodística te costará un poco :-) Siempre puedes
> pedirle a alguien de la lista que contribuya ...
Nunca he dejado de solicitarlo... desde la primera versión.
>
> Si quieres ser absolutamente riguroso con el calculo, ve
> CreateSharedMemoryAndSemaphores() en src/backend/storage/ipc/ipci.c
>
>
> > > No creo. SHMALL es un limite que aplica al total de procesos, mientras
> > > que SHMMAX aplica a cada proceso individualmente, AFAIK.
> > He probado a mantener SHMALL en su valor original (default) y todo
> > parece ir bien, incluso guardando un 10% de la memoria para
> > shared_buffers, como dice Momjian.
> > Creo que es lo que recomendaré (si no me dices lo contrario).
>
> Claro que eso fallará cuando llegue alguien con un servidor con 64 GB de
> memoria ...
Claro. Por eso pido ayuda a esta lista.

La afinación de postgres es crucial para sacar el máximo rendimiento
al servidor. Pero como todos sabemos, no empieza por la afinación de
las querys (índices, y demás), sino por afinar el hardware del
sistema.

Sólo que, para mí y me temo que para muchos, es de lo más críptico que
se puede leer sobre postgres.

Nuevamente, agradeceré cualquier colaboración de la lista que sirva
para ayudarme a escribir un articulo que ayudará a muchos en este
importante objetivo de exprimir postgres.
Gracias.

>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>

--
Juanky Moral - www.juancarlosmoral.es

Lo encontré :)
El valor de PAGE_SIZE es de 4KB (el mismo para linux 2.6 que para linux 2.4):

/usr/src/linux/include/asm-i386/page.h

/* PAGE_SHIFT determines the page size */
#define PAGE_SHIFT 12
#define PAGE_SIZE (1UL << PAGE_SHIFT)
#define PAGE_MASK (~(PAGE_SIZE-1))

PAGE_SIZE es 4096 ( = 1<<12 ).

--
Juanky Moral - www.juancarlosmoral.es