From: | Jaime Casanova <jaime(at)2ndquadrant(dot)com> |
---|---|
To: | Fabricio <fabrixio1(at)hotmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: Servidores grande y su maximo rendimeinto |
Date: | 2014-09-18 18:45:26 |
Message-ID: | CAJKUy5gU4TfWM3zXO9404YLt4bG6jbikWi4iRU5xQTJWdrn3Rg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
2014-08-22 14:51 GMT-05:00 Fabricio <fabrixio1(at)hotmail(dot)com>:
>
> Por ejemplo si hayun servidor de 64 cores y 128GB de RAM y este da un
> rendimiento aproximado de 900 operaciones por segundo atendiendo alrededor
> de 700 usuarios
a que llamas "operaciones por segundo"? lectura/escritura? o estas midiendo
algo mas?
algo que no mencionaste aquí es el disco, es muy importante porque no
importa que tantos procesadores o memoria tengas, si el disco es lento
será un cuello de botella.
de hecho, en lugar de gastar en mas procesadores, yo gastaría en mas
discos y los pondría en un arreglo.
>¿Qué debería esperar de un mainframe o un power con
> cientos de cores y memoria?
aca tengo un servidor con solo 24 cores y 64GB de RAM que atiende
700 gps cada 3 segundos escribiendo
su posisción y 2500 usuarios web (se que no es lo mismo que
conexiones concurrentes a la base). En total todo el tiempo hay alrededor
de 400 conexiones establecidas a la base (cabe decir que se utiliza un pool
de conexiones).
Ahora, no solo interesa el hardware sino también el software y no solo
la base o la aplicación. Por ejemplo en RH6/Centos6 viene habilitado
Transparent Huge Pages que ha demostrado ser una equivocación en el
caso de Postgres y toca apagarlo.
Lo que trato de explicar es que se debe conocer toda la arquitectura y
medir todo en el camino para que puedas saber donde están los
problemas.
> es decir, ¿La base de datos no tiene alguna
> limitante en cuanto a concurrencia u operaciones máximas que pueda procesar
> y me procesara muchas mas con servidores mas robustos?
>
si tiene limitantes. el disco, mapeo de memoria, si tienes mas memoria tendras
mayor problema de escritura cuando el SO vuelque las paginas sucias a disco,
además hay un problema referente a contención cuando tienes demasiados
cpu's (ojo que esto son limitantes de hardware y so realmente por que
postgres no manejas estas cosas de forma directa, aunque si hay código
asembler dependemos de que el procesador y/o so de las facilidades)
En lugar de tener una sola máquina con cientos de cpus y memoria es
más práctico/útil tener varias máquinas y balancear carga de lectura
por ejemplo. O si usas BDR (http://2ndquadrant.com/es/recursos/bdr)
carga de lectura y escritura.
Es mejor no solo porque aprovechas mejor el hardware que tienes pero
además al tener redundancia eliminas los puntos únicos de fallo y te
permite configurar HA.
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Phone: +593 4 5107566 Cell: +593 987171157
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2014-09-19 17:11:55 | webinar sobre Replicación Bi Direccional (BDR) en PostgreSQL |
Previous Message | Emanuel Calvo | 2014-09-18 13:22:11 | Re: Como concatenar bases de datos de mismo esquema distinta data |