SQLOS – Fluxo de componentes pt01 – Modelos e execução

…Continuando sobre arquitetura do SQL Server.

SQLOS – Fluxo de componentes

SQLOS é fundamental para arquitetura do SQL Server. Ele é uma camada fina de modo de usuário que fica entre o SQL Server e o Windows. É usado para operações d baixo nível como agendamento, gerenciamento de memória e recursos de gestão.
Para explorar exatamente o que isso significa e por que ela é necessária, primeiro precisamos entender o modelo de execução do SQL Server:

Modelo e Execução.

Quando um aplicativo autentica o SQL Server estabelece uma conexão no contexto de uma sessão, que é identificada s por um session_I (em versões anteriores do SQL Server foi chamado de SPID).

Podemos ver uma lista de todas as sessões autenticadas consultando sys.dm_exec_sessions.

Quando um pedido de execução é feita dentro de uma sessão, SQL Server divide o trabalho em um ou mais tarefas e em seguida associa um segmento de trabalho para cada tarefa a sua duração.
Cada seguimento pode estar em um dos três estados:
Running: Em processador pode executar apenas uma coisa de cada vez e o segmento em execução em um processador terá um estado de funcionamento

Suspended: SQL Server tem um agendador cooperativo para threads em execução, será produzido suspensa quando uma thread espera por um novo recurso. Isso que chamamos de espera no sQL Server.

Runnable: Quando um segmento tem acabado de esperar, torna-se executável que significa que está pronto para executar novamente. Isso é conhecido como sinal de espera.

Se não há segmentos de trabalho que são threads de trabalho disponíveis e max não foi alcançado, então o SQL Server irá alocar um novo segmento de trabalho. Se a contagem de linhas de trabalho foi alcançado o máximo, então a tarefa irá esperar com um tipo de espera de ThreadPool até que um segmento se torne disponível.

O padrão de contador máximo de trabalho é baseado na arquitetura de CPU e o número de processos lógicos.
As fórmulas para tal são as seguintes:

Para um sistema operacional de 32 bits:

> Total de CPUs lógicos disponíveis <= 4
Threads de trabalho máximo = 256

> CPUs lógicos disponíveis > 4
Max sgmento de trabalho = 256 + ((CPUs lógicos – 4) * 8)

Para um sistema operacional de 64 bits:

> Total de CPUs lógicos disponíveis <= 4
Threads de trabalho máximo = 256
> CPUs lógicos disponíveis total > 4
Max segmentos de trabalho = 512 + ((CPUs lógicos -4) * 16)

Como um exemplo, um SQL Server 64-bit com 16 processadores teria uma configuração de Threads de trabalho máximo de 512 + (( 16 – 4) * 16 = 704.

Também podemos ver os max de trabalho em um sistema executando:

SELECT max_workers_count
FROM sys.dm_os_sys_info

Cada segmento de trabalho requer 2 MB de RAM em um servidor de 64 bits e 0.5MB em um servidor de 32 bits, portanto, SQL Server cria threads apenas quando ele precisa deles, em vez de tudo de uma vez.
O sys.dm_os_workers DMV contém uma linha para cada segmento de trabalho, assim podemos ver quantas tópicos SQL Server tem atualmente executando o seguinte:

select COUNT(*) from sys.dm_os_workers

Próximo post continuaremos falando de Tarefas e sobre o SQLOS.

Até a próxima…