Pregunta simple

¿Cómo se sincroniza el SQL Server Quantum (4 ms) con el servidor OS Quantum (normalmente: 187,5 ms)?

Pregunta simple explicada

Después de utilizar 184 ms del sistema operativo cuántico (que corresponde a 46 cuánticos SQL completos), el sistema cuántico del sistema operativo tiene 3.5 ms de tiempo antes de que tenga que entregar la programación a un proceso diferente. El sistema operativo SQL inicia un cuanto (4 ms) y después de 3,5 ms, el cuántico del sistema operativo ha decidido detener el subproceso actual del sistema operativo SQL que todavía tiene 0,5 ms antes de que produzca la programación. ¿Que pasa ahora?

---

Inmersión profunda en OS Quantum

En las próximas dos secciones escribiré lo que he encontrado hasta ahora sobre el cuanto del sistema operativo y cómo se puede calcular la duración de un cuanto. La duración de un "quantum" del sistema operativo se basa en "ticks" y la duración del "tick" en sí se basa en el "intervalo de reloj" que normalmente es de 15.625000 ms. Pero déjame explicar un poco ...

garrapata

En el artículo del blog Know Thy Tick, el autor Jim explica los conceptos básicos de los intervalos de reloj (también conocidos como "ticks") y para qué sirven.

Cuando leo algo como "el intervalo de reloj ... para la mayoría de los multiprocesadores x86 es de aproximadamente 15 milisegundos", me veo obligado a determinar el valor de mi reloj, o "tic", intervalo. Afortunadamente, el libro en el que leí esta cita, Windows Internals Fourth Edition, proporciona una referencia para ayudarme con mi aflicción. ... El autor, Mark Russinovich, del libro mencionado ha hecho gentilmente la utilidad ClockRes disponible en su sitio web. Al ejecutar esta utilidad, pude determinar que el intervalo de reloj en mi PC multiprocesador x86 es de 15.625000 ms. Interesante, pero mi mente curiosa quiere saber más.

Cuántico

El autor del artículo continúa explicando en su segundo artículo ese...

Por supuesto, la verdadera razón por la cual el intervalo de tick es importante es que afecta la programación de subprocesos . El programador de Windows le da a cada subproceso un "tiempo cuántico" de ejecución antes de permitir que se ejecute otra tarea, con el mismo nivel de prioridad. El cuanto que el programador asigna a un hilo es un múltiplo del intervalo de tics . El valor cuántico específico elegido para un hilo específico está un poco más allá de donde quiero ir con este artículo.

Ok, sé lo que es un cuanto, pero no cuánto tiempo durará un cuanto.

Por ahora, examinemos el valor cuántico predeterminado para un subproceso en primer plano en XPe. En este caso, el planificador de Windows asigna una cantidad de 18 o 6 intervalos de tics. (Sí, para convertir los intervalos cuánticos en tics, uno debe dividir entre 3. ..., pero la razón del múltiplo es permitir que el programador pueda "cargar" un subproceso para realizar una operación que hace que se suspenda).

Ahora sabemos que un intervalo de reloj (tick) debe ser de alrededor de 15.625000 ms y en un sistema operativo de escritorio de Windows donde la cantidad predeterminada es 18 que dará como resultado 6 ticks o 93.750000 ms (18/3 * 15.625000 ms).

En un sistema operativo Windows Server, la cantidad predeterminada es diferente. La configuración "Programación del procesador" está establecida en "Servicios en segundo plano"

^{Esta configuración se puede encontrar en "Configuración del sistema | Avanzado (pestaña) | Rendimiento (sección) | Configuración ..." que abrirá "Opciones de rendimiento | Avanzado (pestaña) | Programación del procesador"}

La configuración cuántica predeterminada es 36 (Fondo) a 36 (Primer plano). El cuanto es más grande y, por lo tanto, más largo. Esto es el doble de la cantidad de 93.750000 ms de la configuración cuántica de primer plano de 18 (6 tick) en un SO de escritorio de Windows, que en un SO de servidor configurado para Servicios en segundo plano es de aproximadamente 187.500000 ms.

Observación / Explicación

Cuando cambia la configuración de "Servicios en segundo plano" a "Aplicaciones" en un servidor o escritorio, la clave HKLM \ SYSTEM \ CurrentControlSet \ Control \ PriorityControl \ Win32PrioritySeparation en el registro cambia de 0x18 a 0x02. ¿Cuál es el valor cuántico predeterminado para 0x02? Esto se puede encontrar en un comentario:

El valor 0x02 implica que los campos "Corto vs. Largo" y "Variable vs. Fijo" son los predeterminados para el sistema operativo.

El valor predeterminado para estos campos para XPe y XP Pro es: Corto y Variable, que es lo mismo que tener los siguientes bits adicionales: 0x24.

O si ingresa este valor con 0x02 le da 0x26, que encontrará en la tabla del artículo.

^{Referencia: Comentario a "Domina tu cuanto" (Blogs de MSDN)}

La tabla que explica la configuración cuántica del mismo artículo:

Win32PrioritySeparation   Foreground   Background
0x28, 0x29, 0x2A                  18           18
0x18, 0x19, 0x1A                  36           36
0x24                               6            6
0x25, 0x14                        12            6
0x26                              18            6
0x15                              24            6
0x16                              36            6

Breve resumen de OS Quantum

Según la información anterior y las citas de artículos, sabemos que un cuanto no es un tamaño fijo, sino que se deriva de una configuración del sistema operativo en las Propiedades del sistema. Un cuanto varía según la Win32PrioritySeparationconfiguración en el registro que normalmente corresponde a una de las configuraciones en "Propiedades del sistema" ("Servicios en segundo plano" o "Aplicaciones").

Un cuanto a nivel de sistema operativo es

• para la configuración "Aplicaciones"
  • 18 (que es 6 ticks) para aplicaciones en primer plano (93.75 ms)
  • 6 (que es 2 ticks) para aplicaciones en segundo plano (31.25 ms)
• para la configuración "Servicios en segundo plano"
  • 36 (que es 18 ticks) para aplicaciones en primer plano (187,5 ms)
  • 36 (que es 18 ticks) para aplicaciones en segundo plano (187,5 ms)

Entonces, ahora sabemos que un cuanto de sistema operativo en una configuración de Windows Server para optimizar los Servicios en segundo plano es ...

36 / 3 * 15.625000 ms = 187.5 ms

---

SQL OS Quantum

Esta sección enumera lo que he encontrado en SQL OS Quantum ...

SOS_SCHEDULER_YIELD Tipo de espera

De la descripción de Paul Randall en el tipo de espera SOS_SCHEDULER_YIELD:

Este tipo de espera es cuando un subproceso pudo ejecutarse para su cuántica de subproceso completo (4 milisegundos en todas las versiones de SQL Server, inmutable ), y así voluntariamente arrojó el planificador, moviéndose al final de la Cola Runnable en su planificador.

^{Referencia: SOS_SCHEDULER_YIELD (Tipos de espera de SQLSkills.com)}

Programadores en DMV de SQL Server

En una explicación sobre los DMV de SQL Server para el DMV sys.dm_os_schedulers.

[...] Windows utiliza un mecanismo de programación preventivo y asigna una cantidad de tiempo de CPU a cada subproceso, cuando un subproceso consume su cantidad, se envía a una cola y se concede la ejecución de otros subprocesos.

Por el contrario, SQL Server utiliza un mecanismo de programación cooperativo cuando los subprocesos pueden producir voluntariamente su cantidad de tiempo (puede ver este comportamiento cuando tiene un tipo de espera SOS_SCHEDULER_YIELD). Esto permite que SQL Server optimice la utilización de la CPU, ya que cuando un subproceso está indicado para su ejecución pero no está listo para ejecutarse, puede producir su cantidad de tiempo a favor de otros subprocesos .

^{Referencia: Comprender los programadores, trabajadores y tareas de SQL Server (MSSQLTips.com)}

Detectar la presión de la CPU del servidor SQL

Esta es una sección muy pequeña de un artículo sobre la presión de la CPU en SQL Server.

Se produce cuando una tarea entrega voluntariamente el programador para que otras tareas se ejecuten. Durante esta espera, la tarea está esperando que se renueve su cuanto .

^{Referencia: detectar la presión de la CPU del servidor SQL (MSSQLTips.com)}

sys.dm_os_schedulers (documentos de Microsoft)

Supongo que la siguiente cita es el fragmento de información más importante sobre la cantidad de SQL OS que pude encontrar:

quantum_length_us bigint  Identified for informational purposes only. 
                          Not supported. Future compatibility is not guaranteed. 
                          Exposes the scheduler quantum used by SQLOS.

^{Referencia: sys.dm_os_schedulers (Transact-SQL) (Microsoft | Docs)}

---

Mi enigma

El servidor OS Quantum regula la cantidad de tiempo que se le otorga al servicio SQL Server para ejecutar "tareas". El SQL Server OS Quantum se define como 4 ms. Si divido los 187.5 ms por 4 ms, me quedan 3.5 ms.

Y ni siquiera hemos comenzado la discusión sobre cuándo el Intervalo de reloj se establece en algo diferente al valor predeterminado de 15.625000 ms ...

Pregunta simple

¿Cómo se sincroniza el SQL Server Quantum (4 ms) con el servidor OS Quantum (normalmente: 187,5 ms)?

Pregunta simple explicada

Después de utilizar 184 ms del sistema operativo cuántico (que corresponde a 46 cuánticos SQL completos), el sistema cuántico del sistema operativo tiene 3.5 ms de tiempo antes de que tenga que entregar la programación a un proceso diferente. El sistema operativo SQL inicia un cuanto (4 ms) y después de 3,5 ms, el cuántico del sistema operativo ha decidido detener el subproceso actual del sistema operativo SQL que todavía tiene 0,5 ms antes de que produzca la programación. ¿Que pasa ahora?

Aunque el planificador no es preventivo, el planificador de SQL Server todavía se adhiere a un concepto de cuanto. En lugar de que las tareas de SQL Server se vean obligadas a abandonar la CPU por el sistema operativo, pueden solicitar que se les coloque en una cola de espera periódicamente, y si han excedido la cantidad interna de 4 milisegundos definida internamente y no están en medio de una operación eso no se puede detener, renuncian voluntariamente a la CPU.

- " Microsoft SQL Server 2012 Internals ", Kalen Delaney et. Alabama. pp38

-Capítulo 2 "El SQLOS" Jonathan Kehayias

Entonces, la noción de un "quantum" dentro de SQL Server es más una "guía" para las tareas de programación. Es decir, cuando escribe una tarea, como digamos, una tarea que realiza un escaneo de tabla, si no golpea ningún bloqueo de página, bloqueo de E / S o espera de bloqueo por un tiempo, debe detener lo que está haciendo y pedir ser volver a poner en la cola ejecutable, en caso de que haya otras tareas esperando.

Pero depende del programador de tareas implementar esto, y puede que no sea exactamente 4 ms para cada tipo de tarea. Por ejemplo, la tarea de escaneo de tablas podría usar una heurística simple basada en el número de páginas escaneadas para implementar los puntos de rendimiento.

Entonces

El sistema operativo SQL inicia un cuanto (4 ms) y después de 3,5 ms, el cuántico del sistema operativo ha decidido detener el subproceso actual del sistema operativo SQL que todavía tiene 0,5 ms antes de que produzca la programación. ¿Que pasa ahora?

Si Windows adelanta el subproceso de SQL Server mientras se ejecuta una tarea, se pausará y cuando su subproceso se programe la próxima vez en una CPU, continuará donde lo dejó. Presumiblemente continuará consumiendo el equilibrio de su cuántica de 4 ms, ya que no notaría ninguna diferencia. Pero, de nuevo, el comportamiento de rendimiento es un detalle de implementación de la tarea, no un comportamiento de SQLOS, por lo que diferentes tareas podrían comportarse de manera diferente aquí.

_{Responda las contribuciones originalmente dejadas como comentarios}

¿Cómo se sincroniza el SQL Server Quantum (4 ms) con el servidor OS Quantum (normalmente: 187,5 ms)?

No lo es y SQL Server no utiliza la programación preventiva. Se espera que los elementos de trabajo alcancen los puntos de rendimiento y, si no lo hacen, obtendrá cosas como NONYIELDINGplanificadores. No hay paridad. SQL Server no distribuye el tiempo. Hace que ciertos subprocesos sean atractivos para que Windows los programe y Windows los programe. Quantum es solo una nomenclatura por un tiempo. Eso es. SQL Server no es preventivo, es responsabilidad de lo que se esté ejecutando para obtener todo el código. - Sean Gallardy

Cuando el sistema operativo cuántico expira, el subproceso se desprograma a la fuerza. Esto es transparente para SQL Server. SQLOS no tiene forma de detectar cuándo sucede esto. No hay API Win32 para eso. La programación es transparente para los hilos de modo de usuario. El planificador de Windows no sabe ni le importa qué están haciendo los hilos de modo de usuario. Windows solo ve subprocesos ejecutables y les permite ejecutarse hasta el final de su sistema operativo cuántico o hasta que se bloqueen. - usr

En Cómo manejar valores excesivos de tipo de espera SOS_SCHEDULER_YIELD en SQL Server por Nikola Dimitrijevic, el término "cuántico" se utiliza esencialmente para significar "el tiempo que una tarea realmente asigna a un trabajador", pero ese no es el mismo sentido que un cuántico de Windows, que es un período de tiempo después del cual el sistema operativo eliminará un hilo de una CPU. Son solo conceptos diferentes. Si el sistema operativo obliga a un subproceso a finalizar la ejecución porque se ha alcanzado el cuanto del sistema operativo, se produce un cambio de contexto. El hilo de SQL Server está suspendido, al igual que cualquier otro programa. - David Browne - Microsoft y George.Palacios .

---

Extractos de la documentación: Dentro del Programador de modo de usuario de SQL Server 2000 (escrito para SQL Server 2000, pero aún relevante):

Tarea preventiva versus cooperativa

UMS, por el contrario, se basa en hilos para ceder voluntariamente. UMS toma el enfoque que usa para evitar involucrar al kernel de Windows más de lo absolutamente necesario. En un sistema en el que se puede contar con los subprocesos de los trabajadores para que rindan cuando deberían, un programador cooperativo puede ser más eficiente que uno preventivo porque el proceso de programación se puede adaptar a las necesidades específicas de la aplicación. Como dije antes, UMS conoce las necesidades de programación de SQL Server mejor de lo que se puede esperar del sistema operativo.

Cómo UMS se hace cargo de la programación

Si UMS va a manejar las necesidades de programación de SQL Server en lugar de permitir que Windows lo haga, UMS debe evitar de alguna manera que el sistema operativo haga lo que hace con cualquier otro proceso: programar subprocesos dentro y fuera de los procesadores del sistema como mejor le parezca. ¿Cómo se hace eso en un sistema operativo preventivo? UMS logra esto a través de algunos trucos inteligentes con objetos de eventos de Windows. Cada subproceso en UMS tiene un objeto de evento asociado. Para propósitos de programación, Windows ignora los hilos que no considera viables, hilos que no pueden ejecutarse porque están en un estado de espera infinito. Sabiendo esto, UMS pone los hilos en suspensión que no desea que se programen haciendo que llamen a WaitForSingleObject en su objeto de evento correspondiente y pasen INFINITE por el valor de tiempo de espera.

Para evitar que Windows programe múltiples subprocesos en el mismo procesador y, por lo tanto, incurra en la sobrecarga y el gasto de los cambios de contexto, UMS intenta mantener viable solo un subproceso, es decir, no en un estado de espera infinito, por procesador.