RE: postgres postgresql.conf

From: "Dario" <dario_d_s(at)unitech(dot)com(dot)ar>
To: "Marcelino Guerrero" <mguerreroh(at)gmail(dot)com>, "Lista de Correo Postgresql" <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: RE: postgres postgresql.conf
Date: 2005-08-10 23:14:48
Message-ID: MHEDJHCKDNOEHJKHIOCJIEMJCFAA.dario_d_s@unitech.com.ar
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

shared_buffers tiene que ser al menos 2 * max_connections... pero podría ser
más, depende de tu hard, tu aplicación, los demás procesos que corran en
servidor y del humor del usuario (hay usuarios que les gusta refrescar
búsquedas sin filtros...)

fsync: Esos valores fuerzan que se escriba a disco los archivos "wal" write
ahead logging.

Hay que dejarlo en true y no debería cambiarse a menos que se sepa
exactamente las consecuencias, para eso, RTBM (read the blessing manual).

Basicamente las consecuencias son, en el caso de una caida del servidor, una
segura e inevitable corrupción de datos, que obliga a tener que levantar
desde un backup. Hay otra consecuencia; es más rápido, pero yo no lo
activaría en ningún lado, salvo que estén dadas algunas condiciones muy
particulares.

Fragmento traduicdo del manual para los no angloparlantes:
El concepto central del proceso de wal es que las modificaciones a los
archivos de datos (las tablas y los índices) deben ser escritos una vez que
estos cambios han sido "registrados", o sea, cuando las entradas de este
registro(log) describiendo los cambios, hallan sido almacenados a un
dispositivo de disco (permanent storage). De esta manera, no es necesario
almacenar las páginas de datos en memoria a disco cuando la transacción se
"compromete" (comitea), y, en el caso de un evento de caida, será posible
hacer la recuperación de la base de datos usando este registro (log),
cualquier cambio no aplicado a las páginas de datos puede ser reconstruido
desde las entradas del registro. (fin de la mini tradiucción)

Los sistemas operativos realizan la escritura usando cache de escritura, es
posible que un dato que ya fue comprometido y según el S.O., escrito en
disco, no quede registrado en ningún lado, con la consiguiente pérdida no
solo de los datos, sino también de la consistencia de los mismos. Fsync
(sincronización forzada) le dice al sistema operativo que no use el cache de
escritura.

Saludos

-----Mensaje original-----
De: pgsql-es-ayuda-owner(at)postgresql(dot)org
[mailto:pgsql-es-ayuda-owner(at)postgresql(dot)org]En nombre de Marcelino
Guerrero
Enviado el: miércoles, 10 de agosto de 2005 18:40
Para: Lista de Correo Postgresql
Asunto: Re: [pgsql-es-ayuda] postgres

Amigos,

En postgresql.conf indica (si no he entendido mal) que el
shared_buffers debe de ser igual a max_connections * 2, es correcto
esto?

Otra cosa hace un tiempo comentaron acerca de la importancia de tener
fsync = true, tambien habia que activar wal_sync_method = fsync,
pregunto esto debido a que desde hace poco estoy incursionando en
PostgreSql.

Muchas gracias

>Tal vez el max_connections = 100 del $PGDATA/postgresql.conf te queda
>corto...
>Y como dice de el archivo mismo, al incrementar este valor hay que fijarse
>que el shared_buffers no se quede por debajo de los 2 x max_connections.
>Tmbn hay otro parámetro...
>
>El otro día leí y me pareció muy lógico (y aparte lo dijo Tom Lane :-) )
que
>muchas conexiones, levantan muchos procesos y si tenés una gran cantidad de
>conexiones, puede consumir muchos recursos que la mayor parte del tiempo
van
>a estar idle. El tomcat (si no me equivoco) tiene un pool de conexiones. Si
>no es así o no se puede implementar facilmente, existe el módulo pgpool
pero
>no puedo dar precisiones más allá de saber que existe.
>
>Saludos.

On 8/10/05, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> On Wed, Aug 10, 2005 at 12:25:29PM -0500, David Licet wrote:
> > Sigo pidiendo ayuda...
> > Tengo una aplicación web con Tomcat y se pierde la
> > conexion a la base de datos a la cual se accede a
> > traves de un pool de conexiones y
> > recibo este mensaje en el archivo log stout:
> >
> > Bootstrap: Create Catalina server
> > Bootstrap: Starting service
> > Starting service Tomcat-Standalone
> > Apache Tomcat/4.1.12
> > Bootstrap: Service started
> > DBCP borrowObject failed:
> > org.postgresql.util.PSQLException: Falló el arranque
> > del Backend: FATAL: connection limit exceeded for
> > non-superusers.
>
> Hmm, si ves que la cantidad de procesos crece sin ningun limite
> aparente, puede ser que Tomcat no tenga su pool de conexiones
> configurado apropiadamente; quizas el numero de conexiones a establecer
> es demasiado grande. Verifica esa configuracion. O quizas sea un
> simple bug en tus programas que no "devuelva" una conexion al pool, si
> tal concepto existe en Tomcat (lo ignoro).
>
> --
> Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
> "El miedo atento y previsor es la madre de la seguridad" (E. Burke)
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 3: si publicas/lees desde Usenet, por favor envía "subscribe-nomail"
> a majordomo(at)postgresql(dot)org para que tus mensajes puedan llegar
> a los suscriptores de la lista
>

---------------------------(fin del mensaje)---------------------------
TIP 5: ¿Has leído nuestro extenso FAQ?

http://www.postgresql.org/files/documentation/faqs/FAQ.html

In response to

  • Re: postgres at 2005-08-10 21:39:47 from Marcelino Guerrero

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Nain Zp 2005-08-11 01:41:26 Re: PROBLEMAS CON EL SERVIDOR
Previous Message Alvaro Herrera 2005-08-10 22:34:39 Re: postgres