> -----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. -- TIP 7: no olvides aumentar la configuración del "free space map"