[jachguate]

Hola, tremendo y viejo hilo que se ha revivido, un saludo a todos los entrañables amigos que van participando por aquí!!

Estoy algo corto de tiempo y, aunque me gustaría, no he tenido ocasión de leer con detenimiento lo que ya se ha mencionado en respuesta a la pregunta de erickahr.

Solo decir que, como bien ha dicho ya mi estimado casimiro es algo aventurado dar respuestas genéricas y por eso, no entraré en mayores detalles. Solo mencionar que si que hay diversas técnicas que se pueden aplicar para encontrar una solución. Como buen DBA (te guste o no, estas llevando ese rol, quizás aparte del de desarrollador y otras cosas), debes aprender a pensar en función de "cuellos de botella".

Cuándo una aplicación está respondiendo más lento de lo que esperarías, usualmente es porque hay un cuello de botella... es decir, tenes cierta cantidad de información y cierta "potencia" en el hardware para procesarla... todo el sistema será tan rápido como el punto del proceso por donde más lento pase la información. Cosas a tener en cuenta son muchas, y varían de acuerdo a cómo tenes configurada la base de datos, cómo se realizan las consultas, etc. Hay que empezar por lo básico, como por ejemplo comprender al optimizador del motor y escribir las consultas de manera que los planes sean óptimos, evitar full table scans, etc.

Cosas a tener en cuenta son:

• I/O (de nada sirve tener ocho nucleos y 40 Gb. de RAM, si los discos son lentos, hay contención o serialización de operaciones a nivel de I/O (por ejemplo, por tener una sola controladora)). Lamentablemente Firebird no ofrece el grado de control que ofrecen otras bases de datos para manejar esto al antojo del DBA, pero si que puede hacerse algunas cosas.
• Procesador. Puede que tengas 16 nucleos, pero que la base de datos solo pueda sacar provecho de uno (especialmente cierto con firebird).
• RAM. En el servidor de base de datos, es bueno tener mucha RAM, y es mejor sacarle provecho. He visto casos donde el dueño del negocio se ve obligado a comprar un servidor con 8, 16 o más GB de RAM, pero cuando revisas Firebird está tirando solamente de un par de ellos. (especialmente cierto con Firebird)
• Memoria Virtual: Esto podría ser parte del punto anterior, del que se desprende otro tema importante. He podido ver en ocasiones servidores de bases de datos con X cantidad de RAM, pero la base de datos está configurada de tal manera que requeriría Y cantidad de RAM, donde Y > X, por lo tanto, el generoso sistema operativo decide hacer uso de la memoria virtual (especialmente cierto con servidores windows). Todo bien, pero lo malo de esto es que mientras el acceso a RAM es del orden de los GB/s, el acceso a disco es cientos o miles de veces más lento. Esto trae al traste la caché de la base de datos que termina por leer de disco lo que supuestamente está en memoria, con la carga adicional de tener que escribir primero al disco alguna página para hacer espacio en RAM... un desastre total.
• Sistema operativo: Quizás lo creas o no... pero el mismo firebird corriendo sobre el mismo hardware en un linux es más rápido que corriendo en un servidor windows. Cuanto más rápido, depende de muchos factores como para aventurarse a dar un número, pero en mi experiencia he llegado a ver casos en que son hasta 50% o 60% más rápidos.
• Mil factores más... no terminaría. Me detendré aquí... me encantaría seguir y me vuelan las ideas.... pero debo llevar los frijoles a mis polluelos y dejar terminadas algunas cosas antes de salir de viaje en menos de 24 horas.

Empezado por erickahr

Hola compañeros, antes que nada buenas tardes (aqui en México), y yo invito la ronda de la 'curacion' porque para estas fechas ya estarán en la resaca de las rondas que mencionaron anteriormente .

Esto es cierto? jajaja, estaré dentro de algunas semanas en tu tierra (DF), lamentablemente poco tiempo, pero quizas podamos llevar esto del plano virtual al plano donde la chela surte sus efectos... ajjaja.

Un saludo y hasta luego.