Sql 2005 MultiHilo o hyperthreading o Dual Core

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:%

Me dice esto:

Total 89835 571562 578
SOS_SCHEDULER_YIELD 58124 312 296
PAGELATCH_EX 24534 93 78
SLEEP_BPOOL_FLUSH 3214 19109 140
WRITELOG 2467 2265 62
PAGEIOLATCH_SH 422 9796 0
PAGEIOLATCH_EX 380 4265 0
LAZYWRITER_SLEEP 269 267625 0
SLEEP_TASK 234 0 0
ASYNC_NETWORK_IO 115 31 0
SQLTRACE_BUFFER_FLUSH 67 268000 0
PAGEIOLATCH_UP 9 62 0


La fila de CXPACKET da cero en las tres columnas. Por tanto mi problema no
es por las esperas CXPACKET.

Creo que el problema es otro. No se exactamente donde lo he leido, pero
creo que lo unico que se puede paralelizar son las SELECT, no los INSERT,
ni los UPDATE, ni los DELETE.

Precisamente, el sistema de calculo lo que hace es, primero un INSERT en
la tabla calculos, y luego varios UPDATE en la misma tabla.

Lo que tengo es un registro en la tabla de calculos por cada registro en
la tabla de cotizaciones. Y luego calculo muchas cosas interdependientes,
es decir, algunos calculos se hacen mediante select sobre la tabla de
cotizaciones, pero otros se hacen con select de la tabla calculos. Más
claro. Las columnas 1 a 7 de la tabla calculos las obtengo con una select
sobre la tabla cotizaciones, pero para calcular las columnas 8 a 11
necesito datos de las columnas 1 a 7 de la tabla de calculos.

Creo el sistema de calculo no corre más porque no puede correr más. Si
desactivo el HT en el equipo grande, el uso de micro se mueve exactamente
igual que en el portatil, y los tiempos son ligeramente inferiores, de 3.8
seg que tarda en el portatil a 3.1 que tarda en el fijo.

El problema que sigo teniendo es que maquina pongo en produccion, por que
una maquina multiprocesador creo que no aumentará el rendimiento del
sistema. Entonces creo que lo unico que puedo poner es un XEON normal, no
un XEON MP, o bien un AMD 64, no un AMD 64X2.

Alguna correccion o sugerencia????

Gracias.

"Miguel Egea" escribió en el mensaje
news:

primero ejecutas dbcc sqlperf(waitstats,clear)
ejecuts tus consultas
y despues
dbcc sqlperf(waitstats)


saludos

"GenioMaestro" wrote in message
news:

Como se monitorizan esas esperas CXPACKET??? Plis.

"Miguel Egea" escribió en el mensaje
news:

Revisa a ver si tienes muchas esperas CXPACKET, es decir esperas por
paralelismo usa el hint maxdop con valor 1 para no permitir paralelismo
y comprueba si has mejorado el rendimiento.

Saludos
Miguel Egea
"GenioMaestro" wrote in message
news:%

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.

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:

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:%

Me dice esto:

Total 89835 571562 578
SOS_SCHEDULER_YIELD 58124 312 296
PAGELATCH_EX 24534 93 78
SLEEP_BPOOL_FLUSH 3214 19109 140
WRITELOG 2467 2265 62
PAGEIOLATCH_SH 422 9796 0
PAGEIOLATCH_EX 380 4265 0
LAZYWRITER_SLEEP 269 267625 0
SLEEP_TASK 234 0 0
ASYNC_NETWORK_IO 115 31 0
SQLTRACE_BUFFER_FLUSH 67 268000 0
PAGEIOLATCH_UP 9 62 0


La fila de CXPACKET da cero en las tres columnas. Por tanto mi problema
no es por las esperas CXPACKET.

Creo que el problema es otro. No se exactamente donde lo he leido, pero
creo que lo unico que se puede paralelizar son las SELECT, no los INSERT,
ni los UPDATE, ni los DELETE.

Precisamente, el sistema de calculo lo que hace es, primero un INSERT en
la tabla calculos, y luego varios UPDATE en la misma tabla.

Lo que tengo es un registro en la tabla de calculos por cada registro en
la tabla de cotizaciones. Y luego calculo muchas cosas interdependientes,
es decir, algunos calculos se hacen mediante select sobre la tabla de
cotizaciones, pero otros se hacen con select de la tabla calculos. Más
claro. Las columnas 1 a 7 de la tabla calculos las obtengo con una select
sobre la tabla cotizaciones, pero para calcular las columnas 8 a 11
necesito datos de las columnas 1 a 7 de la tabla de calculos.

Creo el sistema de calculo no corre más porque no puede correr más. Si
desactivo el HT en el equipo grande, el uso de micro se mueve exactamente
igual que en el portatil, y los tiempos son ligeramente inferiores, de
3.8 seg que tarda en el portatil a 3.1 que tarda en el fijo.

El problema que sigo teniendo es que maquina pongo en produccion, por que
una maquina multiprocesador creo que no aumentará el rendimiento del
sistema. Entonces creo que lo unico que puedo poner es un XEON normal, no
un XEON MP, o bien un AMD 64, no un AMD 64X2.

Alguna correccion o sugerencia????

Gracias.

"Miguel Egea" escribió en el mensaje
news:

primero ejecutas dbcc sqlperf(waitstats,clear)
ejecuts tus consultas
y despues
dbcc sqlperf(waitstats)


saludos

"GenioMaestro" wrote in message
news:

Como se monitorizan esas esperas CXPACKET??? Plis.

"Miguel Egea" escribió en el
mensaje news:

Revisa a ver si tienes muchas esperas CXPACKET, es decir esperas por
paralelismo usa el hint maxdop con valor 1 para no permitir
paralelismo y comprueba si has mejorado el rendimiento.

Saludos
Miguel Egea
"GenioMaestro" wrote in message
news:%

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.

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:

de los que me parecen significativos las esperas tienes de dos tipos
pagelatch y pageiolatch una es contención de caché , la otra es contención
de disco, ninguna creo que sea especialmente significativa ni que tenga
que ver con tu proceso. Lo que si que podemos hacer es optimización pura
y dura

Si puedes ejecutar tu proceso poniento set statitisc io on, set statistics
time on después ejecutar tu proceso y pasarnos los resultados podemos
seguir mirando, No es que SQL sea una aplicacio´n indicada para hacer
"calculo vectorial", pero no creo que en operaciones "pequeñas" de cpu te
vaya a suponer un cuello de botella, tiene que haber algo más.

Saludos
Miguel Egea


"GenioMaestro" wrote in message
news:%

Me dice esto:

Total 89835 571562 578
SOS_SCHEDULER_YIELD 58124 312 296
PAGELATCH_EX 24534 93 78
SLEEP_BPOOL_FLUSH 3214 19109 140
WRITELOG 2467 2265 62
PAGEIOLATCH_SH 422 9796 0
PAGEIOLATCH_EX 380 4265 0
LAZYWRITER_SLEEP 269 267625 0
SLEEP_TASK 234 0 0
ASYNC_NETWORK_IO 115 31 0
SQLTRACE_BUFFER_FLUSH 67 268000 0
PAGEIOLATCH_UP 9 62 0


La fila de CXPACKET da cero en las tres columnas. Por tanto mi problema
no es por las esperas CXPACKET.

Creo que el problema es otro. No se exactamente donde lo he leido, pero
creo que lo unico que se puede paralelizar son las SELECT, no los INSERT,
ni los UPDATE, ni los DELETE.

Precisamente, el sistema de calculo lo que hace es, primero un INSERT en
la tabla calculos, y luego varios UPDATE en la misma tabla.

Lo que tengo es un registro en la tabla de calculos por cada registro en
la tabla de cotizaciones. Y luego calculo muchas cosas interdependientes,
es decir, algunos calculos se hacen mediante select sobre la tabla de
cotizaciones, pero otros se hacen con select de la tabla calculos. Más
claro. Las columnas 1 a 7 de la tabla calculos las obtengo con una select
sobre la tabla cotizaciones, pero para calcular las columnas 8 a 11
necesito datos de las columnas 1 a 7 de la tabla de calculos.

Creo el sistema de calculo no corre más porque no puede correr más. Si
desactivo el HT en el equipo grande, el uso de micro se mueve exactamente
igual que en el portatil, y los tiempos son ligeramente inferiores, de
3.8 seg que tarda en el portatil a 3.1 que tarda en el fijo.

El problema que sigo teniendo es que maquina pongo en produccion, por que
una maquina multiprocesador creo que no aumentará el rendimiento del
sistema. Entonces creo que lo unico que puedo poner es un XEON normal, no
un XEON MP, o bien un AMD 64, no un AMD 64X2.

Alguna correccion o sugerencia????

Gracias.

"Miguel Egea" escribió en el mensaje
news:

primero ejecutas dbcc sqlperf(waitstats,clear)
ejecuts tus consultas
y despues
dbcc sqlperf(waitstats)


saludos

"GenioMaestro" wrote in message
news:

Como se monitorizan esas esperas CXPACKET??? Plis.

"Miguel Egea" escribió en el
mensaje news:

Revisa a ver si tienes muchas esperas CXPACKET, es decir esperas por
paralelismo usa el hint maxdop con valor 1 para no permitir
paralelismo y comprueba si has mejorado el rendimiento.

Saludos
Miguel Egea
"GenioMaestro" wrote in message
news:%

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.

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:

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:

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:%

Me dice esto:

Total 89835 571562 578
SOS_SCHEDULER_YIELD 58124 312 296
PAGELATCH_EX 24534 93 78
SLEEP_BPOOL_FLUSH 3214 19109 140
WRITELOG 2467 2265 62
PAGEIOLATCH_SH 422 9796 0
PAGEIOLATCH_EX 380 4265 0
LAZYWRITER_SLEEP 269 267625 0
SLEEP_TASK 234 0 0
ASYNC_NETWORK_IO 115 31 0
SQLTRACE_BUFFER_FLUSH 67 268000 0
PAGEIOLATCH_UP 9 62 0


La fila de CXPACKET da cero en las tres columnas. Por tanto mi problema
no es por las esperas CXPACKET.

Creo que el problema es otro. No se exactamente donde lo he leido, pero
creo que lo unico que se puede paralelizar son las SELECT, no los
INSERT, ni los UPDATE, ni los DELETE.

Precisamente, el sistema de calculo lo que hace es, primero un INSERT en
la tabla calculos, y luego varios UPDATE en la misma tabla.

Lo que tengo es un registro en la tabla de calculos por cada registro en
la tabla de cotizaciones. Y luego calculo muchas cosas
interdependientes, es decir, algunos calculos se hacen mediante select
sobre la tabla de cotizaciones, pero otros se hacen con select de la
tabla calculos. Más claro. Las columnas 1 a 7 de la tabla calculos las
obtengo con una select sobre la tabla cotizaciones, pero para calcular
las columnas 8 a 11 necesito datos de las columnas 1 a 7 de la tabla de
calculos.

Creo el sistema de calculo no corre más porque no puede correr más. Si
desactivo el HT en el equipo grande, el uso de micro se mueve
exactamente igual que en el portatil, y los tiempos son ligeramente
inferiores, de 3.8 seg que tarda en el portatil a 3.1 que tarda en el
fijo.

El problema que sigo teniendo es que maquina pongo en produccion, por
que una maquina multiprocesador creo que no aumentará el rendimiento del
sistema. Entonces creo que lo unico que puedo poner es un XEON normal,
no un XEON MP, o bien un AMD 64, no un AMD 64X2.

Alguna correccion o sugerencia????

Gracias.

"Miguel Egea" escribió en el mensaje
news:

primero ejecutas dbcc sqlperf(waitstats,clear)
ejecuts tus consultas
y despues
dbcc sqlperf(waitstats)


saludos

"GenioMaestro" wrote in message
news:

Como se monitorizan esas esperas CXPACKET??? Plis.

"Miguel Egea" escribió en el
mensaje news:

Revisa a ver si tienes muchas esperas CXPACKET, es decir esperas por
paralelismo usa el hint maxdop con valor 1 para no permitir
paralelismo y comprueba si has mejorado el rendimiento.

Saludos
Miguel Egea
"GenioMaestro" wrote in message
news:%

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.

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:

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:

de los que me parecen significativos las esperas tienes de dos tipos
pagelatch y pageiolatch una es contención de caché , la otra es
contención de disco, ninguna creo que sea especialmente significativa ni
que tenga que ver con tu proceso. Lo que si que podemos hacer es
optimización pura y dura

Si puedes ejecutar tu proceso poniento set statitisc io on, set
statistics time on después ejecutar tu proceso y pasarnos los resultados
podemos seguir mirando, No es que SQL sea una aplicacioŽn indicada para
hacer "calculo vectorial", pero no creo que en operaciones "pequeñas" de
cpu te vaya a suponer un cuello de botella, tiene que haber algo más.

Saludos
Miguel Egea


"GenioMaestro" wrote in message
news:%

Me dice esto:

Total 89835 571562 578
SOS_SCHEDULER_YIELD 58124 312 296
PAGELATCH_EX 24534 93 78
SLEEP_BPOOL_FLUSH 3214 19109 140
WRITELOG 2467 2265 62
PAGEIOLATCH_SH 422 9796 0
PAGEIOLATCH_EX 380 4265 0
LAZYWRITER_SLEEP 269 267625 0
SLEEP_TASK 234 0 0
ASYNC_NETWORK_IO 115 31 0
SQLTRACE_BUFFER_FLUSH 67 268000 0
PAGEIOLATCH_UP 9 62 0


La fila de CXPACKET da cero en las tres columnas. Por tanto mi problema
no es por las esperas CXPACKET.

Creo que el problema es otro. No se exactamente donde lo he leido, pero
creo que lo unico que se puede paralelizar son las SELECT, no los
INSERT, ni los UPDATE, ni los DELETE.

Precisamente, el sistema de calculo lo que hace es, primero un INSERT en
la tabla calculos, y luego varios UPDATE en la misma tabla.

Lo que tengo es un registro en la tabla de calculos por cada registro en
la tabla de cotizaciones. Y luego calculo muchas cosas
interdependientes, es decir, algunos calculos se hacen mediante select
sobre la tabla de cotizaciones, pero otros se hacen con select de la
tabla calculos. Más claro. Las columnas 1 a 7 de la tabla calculos las
obtengo con una select sobre la tabla cotizaciones, pero para calcular
las columnas 8 a 11 necesito datos de las columnas 1 a 7 de la tabla de
calculos.

Creo el sistema de calculo no corre más porque no puede correr más. Si
desactivo el HT en el equipo grande, el uso de micro se mueve
exactamente igual que en el portatil, y los tiempos son ligeramente
inferiores, de 3.8 seg que tarda en el portatil a 3.1 que tarda en el
fijo.

El problema que sigo teniendo es que maquina pongo en produccion, por
que una maquina multiprocesador creo que no aumentará el rendimiento del
sistema. Entonces creo que lo unico que puedo poner es un XEON normal,
no un XEON MP, o bien un AMD 64, no un AMD 64X2.

Alguna correccion o sugerencia????

Gracias.

"Miguel Egea" escribió en el mensaje
news:

primero ejecutas dbcc sqlperf(waitstats,clear)
ejecuts tus consultas
y despues
dbcc sqlperf(waitstats)


saludos

"GenioMaestro" wrote in message
news:

Como se monitorizan esas esperas CXPACKET??? Plis.

"Miguel Egea" escribió en el
mensaje news:

Revisa a ver si tienes muchas esperas CXPACKET, es decir esperas por
paralelismo usa el hint maxdop con valor 1 para no permitir
paralelismo y comprueba si has mejorado el rendimiento.

Saludos
Miguel Egea
"GenioMaestro" wrote in message
news:%

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.