ERRO: There is insufficient system memory in resource pool 'default' to run this query.

Olá pessoal tudo certo?

Hoje ao entrar em um JOB de um servidor SQL Server me deparei com a seguinte mensagem:

[SQLSTATE 01000] (Message 0)  --> OK [SQLSTATE 01000] (Message 0)  There is insufficient system memory in resource pool 'default' to run this query. [SQLSTATE 42000] (Error 50000).  The step failed.

Esta mensagem de erro indicava problemas de falta de memória, ao consultar o ERRORLOG do SQL Server notei as seguintes mensagens:

2014-12-28 15:22:17.000 Server       Error: 17300, Severity: 16, State: 1.
2014-12-28 15:22:17.000 Server       SQL Server was unable to run a new system task, either because there is insufficient memory or the number of configured sessions exceeds the maximum allowed in the server. Verify that the server has adequate memory. Use sp_configure with option 'user conne
2014-12-28 15:22:17.000 spid56       Error: 701, Severity: 17, State: 123.
2014-12-28 15:22:17.000 spid56       There is insufficient system memory in resource pool 'default' to run this query.
2014-12-28 15:22:17.010 Server       Error: 17312, Severity: 16, State: 1.
2014-12-28 15:22:17.010 Server       SQL Server is terminating a system or background task SSB Task due to errors in starting up the task (setup state 1).
2014-12-28 15:22:17.020 Server       Error: 17053, Severity: 16, State: 1.
2014-12-28 15:22:17.020 Server       BRKR TASK: Operating system error Exception 0x1 encountered.
2014-12-28 15:22:17.030 spid19s  

Logo abaixo destas mensagens havia uma saída do DBCC MEMORYSTATUS. Olhando as seções do MEMORYSTATUS, notei que o CACHESTORE_SQLCP, responsável pelo cache dos planos de execução de queries AD HOC, estava consumindo sozinho cerca de 12.5 GB de memória do buffer pool do SQL Server:

CACHESTORE_SQLCP (node 0)                        KB
---------------------------------------- ----------
VM Reserved                                       0
VM Committed                                      0
Locked Pages Allocated                            0
SM Reserved                                       0
SM Committed                                      0
SinglePage Allocator                       13108912 = 12.5 GB
MultiPage Allocator                          114560


Como o SQL Server tinha o buffer pool configurado para 13.5 GB em uma máquina com 16 GB de RAM, possivelmente o servidor ficou sem memória para continuar atendendo as requisições. A partir daí parti para uma investigação mais profunda das queries executadas pela carga de trabalho e pelo job em particular, afim de identificar oportunidades de melhoria e parametrização das queries do tipo ad hoc. 

Mas o que será que o SQL Server quis dizer ao escrever no log in resource pool 'default'”?

Bom, alguns já devem ter ouvido falar sobre o Resource Governor, uma tecnologia que foi implementada inicialmente no SQL Server 2008 que tem como objetivo controlar os recursos de CPU, Memória e I/O (disponível apenas no SQL Server 2014). Não vamos discutir o Resource Governor aqui, maiores informações podem ser obtidas aqui:


Quando uma versão do SQL Server 2008 ou superior é instalada, dois workload groups e dois resource pools são criados. Os workload groups e resource pools que são criados são os seguintes:

Default: onde são executadas as requisições de usuário, associado ao resource pool Default.

Internal: onde são executadas as requisições de sistema, associado ao resource pool Internal.

Mesmo que o Resource Governor não seja configurado numa instância do SQL Server, ao completar o login as sessões de usuário são atribuídas para o workload group Default. E todas as sessões de sistema rodam no workload Internal. Isto está refletido na sys.dm_exec_requests e sys.dm_exec_sessions, que desde o SQL Server 2008 possuem um campo adicional chamado group_id: sessões com group_id igual 1 são de sistema, sessões com group_id igual a 2 são de usuário:

sys.dm_exec_sessions (Transact-SQL)

sys.dm_exec_requests (Transact-SQL)

É isso pessoal! Um abraço e até a próxima!

Referências adicionais:


Nenhum comentário:

Postar um comentário