Sou muito novo nesse ajuste de desempenho com esperas e filas - fascinante, mas também nem sempre tão intuitivo ...
Neste momento, um cliente meu tem um SQL Server 2008 64-bit Enterprise Edition, atualmente com 16 GB de RAM atribuídos a ele, rodando em um servidor físico com 64 GB de RAM (existem outras instâncias do SQL Server e mutáveis no mesmo máquina também).
Este aplicativo que ele está executando é uma solução Sharepoint 2010, que executa - bem - OK para um site Sharepoint - na maioria das vezes. Exceto pelas buscas, que são terrivelmente lentas.
Agora, do ponto de vista do SQL Server, tenho observado as estatísticas de espera por alguns dias e os três principais tipos de espera são:
1) CXPACKET em torno de 49%
2) SOS_SCHEDULER_YIELD em torno de 10,5%
3) OLEDB em torno de 9,5%
Isso parece ser bastante consistente - sem grandes mudanças ao longo do tempo.
- PAGEIOLATCH_SH vem em sétimo lugar - 2,5% do tempo total de espera, o tempo médio de espera do recurso é de 14 ms.
- ASYNC_IO_COMPLETION vem em oito - menos de 2% do total de tempos de espera, mas alta média de tempo de espera do recurso de 38 segundos (sim, segundos - não milissegundos!)
O tempo de espera do sinal é extremamente baixo, então isso não parece indicar pressão da CPU. Então, o que está causando esse padrão - e o que podemos fazer para (a) encontrar informações mais relevantes ou (b) encontrar uma solução para acelerar as coisas?
Alguma ideia? Percepções? Ideias? Estou praticamente aberto a qualquer coisa - o que não podemos mudar é a arquitetura básica (instâncias separadas do SQL Server, sendo movidas entre servidores físicos - e uma SAN baseada em Unix que não pode garantir a separação de dados e fazer logon em discos físicos separados)
Novamente: este é um site do SharePoint - até onde eu sei, tentar resolver as coisas com indexação ou reestruturação do banco de dados está entre o difícil e o impossível.
Como este é o SharePoint, suas mãos estão atadas. Você não pode criar índices ou estatísticas sem perder o suporte da Microsoft.
CXPACKET significa apenas que um thread de uma consulta paralisada está esperando que outro thread termine de esperar por outra coisa. SOS_SCHEDULER_YIELD pode significar algumas coisas, normalmente significa que você precisa corrigir seus índices se você tiver consultas que não estão ajustadas corretamente, então o SQL Server está pausando essas consultas (cedendo-as) para que possa trabalhar em outras coisas (como este é o SharePoint, você realmente não pode fazer nada sobre isso). OLEDB significa que o SQL Server está aguardando o driver OLEDB, então provavelmente há consultas de servidor vinculadas ou algo parecido que está chamando outro servidor de banco de dados. Não há nada que você possa fazer sobre isso também.
Pelo que parece, não há nada que você possa fazer sem jogar mais hardware no problema. Use o Profiler, Server Side Tracing ou Extended Events e encontre as consultas que estão demorando muito para serem executadas e verifique seus planos de execução e veja o quão ruim isso é. As probabilidades são de que as consultas de pesquisa estejam realizando grandes operações de verificação.
Qual é o tamanho dos bancos de dados de conteúdo? A Microsoft recomenda manter os bancos de dados de conteúdo abaixo de 100 Gigs para que a verificação seja mínima.