Porque el Proceso fb_smp_server muestra un consumo alto

[subzero]

Hola a todos. Buenos hace mucho tiempo estoy trabajando con firebird, tengo un proyecto que inicie hace ya algunos años y del cual en algunos momentos he acudido al foro para obtener una respuesta o una luz a algunos inconvenientes presentados, pues bien, actualmente tengo un servidor virtual 4 cores, 4 gigas en RAM, 50 DD, ubuntu 12.04, firebird 2.5 classicserver y apache.. el caso es que últimamente el consumo del la cpu esta entre 70% y el 90% de forma general pero si lo miro por proceso fb_smp_server el uso de la cpu muestra un consumo de 370% en promedio. Alguien sabe a que se debe esto o que debo mirar....

Les agradezco cualquier idea.

[Casimiro Notevi]

Hola, imposible ayudarte con los datos que has dado

[[duilioisola]]

Básicamente, lo único que se deduce de lo que has presentado es que FB es quien está consumiendo los recursos del servidor.
Habría que ver qué es lo que se está ejecutando en esa base de datos.
* INSERTs/UPDATEs/DELETEs
* Ejecución de un SP
* SELECTs

Deberías mirar que es lo que ejecutan los triggers/sp.
Por ejemplo un select buscando el MAX(campo) de una taba con millones de registros sin utilizar índices o utilizando índices inadecuados. Esto se solucionaría agregando un índice descendiente sobre el campo que deseas.
También puede ser que un trigger haga operaciones sobre otras tablas, que a su vez hacen operaciones sobre otra tabla, que a su vez...
Si ves que se trata de SELECT complejo (con JOIN/UNION/GROUP BY, etc.) deberías ejecutarlo y ver qué PLAN está utilizando (qué índices y si son óptimos). Seguramente se puede optimizar.

Además de esto, podría ver cómo está tu base de datos mediante un GSTAT -h.
Mira la diferencia de transacciones entre la última activa y la reciente. Si la diferencia es más de 20.000 deberías mirar qué es lo que bloquea el commit de las trasnacciones.

C:\>"C:\Program Files\Firebird\Firebird_2_5\bin\"gstat.exe -h C:\Datos\BASE_DE_DATOS.FDB -user SYSDBA -pass masterkey

Database "C:\Datos\BASE_DE_DATOS.FDB"
Database header page information:
Flags 0
Checksum 12345
Generation 148371
Page size 8192
ODS version 11.2
Oldest transaction 143954
Oldest active 143955
Oldest snapshot 143621
Next transaction 148358
Bumped transaction 1
Sequence number 0
Next attachment ID 166
Implementation ID 26
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 1
Creation date Dec 9, 2014 10:00:10

Variable header data:
Sweep interval: 0
*END*

[subzero]

duilioisola, muchas gracias. Efectivamente es una consulta que obviamente estaba generando el problema del consumo ya bajo algo pero aun sigue sobre 300%... conoces de alguna herramienta parecida al monitor de sql server que monitore las consultas algo como el administrador de consultas.... esto a razón que no es una sola base de datos sino varias.... Nuevamente muchas gracias.

[[duilioisola]]

Existen herramientas que se meten entre la base de datos y el cliente para revisar el tráfico de consultas.
Ya que trabajas con FB2.5, puedes probar leyendo la tabla MON$STATEMENTS.
En el campo MON$SQL_TEXT encontrarás la sentencia SQL que las conexiones activas han ejecutado en las transacciones activas.
Una vez que la transacción se termina, se elimina de esta tabla.

Podrías hacer POLLING de esta tabla. (es gratis y quizás descubras algo interesante)

ULTIMO_STATEMENT_ID = 0
WHILE () DO
BEGIN
   SELECT MON$STATEMENT_ID, MON$SQL_TEXT FROM MON$STATEMENS WHERE MON$STATEMENT_ID > :ULTIMO_STATEMENT_ID
   Guardas estos datos en un log
   ULTIMO_STATEMENT_ID = MON$STATEMENT_ID
   Esperas un tiempo (1 segundo por ejemplo)
END