Quais são os perigos de usar o paralelismo no sql server?

4

Em um cliente nosso, o servidor sql é configurado para 1 para o grau de paralelismo. O servidor tem 8 cpu's, então o que seria motivo para limitar este grau a 1?

    
por Lieven Cardoen 20.03.2010 / 10:42

3 respostas

4

O SQL Server já colocará várias consultas em várias CPUs (se licenciadas). Em consultas maiores, ele pode interromper a consulta única em vários encadeamentos (e potencialmente CPUs), permitindo o paralelismo.

Você deve definir o grau de paralelismo para corresponder ao tamanho geral de consultas grandes. Se você estiver constantemente acessando o banco de dados com uma consulta de junção de 72, configure-a para o mesmo número de CPUs que o servidor possui (ou está licenciado para). Se você constantemente acertar o servidor com pequenas consultas, ou você não quiser que consultas maiores ocupem todas as CPUs, defina isso para um número mais conservador (como 1).

Estas são diretrizes muito genéricas, mais informações da MS em Processamento Paralelo de Consultas e Configuração do nível de paralelismo .

    
por 20.03.2010 / 15:35
1

O cenário que vejo frequentemente é uma consulta causando um impasse consigo mesmo quando executado com paralelismo; isso geralmente é um sinal de indexação incorreta ou uma atualização / exclusão mal escritas, mas algumas pessoas usam a rota rápida e suja e desativam o paralelismo para evitar os impasses.

    
por 20.03.2010 / 16:38
0

Veja como eu responderia, com base puramente na minha experiência e conhecimento limitado:

O SQL Server parece tomar uma decisão sobre usar o paralelismo em um plano de consulta, principalmente com base em se isso ajudará ou não uma única execução dessa consulta a retornar mais rápido. Na maioria das vezes, essa avaliação é bastante precisa; ocasionalmente, o otimizador pode fazer uma escolha que não seja tão boa. Mas em ambos os casos, não leva em conta o que mais está acontecendo com esse servidor. Em particular, se você estiver executando um servidor que está manipulando um grande número de solicitações de lote por segundo, e algumas partes significativas desses lotes estiverem sendo paralelizadas, será possível encontrar a privação de encadeamentos. Ou seja, os agendadores estão todos ocupados processando as solicitações paralelizadas ou esperando por elas e nada pode ser processado. Isso pode se manifestar como falta de resposta do SQL Server. Observe que você pode não necessariamente ver 100% de utilização da CPU. Não é da CPU que você está fora, é agendadores disponíveis. Normalmente, você espera muito CX_PACKET e, possivelmente, THREADPOOL, e uma contagem de tarefas executável média entre agendadores acima de 1.

Em algumas lojas, a carga de trabalho é tão complexa que uma decisão estratégica é tomada para eliminar completamente o paralelismo para evitar completamente esse problema. Isso pode funcionar muito bem em algumas situações, até onde sei, embora tenha falado com engenheiros da Microsoft que achavam que era uma ideia equivocada e essencialmente ruim. Nesse cenário, você não pode acelerar uma consulta com paralelismo, portanto, o tempo de execução geralmente é proporcional à utilização da CPU. Isso pode ser uma troca aceitável, especialmente se a maioria das suas solicitações em lote forem pequenas.

    
por 20.02.2014 / 19:00

Tags