CORE DUO

[Rodrigo Fuentealba]

El 5/12/06, Horst H. von Brand<vonbrand en inf.utfsm.cl> escribió:
> 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?

¿varios procesos hijos escriben en el mismo socket intentando no
pisarse la cola entre ellos?

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

sí aportará, pero si es un sólo proceso (que lo dudo) el que escribe
en un socket, el aporte vendrá por otro lado: mejor predictibilidad, y
otras cositas.

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

no necesariamente, puedo correr una instancia de un programa (i.e.
openoffice) que consuma un procesador, y como estará ocupado, una
instancia de (por ejemplo) netbeans puede tirarse a que consuma otro
procesador. No son procesos hijos, no son paralelos, son múltiples
tareas.

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

No, a menos que se programe el proceso para repartirse. Cada proceso
es una unidad que puede ser divisible en instrucciones, pero es
ilógico que repartas instrucciones entre procesadores puesto que el
procesador que pide el favor se tiene que quedar esperando a que le
devuelvan... etc.

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

Eso se llama "no planificar", cosa que se ve mucho. (¿Alguien me puede
explicar por qué si las bases de datos son tan importantes, poca gente
le toma el peso o se preocupa de cosas importantes como los índices y
usar los joins correctamente en vez de lanzar SELECT's a diestra y
siniestra?). En fin, en proyectos grandes relacionados con bases de
datos cuesta demasiado planificar

Por estos lados, utilizando MySQL un proceso (que leía unos archivos
DBF generados por SAP para meterlos luego en esa base de datos) se
completaba en exactamente 27 minutos, y se consumía toda la CPU para
insertar 83000 filas (cosa curiosa). Pensaron en ponerle un par de Gb
de memoria más al tarro... menos mal y repasaron el código antes:
había cosas que ni siquiera me las quisieron contar para que no me
riera (cómo habrán sido de tontas)... resultado? subió, procesó y
mostró en 1 minuto 20 segundos (y todavía cuando vi el código ya
arreglado quedaba por optimizar, pero bueno...)

NO (si, con mayusculas) estoy diciendo que tengas esa clase de
errores, pero ocurre mucho ese tipo de cosas: Consejo: revísalo...
estoy casi seguro de que alvherre tenía un documento por ahí sobre
cómo planificar los índices de una consulta, bastante útil para estos
casos... Si tuviera mi notebook aquí...

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

MySQL 4 con MyISAM sí, pero no tiene las garantías de integridad
referenciada... en cuanto se usa InnoDB, el rendimiento decae
notoriamente. MySQL 5 no lo he probado, no quiero hacerme mala sangre.

-- 
Rodrigo Fuentealba Cartes
Desarrollador de Sistemas Web
Registered User 387639 - http://counter.li.org