Processos e Threads

Processos e Threads

  • Comments 2

Quem se recorda dos “Blue Screen” nos tempos do WIndows 95/98? O próprio chefe já demonstrou ao vivo!!!

 

Faz tempo que isso não acontece. A última vez que vi um Blue Screen foi quando meu notebook estava com problemas de memória, ou seja, era um problema de hardware e não software. No tempo do Windows 95/98/Me, qualquer processo poderia ler e escrever na em qualquer região da memória da máquina. Por exemplo: um programa mal comportado poderia sobrescrever estruturas importantes da Kernel e apagar parte do gerenciador de memória virtual! Não é de se duvidar que o Blue Screen ocorria com frequência.

Felizmente as coisas mudaram e tudo isso é passado. Windows XP incorporou a tecnologia da família NT (Windows NT/2000) e temos um sistema operacional capaz de realizar o isolamento de processo. Isso significa que os processos são independentes e não interferem no comportamento do outro. Um processo é incapaz de ler ou escrever na memória de outro processo qualquer, sequer consegue modificar a Kernel.

Exemplo do Task Manager:

image

 

Processo

Do ponto de vista do Windows, um processo contém:

  • Contexto de segurança
  • Endereçamento virtual (Virtual Address Space)
  • Handles
  • Threads

 

Thread

Os processos, por si só, não executam instruções. Os processos possuem threads, que são agendadas para execução pelo Sistema Operacional. Um conceito interessante sobre as threads é a possibilidade de configurar diferentes prioridade de execução.

 

SQL Server

Cada instância ativa de SQL Server corresponde a um processo SQLSERVR.EXE rodando no Sistema Operacional. Cada instância é responsável por gerenciar sua própria memória, ou seja, não existe um monitor compartilhado entre as instâncias.

As threads do SQL Server podem ser observadas através da DMV sys.dm_os_threads e a coluna priority indica a prioridade da thread. A configuração “Priority Boost” (sp_configure) permite elevar a prioridade do processo do SQL Server em relação aos demais. A recomendação é não habilitar a opção Priority Boost (ver a referência “How to determine proper SQL Server configuration settings”). Ao invés de usar o conceito de prioridade do Windows, o administrador de banco de dados deve usar a funcionalidade do Resource Governor.

 

Referência

MSDN Processes and Threads
http://msdn.microsoft.com/en-us/library/ms684841(VS.85).aspx

MSDN Scheduling Priorities
http://msdn.microsoft.com/en-us/library/ms685100(v=VS.85).aspx

SQL Priority Boost
http://msdn.microsoft.com/en-us/library/ms684828(VS.85).aspx

How to determine proper SQL Server configuration settings
http://support.microsoft.com/kb/319942

Managing SQL Server Workloads with Resource Governor
http://msdn.microsoft.com/en-us/library/bb933866.aspx

  • Fabrício, verificar qual(quais) thread é responsável por determinado procedimento ( como por exemplo, o comando abaixo:

    backup database teste to disk = 'c:\a.bak', 'c:\a2.bak'

    ?

    Abraço

  • Para descobrir as threads utilizadas pelo Backup, basta usar olhar na view "sysprocesses" correspondente ao SPID da sessão que iniciou o backup. Por exemplo,

    SELECT kpid, cmd, * from master..sysprocesses WHERE spid=<session_id>

    A coluna KPID corresponde ao "thread Id".

    Se quiser utilizar as DMV's disponíveis a partir do SQL2005, então procure as "worker threads" (sys.dm_os_workers)  correspondentes à sessão.

Page 1 of 1 (2 items)
Leave a Comment
  • Please add 3 and 2 and type the answer here:
  • Post