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

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.