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

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).

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.