Estamos no processo de migrar para um novo e robusto SQL Server (12 GB de RAM, 2 CPUs de 4 núcleos, 12 unidades de 15k rpm, rede Gbit). Temos as unidades divindidas em 4 partições para os arquivos de índice OS, Data, Log e texto completo.
Aqui está o problema: Estou executando um trabalho que exite 36k pesquisas (uma combinação de junções de tabela e texto completo) de um único aplicativo de console encadeado. Apenas em vez de sobrecarregar nosso servidor, o servidor registra cerca de 5 a 7% da carga da CPU, não os + -60% que recebíamos em nosso antigo servidor.
A partir do relatório do painel, as únicas esperas que estamos recebendo são as ocasionais IOs esperadas na rede - mas elas vêm e vão. Então parece que o SQL Server está limitando nossa conexão?
Alguém pode lançar alguma luz sobre isso?
Bem, você poderia tentar executar o Perfmon e o SQL Profiler para obter mais informações sobre isso. Mas por favor nos conte um pouco mais sobre a configuração da sua unidade, em primeiro lugar. Você diz que tem 12 unidades divididas em 4 partições. Isso significa que você criou uma grande matriz RAID e a dividiu em 4 partições reais no nível do sistema operacional, ou criou 4 contêineres RAID, cada um com uma partição do sistema operacional? O primeiro é uma boa receita para um mau desempenho.
O IIRC, a única edição do SQL Server 2005 que limita as conexões por qualquer motivo, é o Express e apenas acelera quando parece "muitas" conexões simultâneas. É improvável que alguém instale o Express em um servidor robusto ou que um aplicativo de console de thread único tenha muitas conexões simultâneas.
Se as suas consultas não forem paralelizadas, cada consulta será executada apenas em um desses oito núcleos (2x4) de máquinas, efetivamente desperdiçando os outros sete núcleos.
Sem nenhum outro gargalo (IOW, todos os dados que suas consultas precisam são armazenados em cache na RAM e não há consultas de bloqueio de outra coisa), suas consultas usarão 100% de um núcleo. Um "valor do núcleo" de carga no seu sistema é de 12,5%. Isso é próximo do que você vê, se você adicionar um pouco de atividade de disco.
Com o servidor antigo atingindo 60%, pode ser que o servidor antigo tenha paralelizado (pelo menos algumas) consultas e o novo não paralelize nenhuma consulta, por algum motivo.
Eu usaria o Perfmon para examinar a carga do processador por núcleo. Meu palpite é que você vai descobrir que um deles está em 100%, ou muito próximo a ele. Você pode achar que o núcleo "ocupado" muda de um para outro. Se todos os núcleos estiverem igualmente ocupados, algo estranho está acontecendo. Nesse caso, eu definitivamente gostaria de procurar por esperas no arquivo de banco de dados I / O. Existe um DMV para isso.
Eu também usaria o SSMS para examinar os planos de consulta por pelo menos uma amostra das consultas que o aplicativo executa. Às vezes, as coisas simplesmente surgem em você ("Ei, onde foi esse índice? Pensei em colocá-lo de volta após o upgrade", ou algo assim).
Para resumir:
Tags sql-server-2005