Servidor linux con CPU al 100%

[[duilioisola]]

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

top - 15:28:50 up 32 days, 20:59,  3 users,  load average: 0.30, 0.14, 0.15
Tasks: 125 total,   2 running, 123 sleeping,   0 stopped,   0 zombie
Cpu(s): 43.6%us,  5.9%sy,  0.0%ni, 48.8%id,  1.7%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1033244k total,  1017480k used,    15764k free,    16664k buffers
Swap:  2031608k total,       96k used,  2031512k free,   697860k cached
PID to kill:
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7482 firebird  20   0 69160  64m 3064 S    0  6.4   5:17.67 fb_inet_server
 7943 firebird  20   0 61176  56m 3040 S    0  5.6   3:53.82 fb_inet_server
 8095 firebird  20   0 54144  49m 3060 S    0  4.9   2:41.63 fb_inet_server
 2355 gdm       20   0 85180  25m  11m S    0  2.6  15:23.83 gdmgreeter
 8494 firebird  20   0 24640  20m 2872 R   99  2.1   0:11.79 fb_inet_server
 7671 firebird  20   0 23780  20m 2892 S    0  2.0   0:08.64 fb_inet_server
 8480 firebird  20   0 21460  17m 2888 S    0  1.8   0:02.71 fb_inet_server
 7592 firebird  20   0 19200  15m 2852 S    0  1.5   0:00.91 fb_inet_server
.
.
.

[guillotmarc]

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.

[sur-se]

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.

[Casimiro Notevi]

Empezado por sur-se

[..] 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.

[rastafarey]

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.

[sur-se]

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.

[Casimiro Notevi]

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.