2014-08-22 14:51 GMT-05:00 Fabricio <fabrix...@hotmail.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@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
