Sql 2005 MultiHilo o hyperthreading o Dual Core

27/07/2006 - 10:52 por GenioMaestro | Informe spam
Hola a todos:

Tengo una aplicación desarrollada en sql 2005 que entrará en produccion en
septiembre, espero, y tengo algunos problemas que me hacen dudar sobre la
configuracion de la maquina de produccion.

Es un sistema de calculo bursatil. La base de datos tiene ya unos 15 GB y
creciendo. La estructura interna es muy sencilla, tan solo tengo dos tablas
principales, una de cotizaciones con 8 campos y otra de calculos con 53
campos. Pero eso si, cada tabla tiene unos 25 Millones de registros.

El programa lo he desarrollado en el portatil, un centrino 1.6 con 1 Gb de
memoria y se mueve muy bien, usando el micro siempre por encima del 80% y
mucho tiempo al 100%, lo que veo normal porque estoy haciendo muchos
calculos matematicos y consultas bastante complejas.

El problema lo tengo al pasar a la maquina grande de desarrollo. Es un
Pentium4 3.2 con HT, un 630 o 640 con 2 Gb de memoria y 200 Gb de disco duro
Sata2 de 3 Gbs y NCQ. En esta maquina, el uso del procesador está cerca del
50% con un máximo del 55%. Parece como si no usara el HT. Y sin embargo, los
dos graficos se mueven en paralelo, cuando uno sube el otro baja y
viceversa.

En el portatil centrino no hay HT y supuse que al pasarlo a la maquina
grande, con un micro más potente, los tiempos mejorarían, pero no es así. He
probado a poner un Dual Core, que no es HT, pero me pasa lo mismo. Los
tiempos de calculo son exactamente los mismos, tanto en el portatil como en
el P4 con HT que con el Dual Core.

Alguna idea de lo que puede estar pasando???? Que maquina pongo en
produccion si todas las maquinas me tardan lo mismo????

Todas las maquinas tienen Windows XP Pro SP2, y la version demo de 6 meses
de Sql Server 2005 Enterprise.

Espero vuestras ideas y orientaciones.

Gracias.

Preguntas similare

Leer las respuestas

#6 J.A. García Barceló
28/07/2006 - 14:01 | Informe spam
Tal vez lo que diga sea una burrada pero ahi va...

¿Por que no intentas paralelizar tus cálculos (para empezar podemos probar
con 2), particionando tú mismo dichos cálculos? Supongo que los tienes en un
procedimiento almacenado, en ese caso, haz un SP_1 que realice los cálculos
sobre la mitad de los datos que tengas que procesar, y otro SP_2 que realice
la otra parte. Luego lanzas los 2 procedimientos almacenados simultaneamente
usando 2 conexiones diferentes.

A ver que tal se comporta en un server con HT, y en otro con 2
procesadores

Cuentanos.

J.A. García Barceló
http://jagbarcelo.blogspot.com/


"GenioMaestro" escribió en el mensaje
news:%
Mostrar la cita
#7 GenioMaestro
28/07/2006 - 17:05 | Informe spam
No puedo hacer eso que me dices, porque los calculos son interdependientes.

Tenia 12 fases de calculo y las he agrupado en 4, de forma que sean
secuenciales. Es decir, para calcular la fase 2 tengo que tener
obligatoriamente calculada la fase 1, y asi con la 3 y la 4. Al hacer la
agrupacion los tiempos bajaron notoriamente.

Lo que si he probado y demostrado es calcular a la vez dos grupos de
valores, es decir, dos mercados a la vez, nasdaq y nyse, y en ese caso el
micro HT si se pone a 100%, pero los tiempos de calculo son mas altos que
calculandolo por separado, alrrededor de un 20% de incremento de tiempo.


"J.A. García Barceló" escribió en el mensaje
news:
Mostrar la cita
#8 GenioMaestro
28/07/2006 - 18:03 | Informe spam
Puedo poner set statitisc io on y set statistics time on en el administrador
corporativo, lanzando una consulta o un procedimiento almacenado y deciros
lo que da, pero todas las consultas y funciones han sido depuradas al
limite. Os paso una de las operaciones mas pesadas.

update calculos set
Max_Nivel1 = ...,
Max_Nivel2 = ...,
Max_Nivel3 = ...,
Max_Nivel4 = ...,
Max_Nivel5 = ( select top 1 cierre from (SELECT TOP 2 cierre FROM (
SELECT TOP 1900 CIERRE FROM COTIZACIONES WITH (TABLOCKX)
WHERE COD_VALOR = @PASA_VALOR AND FECHA < (SELECT TOP 1 FECHA FROM (SELECT
TOP 600 FECHA FROM COTIZACIONES WITH (TABLOCKX) WHERE COD_VALOR =
@PASA_VALOR AND FECHA <= FECHA_CAL ORDER BY FECHA DESC) AS XX_TEMPO ORDER BY
FECHA ASC)
ORDER BY FECHA DESC) AS XX_TEMPO ORDER BY CIERRE DESC ) as xx_tempo2 order
by cierre asc ) ,
Min_Nivel1 = ...,
Min_Nivel2 = ...,
Min_Nivel3 = ...,
Min_Nivel4 = ...,
Min_Nivel5 = ( select top 1 cierre from (SELECT TOP 2 cierre FROM (
SELECT TOP 1900 CIERRE FROM COTIZACIONES WITH (TABLOCKX)
WHERE COD_VALOR = @PASA_VALOR AND FECHA < (SELECT TOP 1 FECHA FROM (SELECT
TOP 600 FECHA FROM COTIZACIONES WITH (TABLOCKX) WHERE COD_VALOR =
@PASA_VALOR AND FECHA <= FECHA_CAL ORDER BY FECHA DESC) AS XX_TEMPO ORDER BY
FECHA ASC)
ORDER BY FECHA DESC) AS XX_TEMPO ORDER BY CIERRE ASC ) as xx_tempo2 order
by cierre DESC )
FROM CALCULOS WITH (TABLOCKX)
where cod_valor = @PASA_VALOR
and FECHA_CAL >= @F_INI and FECHA_CAL < @F_FIN

Es un SELECT de SELECT de SELECT WHERE SUBSELECT de SUBSELECT, son 5
anidaciones. Es la septima version y hasta el momento es la más rapida que
conseguido. Empeze con un cursor que era terriblemente lento, luego con
WHERE fecha NOT IN (SELECT ...) y tambien era muy lento. Ademas averigue que
si lo calculaba desde una funcion de usuario UDF era más lento que si
lanzaba la consulta directamente en la clausula update, osea que quite las
funciones. Luego probe con optimizaciones como WITH (TABLOCKX) y la cosa
mejoro mucho. Esto es lo mas optimizado que he conseguido. Puntualizo que
aun quitando las optimizaciones WITH (TABLOCKX) el micro HT hace lo mismo,
pero tardando mas tiempo.

Los niveles 1,2,3 y 4 se calculan de la misma forma pero con otros rangos
TOP. Para averiguar el maximo se ordena en ascendente y para el mínimo en
descendente, por lo demas las consultas son identicas. En el nivel 5
necesito procesar 2500 registros, 1900 + 600 = 2500, que multiplicado por
los 10.000 valores da la friolera de 25 millones de registros. Por tanto,
cada vez que calculo todos los valores de todos los mercados, la fase 1
donde esta este update, se pasea por todos y cada uno de los registros de
cotizaciones.

El problema esta en que cuando pasemos a produccion, el cliente quiere tener
de 30.000 a 50.000 valores, lo que me da de 75 a 125 millones de registros.
Creo que voy a tener que particionar las tablas y los indices, aunque el
problema no es de disco duro, la cola de disco esta siempre en cero con un
maximo de 2.

Me extraña mucho que este proceso no sea paralelizable, solo son dos select
pesados, uno de 600 registros y otro de 1900, las otras tres consultas solo
sacan 1 registro o 2, una nimiedad para sql server, y segun estoy
escribiendo se me esta ocurriendo algo. Voy a probar y os cuento.



"Miguel Egea" escribió en el mensaje
news:
Mostrar la cita
#9 GenioMaestro
28/07/2006 - 19:50 | Informe spam
Ya lo tengo.

No se si es por lo que me contais vosotros o porque al contaroslo se me
ocurren mas cosas.

Os lo explico. Veamos, si el sql server no es capaz de paralelizar el
trabajo, bien porque no se puede, bien porque no lo ve necesario, pues
hagamoslo a mano, desde el cliente, y ya esta

Es decir, si lanzo el cliente dos veces y a cada cliente le digo que calcule
un mercado distinto, el micro si se pone a 100%.

¿¿¿ Y si preparo el cliente para que lanze el calculo de dos valores del
mismo mercado de forma ASINCRONA????

Bingo, el micro se pone a 100% y es el sql quien se come el micro.

Ahora solo tengo que parametrizar el cliente segun la configuracion de
procesadores del servidor. Lo cual, mirandolo tecnicamente, es absurdo, pero
me vale, ya que el calculo se realizará desde una sola maquina, en modo
batch nocturno o sumergido.

Gracias a todos.

"GenioMaestro" escribió en el mensaje
news:
Mostrar la cita
#10 Miguel Egea
28/07/2006 - 21:26 | Informe spam
Creo que puede mejorarse, vamos a ver como, ¿nos pasas una descripcion de
uno o dos niveles del tema de cotizaciones yh el script?

Saludos
Miguel Egea
"GenioMaestro" wrote in message
news:
Mostrar la cita
Ads by Google
Search Busqueda sugerida