El 5/12/06, Horst H. von Brand<[EMAIL PROTECTED]> escribió: > Miguel Oyarzo O. <[EMAIL PROTECTED]> 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
