- Cantidad de usuarioas permitidos v/s conectados: 1000 v/s 200
- Si se liberan los procesos cuando terminan.
- Los vaccum no se hacen de forma automática, hay un equipo que los hace en la
noche via cron.
No mencioné que aca hacemos respaldo de las bases cada 1 hora mediante cron
desde un equipo dedicado para ello y los hace con pg_dump.
Dentro del Conf, tengo relevante:
-shared_buffer = 24MB
-work_mem = 8MB
-maintenance_work_mem = desabled
-effective_cache_size = desabled
-checkpoint_segments = 16
-max_connections = 1000
Gracias.
----- Original Message -----
From: Cesar Erices
To: Marcelo Retamal Vallejos
Cc: Guido Barosio ; Lista Postgres
Sent: Wednesday, November 26, 2008 3:04 PM
Subject: Re: [pgsql-es-ayuda] Fw: Ayuda con equipo
El 26 de noviembre de 2008 14:38, Marcelo Retamal Vallejos <[EMAIL
PROTECTED]> escribió:
Bueno... esta es la historia.
El equipo de un momento a otro se comenzó a pegar. Revisamos el
/var/log/message y no hay nada anormal, excepto por warnigs como " no hay una
transacción en curso". La lectura a los disco es permante, esto es, los leds
leen continuamente sin intermitencia, al producirse esto, comienza a bloquear a
los usuarios que acceden a la BD mediante aplicaciones varias.
Cual es la cantidad de usuarios permitidos por el config vs la cantidad de
usuarios conectados?
Al acceder al equipo via login, se demora en dar respuesa a comandos
básicos como top (la memoria esta casi ocupada en su totalidad pero la cpu
practicamente sin uso, además hay muchos postmaster trabajando) o ls.
puede ser por los procesos sin intermitencia, el sistema que se conecta a
postgres libera las conexiones una vez que las realiza?
Este equipo también cuenta con el samba (que es usado para dejar archivos
de imagenes que luego serán almacenados en la BD) y el acceso a este recurso es
muy alto, lo que quiere decir, que se hacen muchos lo_import y lo_export de
archivos.
Al bajar el servicio PG, bueno, se liberan las conexiones y procesos y el
equipo vuelve a esta Ok,
logico si matas los procesos
los vacuum cada cuento tiempo los haces, seria bueno que revisaras eso, y
los procesos que se pegan , deberias revisar tu aplicacion para que libere
dichos proceso...
pero a medida que hay más conexiones y peticiones comienza a quedar pegado
hasta que no hay forma de acceder a la BD y menos al servidor.
Eso.
Por eso necesitamos saber cuales son las condiciones que deben cumplir un
equipo para lograr un servidor de BD PG de alta disponibilidad.
además de eso es necesario que veas la configuracion de postgres y revisaras
porque quedan pegaos esos procesos..
Gracias de antemano.
----- Original Message ----- From: "Guido Barosio" <[EMAIL PROTECTED]>
To: "Marcelo Retamal Vallejos" <[EMAIL PROTECTED]>
Cc: "Lista Postgres" <pgsql-es-ayuda@postgresql.org>
Sent: Wednesday, November 26, 2008 2:17 PM
Subject: Re: [pgsql-es-ayuda] Fw: Ayuda con equipo
Marcelo,
No estas describiendo cual es el problema, sino diciendo cual es
la solucion que le queres dar. Seria objetivo para el resto que nos
comentes un poco de que se trata esto para asi poder avanzar con ideas
=)
Saludos,
gb.-
2008/11/26 Marcelo Retamal Vallejos <[EMAIL PROTECTED]>:
Hola lista, en especial a Alvaro. Hemos tenido últimamente problemas con
uno de los servidores principales de BD de la empresa (PG 8.2.4 en
opensuse
10 para 64 bits), el problema está en la alta disponibilidad de este
equipo,
y que ha llevado a tener horas muertas de acceso (en resumen, histeria
total
por parte de los usuarios). Llevamos años en PG, creo que desde el 2003, y
hemos tenido optimos resultados pero ya estamos llegando al colapso. Lo
raro, que el equipo al detener el servicio del postgres se libera y no
queda
pegado. A donde quiero llegar, queremos tener conciencia de cómo salir del
paso cuando el equipo se pega. Hemos pensado en replicación, en cluster,
cambiar de distribución de linux (el postgresql.conf esta ok).
La pregunta sería: ¿Que condiciones deben cumplirse para lograr un
servidor
de BD PG de alta disponibilidad?.
Como nota: el equipo es un servidor 2U, con opensuse 10 de 64 bits, 4GB en
RAM, RAID 5 SCSI, 73 GB EN DD, no hay replicación, sólo respaldos con
pgdump.
Espero su ayuda, gracias.
Atte., Marcelo Retamal Vallejos
Ingeniería de Sistemas
CMET
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo
agradecerán
--
TIP 7: no olvides aumentar la configuración del "free space map"
--
Cesar Erices Vergara
Ingeniero en Gestión Informática
Analista de Sistema
Santiago - Chile
