Servidor linux con CPU al 100%
 

Hola
Tengo un servidor linux ejecutando firebird 1.5.6 SS . He revisado los parámetros del fichero firebird.conf para optimizar el DefaultDBCahePage a 10240 para tomar algunas páginas más de las 2048 por que trae por defecto.

El tema es que el servidor al ejecutar determinadas consultas se pone al 100% y deja al resto de los equipos inoperativos.
He revisado dichas consultas y están optimizadas. De hecho los analizadores marcan que todas las consultas se realizan mediante índices.
En cualquier caso, con independencia de que la consulta tarde más o menos, lo que no entiendo es porque se quedan bloqueados el resto de los equipos, poniéndose el servidor al 100% de la cpu. ¿No debería ir más lento pero no bloquearse?
La cuestión es que me pasa en servidores diferentes así que pienso que es un problema del Firebird. He buscado el error en ibphoenix pero no he conseguido solucionarlo con las indicaciones: http://www.firebirdfaq.org/faq312/
ya que la instrucción que ejecuto es un select con joins entre tablas.

La consulta que ejecuto desde el IBExpers:
El plan que me propone son todas las consultas indexadas:
PLAN SORT (SORT (JOIN (CABALBCLI INDEX (FK_CALCLI_TIPOPE,IDX_CALCLI_FECHA),LINALBCLI INDEX (FL_LINALBCLI_ENLACEFAB,FK_LALCLI_CALCLI),ARTIFABR INDEX (PK_ARTIFABR),ARTICULOS INDEX (PK_ARTICULOS),MULTIPUNTOSVENTA INDEX (FK_MULPTOVTA_SERPTOVTA,PK_MULTIPUNTOSVENTA))))

No sé que más puedo mirar.
Gracias.

Hola, es "casi" imposible que podamos ayudarte si no tenemos el servidor delante y la base de datos para hacer pruebas, de todas formas puedes "trocear" ese sql para encontrar qué tabla/campo es el que está tardando.
También puedes hacer otro cambio, ya que es linux, instala la versión classic server, es más recomendable.

También puedes tratar de hacer el mismo select pero utilizando JOINs

Código SQL [-]
select c.ncentro, l.carticulo, l.ncod_albaran, l.ccod_serie,
l.ncod_orden,c.npuntoventa, c.ncliente, c.dfecha, 
l.ncantidad1, l.ncantidad2, l.ncantidadvalor, c.ntipoop
from cabalbcli c
left join linalbcli l
on c.ncod_albaran = l.ncod_albaran and c.ccod_serie = l.ccod_serie
/* linalbcli deberia tener un indice por ncod_albaran,ccod_serie */
left join articulos a
on l.carticulo = a.ccod_articulo
/* articulos deberia tener un indice por ccod_articulo */
left join artifabr af
on af.ccod_articulo=a.ccod_articulo
/* artifabr deberia tener un indice por ccod_articulo */
left join multipuntosventa m
on m.ncod_puntoventa=c.npuntoventa  
/* multipuntosventa deberia tener un indice por ncodpuntosventa */
where
 and c.lfacturable=0
 and c.ntipoop=2
 and (c.dfecha >= '10/01/10' and c.dfecha <= '10/31/10')
 and l.lenvase=0
 and l.ncantidadvalor < 0
 and (l.ctipolinea='V' or l.ctipolinea='P' or l.ctipolinea='R')
 and l.nenlacefab is null
 and af.ncod_fabricante = 1
 and af.lprincipal=1 m.ncod_fabricante=1
 and af.csureferencia is not null
 and m.nptovtaserv is null
 order by l.carticulo, l.ncod_orden, l.ccod_serie, l.ncod_albaran
 
/* por el where que utilizas :
   CABALBCLI deberia tener un indice por lfacturable, ntipoop, dfecha
*/

Notas:
He utilizado alias (cabalbcli c, por ejemplo) para que el sql sea más legible

Presta especial atención a los índices que te marco, pues son los que utilizará para tratar de unir una tabla con otra.

Dato que utilizas "and campo is null" entiendo que quieres que te aparezcan registros en los que la tabla asociada no tiene registros. Por eso he utilizado LEFT JOIN.

Veo además que utilizas Firebird 1.5.6 SS.
Yo utilizo la misma versión, pero en modalidad CS.

Esto tiene para mi dos ventajas:
Cada conexión es un proceso distinto, por lo que linux reparte la CP entre procesos y siempre está balanceado.
Si un proceso está al 100% puedes entrar al linux, buscar ese proceso y matarlo!

Yo hago un top, presiono la letra [k] y le doy el número de proceso

Hola.

Lo primero que te recomiendo es que utilices Joins explícitos, como te recomienda el compañero. Facilita mucho la comprensión de la consulta, y por tanto la optimización de la misma.

Respecto a los índices, el hecho de que la consulta utilice índices para todas las tablas no quiere decir que esos índices sean óptimos. Está claro que en alguna tabla se podría crear una índice que agilizaría mucho más la consulta de lo que hacen los índices actuales.

En todo caso, ante una consulta tan sencilla. Puedes simplemente ir por partes.

Empieza por :

Código SQL [-]
select cabalbcli.ncentro
from cabalbcli
where cabalbcli.lfacturable=0  and cabalbcli.ntipoop=2 and
        (cabalbcli.dfecha >= '10/01/10' and cabalbcli.dfecha <= '10/31/10')

Y después le vas añadiendo una a una las tablas relacionadas.

Código SQL [-]
select cabalbcli.ncentro
from cabalbcli
        inner join linalbcli on  cabalbcli.ncod_albaran = linalbcli.ncod_albaran and cabalbcli.ccod_serie = linalbcli.ccod_serie
where cabalbcli.lfacturable=0  and cabalbcli.ntipoop=2 and
        (cabalbcli.dfecha >= '10/01/10' and cabalbcli.dfecha <= '10/31/10') and
        linalbcli.lenvase=0 and linalbcli.ncantidadvalor < 0  and 
        (linalbcli.ctipolinea='V' or linalbcli.ctipolinea='P' or linalbcli.ctipolinea='R') and
        linalbcli.nenlacefab is null

Cuando la consulta se bloquee, ya sabes en que unión tienes que añadir un índice que permita localizar rapidamente sus registros.

Hola.
Gracias a todos. Habéis acertado con la solución al 100%.
Me puse a fraccionar e investigar la SQL con detalle hasta que di con el problema. El join con artifabr era la causa del problema.
Esta table tiene un clave primaria por cod_articulo y cod_fabricante, pero adicionalmente tiene una clave referencia en cod_fabricante a la tabla de FABRICANTES.
El problema es que el plan que utiliza firebird toma como índice de búsqueda para artifabr la clave referencial por fabricante, en lugar de tomar la clave primaria con artículo y fabricante PLAN ... ARTIFABR INDEX (FK_ARTFAB_FABRIC)
y aunque yo le indico que tome ARTIFABR INDEX (PK_ARTIFABR), no lo hace y da error ( ahora que me doy cuenta puse mal el plan que sale en el post inicial).
Al cambiar la consulta a left joins, ahora si está tomando el índice correcto y la consulta ha pasado de tardar 352 segundos a tardar 16 milisegundos (si lo he escrito bien de 5 minutos a menos de un 1 segundo). Increible pero cierto...

De todas formas, con independencia de la consulta SQL. Lo que sigo sin entender es por qué Firebird pone la CPU al 100% y deja a los demás equipos tirados. ¿No debería compartir la carga de trabajo con los otros equipos y simplemente hacer que tarde un poco más la consulta lenta?
Gracias por la magnifica ayuda prestada por todos.

La solución te la hemos dado antes, instala la versión classic server.

Resp
 

Primero te recoiendo que uses la version clsi server ya que la superserver en linux segun mi punto de vista le estas poniendo hacer un trbajo que de por si el sitem aoperativo lo hace solo que es manear los hilos. y segundo deberias por lo menos decirnos las estructuras de las tablas. Quisas te falte algun indice o algo por estilo.

Hola. Gracias por las respuestas.
La verdad es que la decisión de instalar una u otra versión se basa en esta documentación:
http://www.firebirdsql.org/manual/es/qsg15-es-classic-or-super.html

Para linux, dice que da igual cual elija que no habrá diferencia de rendimiento, así que opté por la solución que parece ser la que se va a desarrollar, o sea la superserver. De todas formas haré lo que decís y lo pasaré a la versión classic server a ver si así va mejor.
Un saludo.

Cierto, pero la experiencia dice que no es así, instala la classic, verás la diferencia.
Y si el servidor tiene más de un micro o es dual, entonces notarás una diferencia muy muy significativa.

Hola.
En el caso de un servidor monoprocesador, ¿crees que también se notará mucho el rendimiento? Supongo que en ese caso seguirá prácticamente igual ¿no?.
De todas formas gracias de nuevo a todos por la ayuda.

Al menos ganarás en esto, puede que sí notes la diferencia.