Skip site navigation (1) Skip section navigation (2)

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

From: Nelba Sanchez <nnsanche(at)uc(dot)cl>
To: pgsql-es-ayuda(at)postgresql(dot)org
Subject: [Fwd: Re: Ayuda con mensaje "could not bind socket for statistics collector: Cannot assign requested address"]
Date: 2004-11-30 14:52:52
Message-ID: 41AC8944.10105@uc.cl (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
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.






Responses

pgsql-es-ayuda by date

Next:From: Patricio MuñozDate: 2004-11-30 14:54:52
Subject: Re: Newbie
Previous:From: Daniel Andrade MolinaDate: 2004-11-30 14:31:04
Subject: Newbie

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group