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

Re: Ayuda con mensaje "could not bind socket for s tatistics collector: Cannot assign requested address"

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
Subject: Re: Ayuda con mensaje "could not bind socket for s tatistics collector: Cannot assign requested address"
Date: 2004-11-29 23:24:51
Message-ID: 20041129232451.GD30997@dcc.uchile.cl (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
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.

-- 
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"I would rather have GNU than GNOT."  (ccchips, lwn.net/Articles/37595/)

In response to

pgsql-es-ayuda by date

Next:From: Carlos TonioloDate: 2004-11-30 03:51:08
Subject: Fw: Buenas noches..
Previous:From: Alvaro HerreraDate: 2004-11-29 22:46:44
Subject: Re: resplados periodicos

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