RE: Tunning PGSQL

> -----Mensaje original-----
> De: Javier Fritz Alsite
>
> Hola.
>
> gracias por las recomendaciones.
>
> te comento que el sistema ya tiene montado un Raid 1 ;),
> estoy evaluando la posibilidad de montar un tercer disco para
> mejorar la performance de escritura. Pero lo estamos evaluando.
> Respecto a las conexiones estas son de lectura/escritura,
> el servicio corresponde al uso de sistema tipo erp
> (cliente/servidor), por lo que la cantidad de query's de
> "escritura" es casi equivalente a las de "lectura".

Mi recomendación es que apuntes directamente a 4 discos con RAID 1+0. Es una
configuración económica por cuanto cualquier motherboard y chasis te soporta
los 4 discos. Si pueden ser 6 o más, mucho mejor! Creeme que no será un
derroche.
Recomiendo también lo instales sobre Linux y el raid lo montés con mdadm que
es excelente, salvo tengas una controladora HW RAID.

>
> No conozco bien un sistema de pool de conexiones, segun
> entiendo esto corresponde a un servicio que administra
> conexiones activas y las entrega segun corresponda, esto
> corresponde a un modulo del postgresql ó a una aplicacion
> adicional. Que modelo se recomienda??
>
> Teniendo lo anterior en consideración cuantas conexiones
> son un maximo aceptable???
>
> Estimo que el sistema podria llevarse facilmente y sin
> mayor complicación a unas 250 conexiones maximas, pero cuanto
> más significara un desgaste en el servicio de datos??
>
>

Cada conexión equivale a un proceso en ejecución que consume recursos del
servidor: memoria y cpu, incluso aunque no hagan nada. Además, cada apertura
o cierre de conexión es particularmente costoso en términos de ciclos de
cpu.
Generalmente, en sistemas interactivos, la mayoría de estas conexiones no
están haciendo nada y consumiendo recursos por no hacer nada. Allí es donde
entra en juego el pool de conexiones.
Postgres no tiene pooling nativo pero existen al menos 2 soluciones externas
ampliamente adoptadas: pg-pool2 y pgbouncer.

¿Cuando implementar un pool? Bueno, si superas las 40-50 conexiones ya se
torna interesante.
En tu caso, con 4 cores y mucha memoria seguramente podrás atender 200
conexiones sin impacto considerable pero siendo tan sencillo implementar un
pool sería un desperdició no hacerlo.

Otra ventaja del pool es que te limita la concurrencia. Si los 200 usuarios
deciden disparar un proceso de cierre de contabilidad, sin un pool todos
lograrán ejecutar simultáneamente poniendo el servidor de rodillas y tendrás
un 100% de los usuarios muy enojados esperando al sistema. Si en cambio lo
limitas a digamos 20 conexiones, te aseguras que los primeros 20 serán
atendidos rápidamente, luego los 20 siguientes y así, lo cual es mejor a que
entregar todos los resultados juntos después de varias horas. Solo tendrás
que disculparte con los últimos 20 :)

Saludos,
Fernando.