Re: [Fwd: Re: Ayuda con mensaje "could not bind socket for statistics collector: Cannot assign requested address"]

Hola.
El documento que más me ha servido en este tipo de cuestiones (HW
tunning) es, sin lugar a dudas:
http://www.ca.postgresql.org/docs/momjian/hw_performance/

Una sinópsis muy apretada:
shared_buffers: empezar con un 10% del total de la RAM
work_mem: entre un 2-4% del total de la RAM para pocos accesos
simultáneos a grandes sesiones de ordenación, y valores mucho más
pequeños para muchos accesos simultáneos a pequeñas sesiones de
ordenación.

Por supuesto, hay que controlar que si el total de shared_buffers
asignados excede el tamaño máximo del segmento (en linux, fácilmente
lo hará), habrá que pasarle al kernel nuevos valores para: SHMMAX y
SHMALL.
(En la documentación de postgres hay una fórmula para estos números:)
http://developer.postgresql.org/docs/postgres/kernel-resources.html

Por último, Momjian sugiere ir probando distintos valores mientras
observamos tanto el rendimiento como la paginación. Para esto último
dispones de vmstat o ipcs.

Un saludo.

On Tue, 30 Nov 2004 11:52:52 -0300, Nelba Sanchez <nnsanche(at)uc(dot)cl> wrote:
> Alvaro, Hola,
>
> Los valores fueron obtenidos a partir de pruebas de carga, en una máquina
> chica de 512MB en RAM con postgres 7.4, en donde los parámetros que ayudaron
> a mejorar el rendimiento fueron shared_buffer y max_connections, el
> effective_cache_size realmente no fue muy notorio lo que aportó, se hicieron
> pruebas subiendolo al doble y cuatruple a veces y no mejoraba la utilización
> de cpu, ahora este parámetro tiene que ver con el cache en Disco del Kernel,
> y se configura como el shared de a 8K, pero me quedó la duda más aún como me
> indicas que esta muy bajo.
>
> Para configurar la máquina definitiva se partió de la base que la memoria
> compartida que postgres alocatea no puede ser superior al 25-50% de RAM si
> trabajas en ambientes compartidos con otras BD y/o aplicaciones, por lo
> tanto se vio primero el parámetro shminfo_shmmax el que debe ser el 20% para
> el caso de una máquina de 8GB serían 1600MB, de ahí solo se quizo utilizar
> 650MB (esto si en forma aleatoria) más la cantidad máxima de conexiones 512
> c/u utilizando 14K da un total de 7MB en total 657MB --> de aca salen los
> 83200. Efectivamente el link que puse sobre el tunning no era el que
> utilice, fue este
> http://www.n2h2.com/downloads/ifp_linux/v2.5/postgres_config.html, el
> effective_cache_size antes estaba en 1000.
>
> Estamos en etapa de pruebas y se insistirá con el afinamiento de ser
> necesario.
>
> Muchas Gracias, me interesa discutir esto con personas con experiencia, por
> estos lados no tengo personas con esas características y puedo estar
> equivocada con mis conceptos.
>
> -------- Original Message --------
> Subject: Re: [pgsql-es-ayuda] Ayuda con mensaje "could not bind socket for
> s tatistics collector: Cannot assign requested address"
> Date: Mon, 29 Nov 2004 20:24:51 -0300
> From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
> To: Nelba Sanchez <nnsanche(at)uc(dot)cl>
> CC: pgsql-es-ayuda(at)postgresql(dot)org
> References: <463a53a404111711455f4298a8(at)mail(dot)gmail(dot)com>
> <41A732A4(dot)5020601(at)uc .cl> <20041127162000(dot)GA21842(at)dcc(dot)uchile(dot)cl>
> <41AB1D83(dot)3010700(at)uc(dot)cl>
>
> On Mon, Nov 29, 2004 at 10:00:51AM -0300, Nelba Sanchez wrote: Nelba, >
> Alvaro, los numero no fueron para nada "inventados" me documente antes > de
> cambiarlos, y se han hecho varias pruebas de carga para determinar > esos
> valores, en un inicio ese estudio no se realizó y hubieron muchos >
> problemas que ahora estamos solucionando, en fin, realmente me ofendes > con
> tu comentario, Oops, mil perdones. La verdad es que al momento de escribir
> ese mensaje estaba algo espantado debido a que venia saliendo de una
> experiencia traumatica con un servidor mal configurado, que se caia todos
> los dias. Corrigiendo la configuracion dejo de caerse. Quede algo aturdido
> por la extrema falta de cautela exhibida por el individuo que sugirio el
> cambio. > creo que sería mas contructivo que sugirieras los cálculos que >
> fundamenten estos números, los cuales fueron extraidos de : > >
> http://www.varlena.com/GeneralBits/Tidbits/perf.html >
> http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html > >
> En fin, poner los calculos numericos si de algo sirviera mi ejemplo lo >
> haría, avisame. Por favor hazlo. Que yo sepa no hay formulas que entreguen
> numeros "correctos". La unica forma de obtener los mejores numeros es hacer
> experimentos, midiendo el rendimiento del servidor frente a una carga lo mas
> parecida a tu carga real para distintos valores de los parametros relevante
> (que, hasta donde entiendo, es lo que ustedes hicieron). Ahora, leyendo el
> documento "Tuning PostgreSQL for performance" encuentro que el consejo sobre
> shared_buffers es razonable y de ninguna manera valida lo que tu usaste en
> ese parametro. El problema es que hay ciertas ineficiencias en Postgres (al
> menos en versiones anteriores a 8.0) que hacen que tener shared_buffers
> demasiado alto (> 30000 probablemente) sea contraproducente, por eso es que
> el valor de 80000 que citaste me hiciera sonar la campana. Finalmente, el
> valor de effective_cache_size me parecio ridiculamente bajo y probablemente
> no se condice con la realidad. Seria bueno que detallaras el proceso que
> usaste para encontrar los numeros; si fue puramente utilizacion de alguna
> formula, o si son unicamente resultados experimentales? O una combinacion de
> ambas cosas, y cual seria esta combinacion? > TE agradezco de todas formas
> todo lo que me aconsejas sobre el colector, > la BD ha estado estable no se
> ha caido nuevamente, voy a revisar mejor > los procesos antes de levantar la
> BD nuevamnete. Ok.
>
>

--
Juanky Moral
(desde Valencia, España)