Re: Servidores grande y su maximo rendimeinto

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

In response to

Browse pgsql-es-ayuda by date

  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