FireBird Frezee!!!

ELINK · #1 28-10-2005

No se Porque sucede, pero en muy pocas ocaciones el servidor del Firebird se congela, todas las estaciones colapsan, cuando voy al server veo el proceso del fbguard a 100 por hora, cosumiendome todos los recursos del sistema!!!
solo me quedaba reiniciar el server.

Mis preguntas son:
como puedo hacer para solucionar este problema???
como puedo saber cual fue la accion o la instruccion que desató este problema???
como puedo hacer para que el server por si solo pueda solucionar este problema???

No se si pido mucho...

, ojala puedan ayudarme

Casimiro Notevi · #2 29-10-2005

Creo, que en principio, deberías de hacer un seguimiento, preguntando a los usuarios qué estaban haciendo en ese momento.

Te toca hacer de detective

ELINK · #3 29-10-2005

Cita:

Empezado por Casimiro Notevi

Creo, que en principio, deberías de hacer un seguimiento, preguntando a los usuarios qué estaban haciendo en ese momento.

Te toca hacer de detective

jeje
Si Casimiro Notevi, ya les pregunte y revise el codigo, en las partes que me mencionaron(todo esta bien), y es que el problema ocurre muy raras veces(todos los modulos del programa son de uso diario), en estos cuatro años que tengo con firebird a ocurrido unas tres veces

(pero en esas tres veces a todos se nos bajo la presion por el susto

)

hay alguna manera de que el servidor me dea alguna especie de imforme del error???(ya que cuando ocurre el problema "solo" se cuelga el server, pero no da ningun error)

Casimiro Notevi · #4 29-10-2005

Normálmente, cuando sucede un error, siempre da un mensaje. En tu caso ¿qué ocurre exactamente?... es que con tan pocas pistas que das es "casi imposible" dar una respuesta adecuada

Ni siquiera has dicho qué es lo que te comentaron los usuarios, qué sistema usas, el servidor es windows o linux, son muchos usuarios, qué se hace exactamente en el servidor... muchas consultas pequeñas, pocas grandes, ... el servidor hace únicamente de servidor de interbase o hace más cosas?, si hace más cosas, cuáles son que puedan interferir en el sistema, si es un windows, no tendrás ningún virus, troyano, spyware, etc...

Que el servidor se "congele", personalmente nunca lo he vivido/sufrido, exactamente qué quieres decir con "congele", que se vuelve muy lento, que se detiene, que se "quita" de memoria?, si el "guardián" está trabajando a tope, como dices, seguramente es que está intentando poner en marcha el server y hay algún proceso que lo vuelve a cerrar y éste vuelve a intentar abrirlo... es el mejor momento para ver qué están haciendo los usuarios y buscar al culpable porque eso de que: "ya les pregunte y revise el codigo, en las partes que me mencionaron(todo esta bien)" está claro que no es así, siempre que algo falla es porque hay algún error aunque no lo hayamos podido detectar.

En fin, que no estoy contándote nada que no sepas, tan sólo te queda explicar muy detalladamente todo el entorno de trabajo para que te podamos ayudar o personarnos ahí y echarte una mano

en el buen sentido de la palabra.

Saluditos.

vtdeleon · #5 29-10-2005

Saludos

Como dice Casimiro, con los pocos datos que has ofrecido, tiraré unos tiros al aire

: Lo usuarios(la mayoria de veces) dan repuestas un poco vagas y no claras cuando ocurre un problema.
Como es en el servidor que ocurre el "congelamiento", podría ser algun "trigger" o "store procedure"

Solo me queda decir que avises a todos los usuarios de sistema que cuando suceda lo mismo no hagan nada (cerrar aplicacion, dar click en todos lados, puyar a ver que sucede) y asi chequeas en que modulos estan cada uno; chequeas el código, tanto en delphi con en el servidor firebird.

ELINK · #6 29-10-2005

Tienen Razon en Todo lo Que dicen: (toda concecuencia tiene una causa)

Es Un error que a mi tambien me deja perplejo

voy a tratar de responder todas sus preguntas:

qué es lo que te comentaron los usuarios???
que "de un momento a otro el programa se puso blanco y no se podia hacer nada" (programa en blanco= evidentemente el programa estaba tratardo de comunicarse con el server y consumia los recursos del cliente)

el servidor es windows o linux???
Actualmente Linux, Tambien estubo en windows, y ocurrio el mismo error un par de veces

son muchos usuarios???
nop, son solo 5.

qué se hace exactamente en el servidor???
Al ver lo que pasaba en las estaciones fui al server a ver que pasaba; no hubo ningun problema con linux, al ver los procesos vi que el fbguard consumia casi todos los recursos y cuando trataba de ingresas a traves de consola a la base de datos desde el server, simplemente no pasaba nada, yo daba la instruccion y luego no pasaba nada, no habia respuesta.

muchas consultas pequeñas, pocas grandes???
depende lo que signifique grande o pequeño para ti

las son pequeñas, la mayoria son insert y update

el servidor hace únicamente de servidor de interbase o hace más cosas???
El Servidor tiene el lujo de se solo para firebird,son 3 db con un total de 30 Mb de tamaño

exactamente qué quieres decir con "congele", que se vuelve muy lento, que se detiene, que se "quita" de memoria???

Se detiene.

Como es en el servidor que ocurre el "congelamiento", podría ser algun "trigger" o "store procedure"???
no hay store procedure, pero si trigger, los revice todos, y ninguno genera un loop infinito

*Solo me queda decir que avises a todos los usuarios de sistema que cuando suceda lo mismo no hagan nada (cerrar aplicacion, dar click en todos lados, puyar a ver que sucede) y asi chequeas en que modulos estan cada uno; chequeas el código, tanto en delphi con en el servidor firebird.

Gracias. ya lo hice, pero para la proxima tomaré mas atención y sere mas acucioso en hacer las preguntas a los users.

Espero puedan ayudarme a resolver este problema

lpmlpm · #7 29-10-2005

Otros tiros al aire:
Que libreria de conexión usas??? si dices que cambiando de servidor te dio problemas puedes pensar que tus aplicaciones cliente ponen a hacer "algo" al servidor... me sucede algunas veces con PHP por ejemplo cuando hago alguna cosa muy rara con punteros y eso, y es debido a como la dll de PHP tiene la comunicación con el servidor...

Otra cosa que puede suceder es que estas ejecutando una consulta que le pide mucho al servidor, igual y armas una consulta dinamicamente que le esta pidiendo mucho al servidor, no se una que regrese cientos de miles de registros, y si no tienes una libreria de conexión que use sesiones persistentes tus clientes le estan pidiendo al server que les "traiga pa ca" todos y cada uno de esos registros de un solo golpe, lo que forza al motor a que tiene que resolver toda la consulta de una sola vez y por eso se pone bien talachero en ese momento...

Espero te sirva...

ELINK · #8 29-10-2005

Cita:

Empezado por lpmlpm

Otros tiros al aire:
Que libreria de conexión usas??? si dices que cambiando de servidor te dio problemas puedes pensar que tus aplicaciones cliente ponen a hacer "algo" al servidor... me sucede algunas veces con PHP por ejemplo cuando hago alguna cosa muy rara con punteros y eso, y es debido a como la dll de PHP tiene la comunicación con el servidor...

Otra cosa que puede suceder es que estas ejecutando una consulta que le pide mucho al servidor, igual y armas una consulta dinamicamente que le esta pidiendo mucho al servidor, no se una que regrese cientos de miles de registros, y si no tienes una libreria de conexión que use sesiones persistentes tus clientes le estan pidiendo al server que les "traiga pa ca" todos y cada uno de esos registros de un solo golpe, lo que forza al motor a que tiene que resolver toda la consulta de una sola vez y por eso se pone bien talachero en ese momento...

Espero te sirva...

no men, en la tabla mas grande del server solo tiene como maximo 10 mil registros, por eso no creo que el problema venga por hay, sin envargo puede ser por el driver odbc es el que da el mismo firebird...

brandolin · #9 29-10-2005

A mi me ha pasado que armando alguna sentencia select con dos o mas tablas o bien con alguna tabla join la misma al estar mal armada la consulta se generaba un chache enorme por lo que se consumia todo el server. Tendrias que validar las consultas en el momento que sucede que se cuelga el server.
Espero que te sirva.

vtdeleon · #10 29-10-2005

Saludos

Cita:

Empezado por ELINK

...sin envargo puede ser por el driver odbc es el que da el mismo firebird...

ODBC???, Qué componentes usas???? Lo mejor para bases de datos Firebird es usar los componentes IBX o MODlib (aún no los he utilizado)

AMO · #11 29-10-2005

Saludos

Me ha pasado algo similar en varias ocasiones. En mi caso ya lo detecte y se debe al sweep que realiza la base de datos cada cierto numero de transacciones. En mi caso (windows 2000) se consume el 100 % de procesador y no responde nada, sin embargo no se bloquea. Al dejarla un tiempo bastante largo todo vuelve a la normalidad.

Tambien he logrado desencadenar este problema al realizar el backup de la base de datos, el cual tarda demasiado en concluir.

El problema se ha solucionado manteniendo la politica de backup y restore de manera periodica.

Casimiro Notevi · #12 29-10-2005

Desde luego que en tu caso te aconsejo que si puedes cambies odbc por ibx, fibplus, ibobjects, etc

Al haberse repetido el problema tanto con servidor windows como linux quiere decir que no es culpa de interbase sino del programa o de algún trigger de los que comentas que tienes.

También, como te han comentado antes, te aconsejaría que pongas sweep a cero y hagas backup/restore muy a menudo, que además en tu caso, al ser la base de datos pequeñita lo haría en un momento y siempre la dejarías "a punto" para empezar a trabajar.

Si quieres, bájate este .rar con alguna documentación sobre consejos a tener en cuenta a la hora de usar interbase/firebird: Aquí lo tienes.

Y ya nos contarás cómo te va.

Saluditos.

ELINK · #13 29-10-2005

Muchas Gracias Por su Apoyo.
voy a probar cada una de sus recomendaciones y especial mente lo del sweep, backup y restore

GRACIAS

jachguate · #14 29-10-2005

Hola.

Entre todo lo hablado, creo que se ha mantenido cierta ambiguedad en un asunto muy importante.

No es lo mismo que un proceso muera a que un proceso esté archi-super ocupado haciendo una tarea útil o que un proceso esté igualmente ocupado haciendo algo inutil (un ciclo infinito, por ejemplo).

En este caso, evidentemente, el proceso está muy ocupado para atender a los clientes; a todos los clientes por lo que puede entenderse, así que es muy lógica la sospecha del sweep. No has dicho por cuanto tiempo has esperado antes de matar los procesos en el servidor, pero tengo la impresión que no has esperado mucho, pues un sweep sobre bases de datos de 30 Mb. se harán bastante rápido.

Por defecto, el sweep se realiza durante los backups, y durante los select's cada 20,000 operaciones. Para descartar esta posibilidad podes cambiar la frecuencia del sweep o desactivarlo totalmente.

enlace

Otro punto importante que no se ha mencionado es la arquitectura del servidor: Classic Server o SuperServer?

Si es un cliente el que está originando el problema, podrias aislarlo usando el Super Server en lugar de un Classic Server. Es otra opción que tenes que considerar y que puede llevar tus tareas detectivezcas a buen puerto.

Saludos.

ELINK · #15 29-10-2005

Cita:

Empezado por jachguate

Hola.

Entre todo lo hablado, creo que se ha mantenido cierta ambiguedad en un asunto muy importante.

No es lo mismo que un proceso muera a que un proceso esté archi-super ocupado haciendo una tarea útil o que un proceso esté igualmente ocupado haciendo algo inutil (un ciclo infinito, por ejemplo).

En este caso, evidentemente, el proceso está muy ocupado para atender a los clientes; a todos los clientes por lo que puede entenderse, así que es muy lógica la sospecha del sweep. No has dicho por cuanto tiempo has esperado antes de matar los procesos en el servidor, pero tengo la impresión que no has esperado mucho, pues un sweep sobre bases de datos de 30 Mb. se harán bastante rápido.

Por defecto, el sweep se realiza durante los backups, y durante los select's cada 20,000 operaciones. Para descartar esta posibilidad podes cambiar la frecuencia del sweep o desactivarlo totalmente.

enlace

Otro punto importante que no se ha mencionado es la arquitectura del servidor: Classic Server o SuperServer?

Si es un cliente el que está originando el problema, podrias aislarlo usando el Super Server en lugar de un Classic Server. Es otra opción que tenes que considerar y que puede llevar tus tareas detectivezcas a buen puerto.

Saludos.

Gracias por la ayuda:
Bueno la Verdad no espere muuuucho, solo unos 5 a 7 min. luego lo maté
Y la arquitecrura es SUPER SERVER, lo cual me deja mas perplejo con respecto al problema, ya que no deberia caerse todo (creo,verdad?)

Casimiro Notevi · #16 29-10-2005

Una pregunta, creo que has dicho que el "guardián" estaba a tope, pero ¿el "server" estaba funcionando o ni siquiera estaba cargado en memoria?, es que si no estaba es porque ha ocurrido algún error grave provocado por alguna consulta "mal hecha" que ha provocado que desaparezca... y es entonces cuando el "guardián" se pone en marcha para lanzarlo.

O sea, la pregunta es: fbguard y fbserver, ¿estaba fbserver en el momento en que fbguard estaba a tope?

ELINK · #17 29-10-2005

Cita:

Empezado por Casimiro Notevi

Una pregunta, creo que has dicho que el "guardián" estaba a tope, pero ¿el "server" estaba funcionando o ni siquiera estaba cargado en memoria?, es que si no estaba es porque ha ocurrido algún error grave provocado por alguna consulta "mal hecha" que ha provocado que desaparezca... y es entonces cuando el "guardián" se pone en marcha para lanzarlo.

O sea, la pregunta es: fbguard y fbserver, ¿estaba fbserver en el momento en que fbguard estaba a tope?

No lo Recuerdo bien, pero estoy casi seguro q si estaba, he incluso,estaba varias posiciones mas abajo, osea que consumia menos recursos que otras aplicaciones propias de linux.

y cuando te refieres ha:

Cita:

Empezado por Casimiro Notevi

ha ocurrido algún error grave provocado por alguna consulta "mal hecha" que ha provocado que desaparezca...

es posible eso??? porque siempre (creo) que hay una consulta mal hecha a error, en todo caso podrias ampliarme mas informacion con respecto a ese tipo de errores, ya que tal vez ese sea mi problemas

otra vez, Gracias por su ayuda (a Todos

)

Casimiro Notevi · #18 29-10-2005

Cita:

Empezado por ELINK

... y cuando te refieres ha:
es posible eso??? porque siempre (creo) que hay una consulta mal hecha a error, en todo caso podrias ampliarme mas informacion con respecto a ese tipo de errores, ya que tal vez ese sea mi problemas) ...

Me he encontrado casos de consultas aparentemente correctas que según qué circunstancias provocaban la caida total del fbserver, han sido dos o tres en casi 8 años, y siempre han sido detectadas en las pruebas previas antes de incluirlas en las versiones definitivas para los clientes, así que no hubo problema. Pero pueden ocurrir, sí, muy difícil, pero puede.