Uso de varios procesadores

Hola Mariano, cómo andás?

"Jose Mariano Alvarez" wrote:

Gux:

Si ese es el articulo donde aclara que el mito es falso y creo que MAT debe
estar equivocado.

Tal vez. No me siento de la estatura como para decir que Matt o los otros
chicos están equivocados... cómo saberlo? :-)

En los libros "inside SQL" y en la documentacion de MS aparecen detalles
acerca de los schedulers y como pueden ser asociados a cada procesador logico
habilitado por el effinity mask y de como una simple instruccion que supera
el cost threhold for parallelism puede asignar tantos nucleos de
procesamiento como permita la opcion de configuracion MAXDOP.

Conozco de cerca los Inside SQL. El tema que para mí pone en duda todo el
asunto es que siempre se habla de paralelismo en ejecución de sentencias y
procesos. Eso no hay dudas que utiliza adecuadamente a los multiprocesadores.

Ahora, cuando llega el momento de ir al filesystem a manipular un archivo
(p.e. cuando se va a efectuar el autocrecimiento de un archivo físico de la
base de datos) el thread que accede maneja un handle del archivo (sobre el
que se establece además un lock) y no alcanzo a entender que pudieran varios
threads manipular el mismo handle así como si tal cosa.

Sigo sin encontrar una respuesta que responda con total claridad a esta
pregunta:

?Puede un archivo físico en el filesytem de Windows ser modificados
concurrentemente por threads ejecutando en diferentes procesadores?

Por otro lado podria suceder que la mayotia de las veces los datos esten en
memoria y por lo tanto no dependeria del archivo fisico aunque en el
direccionamiento en memoria de las paginas de la base de datos este el FileNo
como parte de la direccion de acceso. Acordate que usa hashing en el buffer
pool para encontrar la pagina en memoria.

Insisto, no me interesa lo que suceda en memoria. Tengo bien claro que allí
el problema está resuelto. Lo que me interesa hacer notar es el acceso físico
a disco.

Gux: Por favor mandame un correo.

You've got mail :-)

Un gran saludo!
~gux

No se si es posible, pero imagino que si se puede. Aun reduciendo a la
situación de que no se pueda acceder en paralelo al archivo (que es un
modelo lógico de un conjunto de bytes en disco), el thread que reciba las
peticiones de disco va manipular los bytes al menos un orden de magnitud mas
rápido que el conjunto de los discos. Por lo tanto puede recibir y encolar
las peticiones y de esa manera paraleliza los accesos decidiendo el orden en
los resuelve. Es lo mismo que hace el SO con el procesador y los thread del
sistema preemtive.

Yo estuve trabajando con un equipo SuperDome NUMA de 32 procesadores, 64Gb
RAM y un storage SAN. Probe un proceso que tardaba 1 hora y usaba 1 solo
procesador la mayoría del tiempo. Pusimos el mismo proceso dos veces en
paralelo sobre los mismos discos y prácticamente no se vio afectado.
Corrieron los dos procesos juntos casi en el mismo tiempo usando dos
procesadores. Aquí el problema eran los cursores.

Creo que igualmente nos fuimos de tema ya que esta persona tenia un proceso
que usaba un solo procesador (y no indico que había problemas de disco).


Saludos


Ing. Jose Mariano Alvarez
SQLTotal Consulting

(Cambia los ceros por O y saca lo que sobra)

Este mensaje se proporciona tal como es, SIN GARANTIAS de ninguna clase. Por
favor tratar de indicar la versión de SQL y Service Pack. La inclusión de
(CREATE, INSERTS, etc.) para poder reproducir el problema también ayuda.










"Gustavo Larriera (MVP)"
wrote in message news:

Hola Mariano, cómo andás?

"Jose Mariano Alvarez" wrote:

Gux:

Si ese es el articulo donde aclara que el mito es falso y creo que MAT
debe
estar equivocado.

Tal vez. No me siento de la estatura como para decir que Matt o los otros
chicos están equivocados... cómo saberlo? :-)

En los libros "inside SQL" y en la documentacion de MS aparecen detalles
acerca de los schedulers y como pueden ser asociados a cada procesador
logico
habilitado por el effinity mask y de como una simple instruccion que
supera
el cost threhold for parallelism puede asignar tantos nucleos de
procesamiento como permita la opcion de configuracion MAXDOP.

Conozco de cerca los Inside SQL. El tema que para mí pone en duda todo el
asunto es que siempre se habla de paralelismo en ejecución de sentencias y
procesos. Eso no hay dudas que utiliza adecuadamente a los
multiprocesadores.

Ahora, cuando llega el momento de ir al filesystem a manipular un archivo
(p.e. cuando se va a efectuar el autocrecimiento de un archivo físico de
la
base de datos) el thread que accede maneja un handle del archivo (sobre el
que se establece además un lock) y no alcanzo a entender que pudieran
varios
threads manipular el mismo handle así como si tal cosa.

Sigo sin encontrar una respuesta que responda con total claridad a esta
pregunta:

?Puede un archivo físico en el filesytem de Windows ser modificados
concurrentemente por threads ejecutando en diferentes procesadores?

Por otro lado podria suceder que la mayotia de las veces los datos esten
en
memoria y por lo tanto no dependeria del archivo fisico aunque en el
direccionamiento en memoria de las paginas de la base de datos este el
FileNo
como parte de la direccion de acceso. Acordate que usa hashing en el
buffer
pool para encontrar la pagina en memoria.

Insisto, no me interesa lo que suceda en memoria. Tengo bien claro que
allí
el problema está resuelto. Lo que me interesa hacer notar es el acceso
físico
a disco.

Gux: Por favor mandame un correo.

You've got mail :-)

Un gran saludo!
~gux