Re: Software y Hardware recomendados (para evitar el cambio a Oracle)

Gracias a todos por sus respuestas. Todos los aportes han sido de mucha
ayuda.

Conversaré todos estos temas con el resto del equipo y probablemente un
los próximos días siga haciendo preguntas tal vez más concretas y
comentando si se toma alguna resolución.

En cuanto a la contratación de soporte profesional ya sea en
CommandPrompt u otra empresa, yo ya lo he sugerido desde el principio.
Pero por ahora se están viendo alternativas.

Hay que ver qué tan bien le cae a la empresa que el soporte sea
únicamente remoto, porque CommandPrompt no tiene técnicos en Uruguay, ¿o sí?

Yo de todas formas ya pasé el link de empresas uruguayas y argentinas
(por la cercanía, por si acaso) que están registradas en el sitio de
postgres para dar capacitación y soporte. Pero no es mi decisión.

Como ya dije, esto lo estoy haciendo para que los que en definitiva
tienen el poder de decisión, lo hagan de la manera más informada posible.

Saludos,
Diego

Alvaro Herrera escribió:
> Diego Algorta Casamayou escribió:
>
> Hola
>
>> Este es mi primer mail a esta lista.
>
> Bienvenido!
>
>> En la empresa en al que trabajo estamos usando 2 servidores con
>> postgresql 8.0.2 replicados mediante slony 1.0.5.
>
> En 8.0.2 hay un variado ecosistema de bugs, varios de los cuales se
> alimentan con mucho entusiasmo de tus datos. Si realmente los valoras,
> actualiza a la version 8.0.13. Por que? Explicacion aca:
>
> http://www.postgresql.org/support/versioning
>
> Si estan apretados de rendimiento, entonces es muy recomendable migrar a
> una version posterior (8.2.4), aunque puede ser algo mas de trabajo
> (pero como se ha documentado en esta lista varias veces, la
> compatibilidad hacia atras de las versiones mas nuevas se valora
> bastante, por lo que es bastante posible que el trabajo sea minimo).
>
>
>> Según me dicen, se está buscando tener un mínimo de 50 TPS sostenidas.
>> Pero cada una de esas transacciones puede involucrar varios inserts /
>> updates. Por ahora no tengo datos más concretos.
>
> 50 TPS los puede manejar Postgres muy tranquilamente. La gente que anda
> preocupada de afinar Postgres para situaciones de alta concurrencia
> tiene preguntas en torno a los *varios miles* de consultas por segundo.
>
> El hardware mas aconsejable es
>
> - controladora RAID por hardware con bateria de respaldo de cache de
> escritura
>
> - arreglo de discos en RAID 10 para buen rendimiento
>
> - Toda la memoria que puedas pagar (tope: el tamaño de tu base de datos)
>
> Las CPUs suelen no ser tan criticas, pero versiones "antiguas" de los
> Xeon no eran muy buenas con Postgres. Los de ahora no tienen problemas.
>
> Hace una semana estabamos haciendo unas pruebas en mi empresa, y la
> configuracion que estabamos midiendo consideraba un RAID 10 de 16
> discos, que permitia soportar *tranquilamente* a unos 800 clientes
> conectados simultaneamente haciendo como 2000 consultas por segundo (no
> tengo claro la proporcion de lectura vs. escritura) ... pero eso fue
> antes de ajustar apropiadamente algunos parametros; entiendo que despues
> de eso los numeros subieron, pero no le he seguido la pista a ese
> asunto.
> (Ahora que lo pienso, no llegue a enterarme si la controladora RAID
> tenia o no baterias de respaldo).
>
>> La solución a implementar debe ser tolerante a fallos en el sentido de
>> que en caso de rotura del servidor DBMS, se debe poder automatizar el
>> pasaje a producción de un servidor de backup en menos de 10 minutos.
>> También sería deseable la replicación sincrónica entre servers (lo
>> cual, según tengo entendido, descarta el uso de slony I para la
>> replicación pues trabaja asíncronamente).
>
> Echale una leida a
> http://www.postgresql.org/docs/8.2/static/high-availability.html
> para ponerte al dia en el tema de la alta disponibilidad. Pretender
> usar replicacion sincronica solo porque no suena "bien" el uso de la
> asincronica, puede significar que no estas entendiendo realmente cómo
> funciona la sincrónica y qué consecuencias trae.
>
>> Para el hardware, hoy en día se están usando servidores IBM con
>> procesador XEON 64bits 3.2GHz con 2 GB de RAM y 3 discos SCSI en RAID 5.
>> Por lo que he leído por ahí, el uso de RAID 5 con menos de 6 discos está
>> desaconsejado para usarse con un DBMS y sería mejor usar RAID 1
>> (espejo). Pero se escuchan sugerencias de cambio de hardware.
>
> Lo peor que puedes hacer con tus discos es RAID5, porque la velocidad de
> lectura mejora "un poco" con respecto a un disco solitario, y la
> velocidad de escritura empeora. Lo mejor es un RAID10 (espejo+striping),
> que ademas de darte mejor rendimiento tiene una major resistencia a
> fallos; si la controladora RAID tiene baterias, puedes mejorar el
> rendimiento de forma sustancial activando el cache de escritura de la
> misma, *conservando* la caracteristica de recuperacion total de datos en
> caso de fallas catastroficas (corte de energia, caida del sistema
> operativo, etc). (Una observacion: el cache de escritura de los discos
> mismos siempre debe estar desactivado).
>
>> Hoy en día estamos usando SuSE 9.2 64bit en esos servers, pero tengo
>> entendido que postgresql funciona mejor en OpenSolaris. ¿puede ser? (yo
>> personalmente soy usuario y defensor de Ubuntu/Debian).
>
> No. Es igual en cualquier distribucion moderna.
>
>> La partición donde tenemos los datos tiene XFS como filesystem. Eso sí
>> estaría bien. ¿no?.
>
> Chequea el otro thread, como ya te dijo Mario.
>
>> ¿Sería aconsejable el uso de cosas como cJDBC, Sequoia o SQLrelay para
>> lograr parte de estos requerimientos?
>
> Posiblemente, pero yo no los consideraría en una primera pasada. Lo que
> sí puede hacer una diferencia importante es el uso de un "connection
> pool" como pgPool (entiendo que algunos de los que mencionas también
> hacen esta tarea, pero pgPool es más "bare-bones" y requeriría menos
> cambios en tu configuración actual).
>