CORE DUO

[Horst H. von Brand]

Miguel Oyarzo O. <admin en aim.cl> wrote:

[...]

> Por ejemplo, mysql no abre procesos hijos y ejecuta todas las
> consultas en el mismo socket.

El mismo proceso, o son varios?

> Este consume la CPU fuertemente (hasta en un 80% en nuestro caso y por
> lapsus de varios segundos).
> 
> Segun lo que dices, CORE duo no aportara mejora.

Yep.

Y para bases de datos lo que importa en muchos casos es simplemente la
serializacion de los accesos a los datos. Si, p.ej., toda transaccion tiene
que obtener un nuevo numero de factura via incrementar un contador comun,
no sacaras demasiado paralelizando.

> Entonces, el doble nucleo solo se usa en procesos hijos y
> procesamiento "paralelo" nomas?

Procesos hijos, hebras, ... Notese que en un tarro Unix generalmente hay
varias actividades (no demasiado demandantes, eso si), un dual core te
permite hacer eso en paralelo con el resto (y ganas solo por eso, digamos,
un 5%). 

> No es capaz de dividir y repartise el proceso entre los nucleos?

Hay que programar el sistema de esa forma, y hay que tener cuidado que no
se tropiece con sus propios pies al trabajar en paralelo (aca en un core
duo /ninguna/ de las tareas de hebras de sistemas operativos anda, en los
tarros de una CPU andan como avion...) y que no se auto-entrabe
innecesariamente.

Cuidado, vi con estos mismos ojitos una aplicacion de base de datos que se
demoro un par de horas antes que la abortaran (!), que reorganizando (por
la via de agregar indices juiciosamente, division/agrupamiento de los
campos en tablas, y reorganizar las consultas de forma de "filtrar lo mas
posible al comienzo" y evitar tomarse tablas completas, y algunos cambios
de algoritmo, aprovechando las capacidades de busqueda del RDBMS y/o
procesando secuencialmente en el orden natural) se completaba en cosa de un
minuto.

Antes de tirarse con "mas maquina" hay que analizar que esta pasando. Si el
RDBMS se la pasa la mayor parte del tiempo esperando que se liberen
registros/tablas, con mas CPU esperara mas rapido, pero no menos tiempo.
Puedes estar corto de RAM (swapping es fatal para rendimiento!). Etc.

Otra cosa que me han soplado es que MySQL si es mas rapido que Postgres (en
las consultas simples que maneja), pero en cuanto solicitas las garantias que
un RDBMS de a deveras te da anda mas lento que el caballo del malo, y como
en Postgres puedes hacer consultas mas complejas el rendimiento de la
aplicacion como un todo suele ser bastante mejor, ademas que el resultado
es mas simple (y mantenible). Claro que significa reorganizar y redisen~ar
pesado...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513