SQL muy lenta la 1ª vez
Hola a tod@s, pues lo dicho, tengo una consulta que al ejecutarla nada más iniciar el PC le cuesta mucho, unos 5 minutos, las siguientes veces la resuelve en 3 segundos. Solo cuando se reinicia el PC, si reinicio el FBServer la resuelve rápida. Tengo índices creados por los campos que forman las condiciones, el plan que utiliza, para mi entender, es el correcto. Si fuera menos diferencia podría entender que se tratara de temas de caché.
La consulta es algo así: También he probado esto:
a ver si podéis echarme una mano Gracias de antemano |
Hay un problema conocido con las Base de Datos FB y las copias de seguridad del sistema "Restauración del sistema". Suena a que te está pasando algo así.
Puedes hacer una prueba rápida desactivándola y a ver qué tal. No estaría mal que dijeras qué sistema estás utilizando (S.O.) Cuando separamos el sistema, otra cosa que te puede estar pasando es esta. |
Gracias Neftali, apareces por todas partes. Todo eso está comprobado. La verdad es que llevo un par de días a vueltas con esto.
Restaurar sistema desactivado, uso IP en lugar de nombre, la afinidad está puesta a 0 (CPU 1) en firebird.conf, no hay discos shadows y no hay Blobs en esa consulta. He probado en mi equipo con protocolo LOCAL y TCP_IP y lo mismo, la primera vez un dolor las siguientes visto y no visto. En el cliente el equipo se enciende sobre las 2:00 de la mañana y el lanza la consulta sobre las 9:00, para esas horas todas las tareas de mantenimiento han terminado. Los SO's: Cliente: Windows Server 2008 64bits. FB 2.1.4 32bits. Mi equipo: Windows 7 64bits. FB 2.14 32bits. Hay que decir que la tabla1 tiene 24 campos, una longitud de registro de unos 14KB y actualmente anda por el millón de registros. |
Bastante difícil es poder ayudar sin tener el equipo a mano y probar, que además lo pones más difícil. Por ejemplo, esas sqls que has puesto no son las que estás usando, evidentemente.
De todas formas, si la primera vez va lento y después va rápido, está claro que hay algo que no tiene que ver con la base de datos, deberías probarlo en local, luego en otro ordenador haciendo de servidor y así comprobar. Desde luego, que aunque dices que lo has verificado, está claro que algo hace el sistema para tardar tanto la primera vez. Si en lugar de probar antes esas consultas, pruebas otras diferentes, ¿también va lento la primera vez y después no?. En fin, que no das mucha información para poder hacernos una idea real del sistema. |
Hola amigos, la situacion puede ser la siguiente: primero revisar la extension de la base de datos, evitar .gdb y colocarle .fdb, esto es debido a que no me acuerdo desde que version de Windows los archivos con extension .gdb estan relacionados con el sistema operativo y este hace una copia de seguridad la primera vez que se abre el archivo y si es de buen tamañao pude durar unos minutos. Lo segundo es que la consulta es un producto cartesiano puro, es decir, si tienes en la tabal a 1.000 registros y en la b unos 2.000, la tabla resultante endra 2.000.000 de registros y eso es demoradp escribir tantos registros en una tabla mas si tienes indicies y llaves priamrias y foráneas.
Puedes darnos un poco más de información del contenido de las tablas, volumen de registros y la consulta completa para tratar de colaborarte. |
SQL muy lenta la 1ª vez
Hola y gracias por el interés.
La BD ya tiene extensión FDB. El producto cartesiano puro y duro, en este caso, es obligado. Por varias razones necesito que todos los artículos (tabla2) que entran en la consulta estén en todos los almacenes (tabla3) del cliente. Ya probé en otro equipo (el mío) con diferentes protocolos (local y tcp_ip), me psa lo mismo. Buena idea esa de probar otras consultas, de momento he lanzado el producto cartesiano "sin condiciones", más duro todavía, y lo ha resuelto rápido. Me queda probarlo con udf's por ver si es tema de reserva de memoria. La consulta real es la siguiente: Artal: tabla de poco más de un millón de registros con esos 14KB de longitud Artic: unos 52.000 registros Almac: 40 registros asCreaTalla, asIniTalla son udf's que tratan cadenas de texto. Como he mencionado probaré a quitarlas de la consulta por ver si es ese el problema. Toda la información que necesitéis la pedís, no hay problema, es por no extenderme mucho ya que los mensajes largos a mí me asustan. Un slaudo. |
Hola de nuevo, he probado quitando las udf's y tenemos el mismo resultado, la primera vez unos 6 minutos y las siguientes unos 3 segundos. Observando el proceso FBServer hace unas 436.000 lecturas, siempre. La diferencia es que la primera vez va de unos 1.200 en 1.200 y las siguientes de unos 120.000 en 120.000. Curioso que sea justo por 10. ¿Tendrá algo que ver la configuración del FBServer?.
Las que he tocado: TempBlockSize = 2097152 BugcheckAbort = 1 TcpRemoteBufferSize = 16384 Os pego la cabecera de la BD por si también da pistas: Database header page information: Flags 0 Checksum 12345 Generation 4376 Page size 4096 ODS version 11.1 Oldest transaction 2396 Oldest active 4272 Oldest snapshot 4272 Next transaction 4273 Bumped transaction 1 Sequence number 0 Next attachment ID 90 Implementation ID 16 Shadow count 0 Page buffers 2048 Next header page 0 Database dialect 3 Creation date Nov 22, 2012 14:28:30 Attributes force write Variable header data: Sweep interval: 0 un saludo. |
Una pregunta en tu sistema cuando entras por primera vez en el dia haces el merge y luego utilizas la tabla sn volver a ejecutar el merge ? Si es asi pues debe demorarse por el volumen gigante de resitros que estás creando. De otro lado si cada día eliminas los datos del dia anterior y vuelves a crearlos estas limpiando una cantidad de páginas de la base de datos y volviendo a utilizarlos y para firebird es un poco pesado hacer esto y ralentiza efecutar tareas como los backups.
Creo que el volumen de registros es alto por el asunto de ser un producto cartesiano de esas caracteristicas y firebird lo ha resuleto en un tiempo acorde a ese volúmen. Muy respetuosamente, haz revisado si la solución que encuentras en el merge es posible que pueda hacerse por otro camino ? Cuanto gigas mide tu base de datos ? |
Yo nunca he necesitado usar merge ni matched, seguramente puedas hacerlo de otra forma.
Es más, es que ni siquiera sabía de la existencia de ellos. Aunque tampoco debería ser motivo de lentitud la primera vez. |
Hola Ibuelvas.
Este proceso lo ejecutan varias veces a lo largo del día. Registros nuevos pueden ser del orden de 1 ó 2, no dan de alta materias primas todos los días, y si dan será 1 ó 2. Claro que para saber si están o no compara con gran cantidad de registros, los del artal. El producto cartesiano que tanto nos preocupa a todos, la verdad que cuando veo uno lo primero es echarme las manos a la cabeza, lo resuelve siempre en pocos milisegundos. No se eliminan nunca los registros de las materias activas. Hoy estoy probando con la sieguiente SQL que es prácticamente lo mismo: He probado en FB2.1.4 32bits, FB2.1.4 64bits y en FB2.5.264bits todos sobre un Windows 7 64bits virtualizado con 6GB de ram y dos cores a 3.4GHz y mismo resultado, la primera vez penoso y las siguientes de alucinar. Creo que va a ser temas de caché aunque me cueste creerlo. Por si da pistas, las pruebas echas con FB2.1 32 y 64bits han atacado a la misma BD, pues bien en cuanto lo ejecutaba con un servidor el otro era rapidísimo, indistintamente de cuál usara primero. Un saludo |
¿El servidor es un windows virtual?
Si es windows entonces supongo que estarás usando la versión superserver, además "ánclalo" a una sola cpu, no uses más de 1. Cambia firebird.conf la propiedad CpuAffinityMask por el valor apropiado. El tamaño de página debe ser 8192 al menos. Si es una máquina virtual entonces procura que sea de tamaño fijo, no dinámica. No estaría mal tener un disco aparte para los archivos temporales. También te recomiendo que mires este documento, aunque es para windows 2003, creo que es válido para las siguientes versiones. |
Hola Casimiro, el del cliente es un Server 2008 64bits y sí, es un virtual con VMWare. Las últimas pruebas, por no tocar mi sistema, las he echo sobre un Win 7 64bits virtualizado con VBox, pero también hice sobre mi equipo con windows real obteniendo los mismos resultados.
La propiedad CpuAffinityMask está a 1, antes no lo he indicado porque es el valor que, en teoría, viene por defecto, aún así lo tengo sin la almuadilla (#) de comentario. Todas las instalaciones que tengo son superServer. Me has leído el pensamiento, mientras hacía un backup/restore para cambiar el tamaño de página ha entrado tu respuesta (por cierto gracias). Con respecto al documento, por si acaso, lo pondré en el registro del cliente (ya le vale al Windows tiene un servicio definido como gds_db y puerto 3050 y aún así tiene que tocar las narices????). Un saludo y muchas gracias |
o también puede usar SuperClassic, el cual si permite manejar bien los nucleos y manejar muy bien excepciones de Firebird
|
Hola, en el cliente tengo instalado el FB 2.1.4 el cual no me permite superclassic. Tengo intención de cambiar el motor pero todavía estoy en fase de pruebas.
Por cierto se me olvidó en el anterior, los discos en el cliente no sé si son dinámicos o fijos, de eso no me encargo, se lo preguntaré. Lo que sí está es un disco separado para los temporales del firebird. Un saludo |
Tanto en clientes como en servidor debe estar la misma versión de firebird, no los mezcles.
|
Hola, y así es, en todos está el fb 2.1.4
|
Bueno, esa tabla artal podrias manejarla como una vista y te evitas el problema de estar insertando esa millonada de registros. Creo que si revisamos detenidamente el diseño de la base de datos podriamos darle otra soución a tu situación.
|
bueno, algo que yo he notado en Widows es que cuando hay varios procesadores es mejor trabajar con ClasicServer que con SuperServer, y mejor aun SuperClassic, pero sí solo hay un procesador es mejor trabajar con SuperServer, la aplicación que más me ocupa, tiene un nivel de instalación bastante alta al mes, cuando se instala en un multinucleo un SuperServer suele bloquearse en tareas que demanden mucho al procesador
|
Hola, la tabla artal es necesaria, hay campos que se actualizan en diferentes trigger's de la BD. No veo como convertirla en vista.
Voy a probar el superclassic en mi Win7 vBox a ver qué me encuentro. Otra curiosidad, al probar los cambios de tamaño de página (backup/restore) resulta que depués de ese proceso la resuelve rapidísimo. Es decir, inicio el sistema, hago un backup/restore sin tocar nada, ejecuto la consulta y la resuelve en 3 segundos. Cada vez apunta más a caché, ¿qué opináis?, ¿cada BD tiene su propia caché o es el firebird el que mantiene una única (hablando en superServer)? Un saludo. |
Cita:
|
Hola Casimiro
Cita:
un saludo. |
Compartenos los metadatos de las tablas importantes de tu base de datos para entender un poco mas la situacion. De acuerdo con Casimiro que tampoco he necesitado en mas o menos los mismos años modificar la configuracón por defecto del motor de base de datos Firebird, el aumento de cache lo que permite es que parte de la base de datos queda en la memoria RAM aumentando la velocidad en la manipulacion y consulta de datos y su uso es para casos muy especiales, tal vez el tuyo.
|
Cita:
|
Cita:
El porque la 1era vez es lento y luego rapido me parece obvio. Al principio la tabla de destino esta "vacia", luega la llenas, luego al repetir ya esta llena y solo copia los registros faltantes. El filtro de la consulta hace todo rapido. Lo que no entiendo, es porque hay que preocuparse al siguiente dia por esto. Siempre la tabla de destino esta "vacia" al arrancar??? |
Hola
Cita:
Tuve un profe en EGB que nunca ponía un 10, decía que siempre hay más caminos y que seguro que hay otro mejor. El producto cartesiano que tanto nos preocupa no es el problema, ese producto, incluso sin condiciones que filtren las tablas, lo resuelve en milisegundos (con fetch all). Por cierto lo probé en un FB2.5.2 64bits en modo superClassic y... lo mismo. Sigo con que es problema de caché, ¿de Windows?, :confused:. Casimiro, estoy contigo, posiblemente en un Linux "pelao" la cosa cambie, de hecho lo probaré por curiosidad. Un saludo y no me harto de agradeceros vuestro interés, muchas gracias |
Cita:
|
Hola, así es, en el momento que hago un backup/restore o ejecuto una vez la consulta va como la seda.
Mi última prueba va a ser con un OpenSUSE y salga lo que salga ahí terminaré. Os cuento resultados. un saludo. |
Podrias darnos el plan de ejecucion? Cuando mencionas que el producto cartesiano se resuelve rapido, has identificado EXACTAMENTE en que paso esta la demora? El comando EXPLAIN podria dar una luz...
Lo ultimo que se me ocurre es eliminar los indices y triggers antes de la insercion y reagregarlos al final. Tambien, meter los datos en una tabla temporal y de alli traspasarlos. Pero quizas debes analizar esta presentacion sobre desempeño: http://www.slideshare.net/ibsurgeon/...mance-problems |
Cita:
Creo que este tema me va a ser de lo más valioso, ya que tengo una aplicación que presenta una situación muy parecida a la de ARPE1. En mi caso es Windows XP + Firebird 1.5 + Delphi 7 + DBX con el controlador de InterBase (que hasta esa versión de Firebird sí es compatible, según entiendo). El archivo .fdb ocupa unos 535 MB, hago uso adecuado de los índices y pasa lo mismo: con ciertas y muy particulares consultas, la primera vez que las realizo se demora un par de minutos, mientras que haciéndola de nuevo resultan instantáneas. Esto pasa incluso habiendo ya hecho otras consultas y actualizaciones en la base de datos (la conexión puede tener ya varias horas de vida y uso antes de hacer esa primera consulta extrañamente lentificada, o puede ser en cuanto se abre dicha conexión). El problema no ocurre si hago lo mismo desde IBExpert (ahí siempre es rápido) o bien en red. Es decir, sólo pasa cuando ejecuto la aplicación conectándome a la base de datos localmente (misma PC para cliente y servidor). Con IBExpert, ya sea remoto o local, anda rapidísima la consulta. Ya comprobé que la demora no ocurre en el código Delphi. Sino en la llamada que finalmente hace este código a Firebird. ¿Debería pensar en cambiar el controlador DBX InterBase? :o Extraños saludos. |
Cita:
Cita:
|
Hola
Cita:
Código SQL
Aunque veamos ALMAC NATURAL , no preocupa sólo tiene 40 registros y los lee una vez (analizado con IBExpert). Cita:
Cita:
un saludo y gracias. |
Cita:
Un saludo. |
Hola de nuevo, más resultados.
iSQL de firebird (por evitar herramientas de terceros): 1. 1ª vez esos 6 minutos 2. siguientes >>> 3 segundos FDB copiada, tal cual, sobre un SSD. 1. 1ª vez ¡¡¡¡¡ 17 segundos !!!!! 2. siguientes >>> 3 segundos Es curioso, los archivos temporales de FB los tengo redirigidos sobre un mecánico (TempDirectories = G:\FBTemp). Lo único que he hecho ha sido mover el FDB a un SSD. De aquí casi se puede sacar que la caché ¿la guarda en el mismo FBD?. Una pasada el rendimiento, creo que es una buena inversión para los clientes, aunque sea uno pequeño para almacenar sólo el FDB. Y otras cosillas, al tocar lso tamaños de página se reduce algo el tiempo (a más tamaño menos tiempo, al menos en esta consulta). Tampoco para tirar cohetes. Un saludo y os seguiré contando PD. Creo que a estas alturas deberíamos olvidarnos de la consulta SQL y tratar temas de caché, memoria, firebird.conf... es decir de las configuraciones de los sistemas. Voy por SUSE a ver qué me cuenta. |
IBO es buenecito, aunque IBX y FIBplus son algo más rápidos.
Alguna vez leí o escuché que ibexpert usa, o usaba, IBO. Un par de cosas, ese disco G: es una partición del mismo o es otro disco físico. Debería ser otro disco para mejorar. Si es una partición del mismo entonces estamos en las mismas, no sirve de mucho, más bien de nada. Otra cosa, por probar que no quede, mira de cambiar not exists por not in |
Hola
Cita:
Cita:
un saludo |
Hola
Cita:
Un saludo. |
Cita:
Y por favor, usa el mismo dato para hacer evaluaciones y medidas, si cambias los querys cada vez pues como se puede determinar exactamente la causa? Lo ultimo se me ocurre, es que el disco este fragmentado, o que las estadisticas de los indices esten desincronizadas. El que vuele con SSD muestra en parte eso (los SSD no se fragmentan, y tienen IO superveloz). Es claro, desde mi punto de vista, que FB esta leyendo datos del disco y no desde los indices (en memoria). La 2da vez es rapido porque tiene los planes, indices, etc precalculados y las estadisticas corregidas... |
Ya sé que no va a ser posible, pero no estaría mal tener una copia de la BD para probar :)
|
Hola
Cita:
Código SQL [-]Select artic.artic, almac.cod as almac from artic, almac where artic.activo = 'S' and artic.filtro = 'MP' and not exists ( Select artal.artic from artal where artal.artic = artic.artic and artal.almac = almac.cod) Todas las pruebas que os voy poniendo están hechas con la consulta anterior (pensando en un "insert into" en lugar de un "merge"). La tabla "almac" es una auxiliar de código/descripción con clave primaria por código, si no usa ese índice es porque no hay condiciones para el uso y porque necesita todos los registros (en eso consiste la consulta: los artículos seleccionados en todos los almacenes). Cita:
Por cierto no sé a qué te refieres con los tiempos, la consulta la ejecuté con iSQL calculando sólo el plan (Set planonly on). un saludo y gracias por el interés |
Hola
Cita:
Me gustaría poder compartir más a fondo el problema y las pruebas, pero sabéis que no se puede, si fueran míos los datos pues sí, no habría problema en haceros llegar una copia (¡¡¡de casi 3GB!!!). LOPD, LOPD, LOPD. Con un cantito en los dientes que se me permita tenerla a mi, ¡¡¡menos mal!!!. No sé si podría generar un FDB con las tres tablas implicadas y datos aleatorios hasta llegar al volumen que tienen ellos, y si es así si nos encontraríamos con el mismo problema. Lo estudiaré, de momento me he dado cuenta que tengo el unix muuuuuy olvidado y no soy capaz de echar a andar el fbserver en suse. Un saludo y os sigo poniendo resultados. |
La franja horaria es GMT +2. Ahora son las 10:05:39. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi