![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
|||
|
|||
|
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 ?
__________________
Luis Fernando Buelvas T. |
|
#2
|
|||
|
|||
|
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 |
|
#3
|
||||
|
||||
|
¿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.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#4
|
|||
|
|||
|
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 |
|
#5
|
||||
|
||||
|
o también puede usar SuperClassic, el cual si permite manejar bien los nucleos y manejar muy bien excepciones de Firebird
__________________
"Como pasa el tiempo..... ayer se escribe sin H y hoy con H" |
|
#6
|
|||
|
|||
|
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 |
|
#7
|
||||
|
||||
|
Tanto en clientes como en servidor debe estar la misma versión de firebird, no los mezcles.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#8
|
|||
|
|||
|
Hola, y así es, en todos está el fb 2.1.4
|
|
#9
|
||||
|
||||
|
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
__________________
"Como pasa el tiempo..... ayer se escribe sin H y hoy con H" |
|
#10
|
|||
|
|||
|
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.
__________________
Luis Fernando Buelvas T. |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| aplicación lenta | Celta | Varios | 2 | 13-01-2012 13:42:19 |
| Conexion Con Interbase/FireBIrd lenta...muy lenta | federiconqn21 | Firebird e Interbase | 3 | 11-03-2010 13:13:34 |
| Aplicacion lenta | aanil | OOP | 4 | 26-01-2010 15:11:39 |
| Ayuda con consulta lenta, lenta, lenta | Gregory Mazon | Firebird e Interbase | 22 | 27-06-2007 09:56:38 |
| Impresion lenta, muy lenta... | Perio | Impresión | 2 | 20-05-2005 13:10:00 |
|