Martin Sjöberg's questions

Esta é uma pergunta muito geral, por isso não dou muitas informações específicas. Estou mais interessado em paralelismo e suas possíveis desvantagens. Geralmente sou a favor do paralelismo como algo útil e positivo.

Parece que me deparo com mais e mais sistemas que possuem um ou mais procedimentos armazenados que apresentam problemas com muito paralelismo. Existe uma boa maneira de descobrir se esse é realmente o problema ou se há algo mais à espreita?

Normalmente o sql é um pouco complexo com talvez 5 ou mais junções e também alguns udf e ainda mais complexidade. Até agora, encontrei esses problemas examinando tudo, desde problemas de desempenho comuns, mas também de situações mais extremas com mensagens de erro como "Não foi possível criar thread ..." e também bloqueios de várias cópias simultâneas do mesmo procedimento de armazenamento.

Estou muito curioso para saber como vocês fazem para encontrar problemas como esses e também como resolvê-los. Recodificação? Jogando com MAXDOP(grau máximo de paralelismo)? E assim por diante...

Eu gostaria de sua opinião sobre isso. Eu tenho um servidor SQL 2008r2 Ent. Ed. 64 bits com 16 núcleos e 64 GB de RAM. Há uma instância do servidor SQL corrigida totalmente a partir de 20111014.

A RAM máxima está definida para 60000 MB. A quantidade de RAM livre é 0 de acordo com o gerenciador de tarefas após alguns dias online.

Se eu alterar o máximo de RAM para menos de 53 GB, depois de alguns dias ele se estabilizará e terá um pouco de RAM livre.

É o processo sql que aloca a memória RAM de acordo com o gerenciador de tarefas. Como faço para chegar a um acordo com o que o problema realmente é? Escusado será dizer que já fiz muitos testes, mas ainda não resolvi isso ao meu gosto. e, ohh, não obtemos o atraso típico de falta de memória quando a memória RAM disponível está livre para 0.

Atualização 1:

Inspirado por outro Q/A relacionado à RAM nesta página https://dba.stackexchange.com/a/7062/2744 . Eu usei esses dois para ver para que a RAM está sendo usada.

SELECT TOP ( 10 )
        [type] AS [Memory Clerk Type] ,
        SUM(single_pages_kb) AS [SPA Mem, Kb]
FROM    sys.dm_os_memory_clerks
GROUP BY [type]
ORDER BY SUM(single_pages_kb) DESC
OPTION  ( RECOMPILE ) ;

SELECT  DB_NAME(database_id) AS [Database Name] ,
        COUNT(*) * 8 / 1024.0 AS [Cached Size (MB)]
FROM    sys.dm_os_buffer_descriptors
--WHERE   database_id > 4 -- system databases
--        AND database_id <> 32767 -- ResourceDB
GROUP BY DB_NAME(database_id)
ORDER BY [Cached Size (MB)] DESC
OPTION  ( RECOMPILE ) ;

A quantidade usada mostrada por eles é primeiro selecionar 7948432 Kb, segundo um 44030,57812 MB, que é um total de cerca de 52 GB usado pelo servidor SQL ... então, para onde foi o resto da minha RAM? :-) O gerenciador de tarefas mostra agora em cache 363, disponível 401, livre 40 e sqlservr.exe tem memória privada definida 64 459 656. Max Ram definido como 60000 MB como antes.