none
Como fazer o SQL Server 2005 x64 utilizar todos os núcleos disponíveis de um servidor? RRS feed

  • Pergunta

  • Olá, pessoal

    Há algum tempo utilizo o recurso FullText do SQL 2005 x64; até o momento obtive excelentes resultados, pois a pesquisa é incrivelmente rápida e de total confiança.

     

    A quantidade de pesquisas realizadas a cada “busca”, porém, estava girando em torno de 300.000 comparações. Percebi então que o desempenho começou a cair. Li recentemente em um fórum que quando o número de comparações passa de 100.000 o desempenho tende mesmo a cair, isso é verdade?

     

    Mesmo não tendo a confirmação dessa dúvida, mas com a comprovação de uma queda no desempenho, providenciei a compra de um novo servidor Dell com 02 processadores Xeon Quadri-Core (08 núcleos), 16 Gb de RAM e dois HD’s SASu de 146Gb configurado com RAID1.

     

    Após a instalação do SQL Server 2005 x64, disparei a execução da “busca” (uma SP que roda no próprio banco) e percebi que todo o processamento ocorre em apenas um dos oito núcleos disponíveis.

     

    Li e reli os livros “SQL Server 2005 Administração & Desenvolvimento”, de Junior Battisti, e o “SQL Server 2005 - Guia de Bolso do Administrador”, de William R. Stanek. No guia de bolso, obtive várias dicas de como mudar as configurações de afinidades dos núcleos, da prioridade de I/O, de habilitação do gerenciamento AWE de memória, de habilitação do paralelismo de planos de execução, etc.

     

    Mas hoje tenho um pouco mais de 1.000.000 de combinações rodando nessa minha única SP e até o momento não obtive uma solução para fazê-la executar utilizando todos os oito núcleos disponíveis em meu novo servidor.

     

    Alguém saberia me informar como instruo o SQL Server 2005 x64 para utilizar todos os oito núcleos disponíveis neste meu novo servidor?

     

    Ps. Está instalado o Windows 2008 x64 com SQL 2005 x64.

    segunda-feira, 25 de maio de 2009 20:27

Todas as Respostas

  • Boa Noite,

    O SQL Server por padrão irá utilizar todos os núcleos disponíveis. A única razão para que isso não aconteça é caso durante a instalação um número de processadores menor tenha sido escolhido ou então a configuração foi alterada.

    Toda vez que uma operação é submetida ao SQL Server, ele avalia o seu custo antes de executá-la e acima de um certo patamar, ele opta por verificar a possibilidade de utilizar mais núcleos para concluir a operação de forma paralela. Normalmente esse processo  é muito bem feito e não necessita de intervenções (você pode baixar o custo de avaliação para planos em paralelo mas os resultados podem ser piores que melhores).

    Se o SQL Server usa um núcleo para executar a sua consulta há duas possibilidades possíveis:

    Ele não acha que usar mais núcleos irá acelerar o processo
    Dizem que se você tem uma equipe com seis pessoas e adicionar mais seis para ajudar, talvez os resultados piorem. Pode ser que apenas seis pessoas desempenhem uma tarefa a um custo benefício melhor que doze pessoas. O SQL Server também faz essa avaliação, pois, se alocar mais processadores para uma determinada tarefa, pode ser que outras tarefas fiquem esperando. Vale a pena lembrar que se a tarefa não for CPU Bound, mas IO Bound por exemplo, ou seja, gaste muito mais tempo recuperando dados do discos, adicionar mais processadores não vai acelerar a recuperação de páginas do disco. O máximo que irá acontecer é dois processadores esperando

    Ele determina (By Design) que a operação deve ser serial
    Existem determinadas tarefas que (By Design) não podem ser executadas com mais de um nucleo simultaneamente. A reindexação de uma partição (no SQL Server 2005) é um desses exemplos. Mesmo que existam vários núcleos disponíveis, a reindexação de uma partição será executada de forma serial e não adiantará utilizar mais processadores.

    Eu sugiro que você avalie o plano de execução, verifique o resultado da Statistics IO e Statistics Time para realmente verificar se o CPU é o culpado da sua perda de desempenho. Talvez não seja melhorando a utilização da CPU (se for o caso) que você consiga resolver o problema.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Como executar tarefas ao iniciar o SQL Server ?
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!570.entry
    Classifique as respostas. O seu feedback é imprescindível
    segunda-feira, 25 de maio de 2009 21:31
  • Olá Gustavo, 
    blz meu chara? rsrs

     

    Seguinte, a instalação do SQL Server foi realizada por mim com os dois núcleos já instalados no servidor.

     

    Com relação a "ele não achar que precisa de mais núcleos para acelerar o processo", como posso fazer para comprovar isso? Preciso desta informação para saber para onde "correr", isto é, será preciso re-desenvolver minha SP no banco? ou precisarei de alguma forma ir re-configurando o SQL Server para conseguir uma melhor performance.

     

    Com relação ao "By Design", minha SP esta abrindo um cursor com mais de 1.000.000 de registros como já citei e em seguida realiza um while executando o método CONTAIN do FullText, só isso! Pergunto: algum desses dois processos é executado pelo SQL Server de forma serial?, isto é, por padrão utiliza apenas 01 núcleo?

     

    Como avalio o plano de execução da Statistics IO e Statistics Time utlizando uma SP?, pois não consigo depurá-la. É o Profile/Tunning? Qual opção?

     

    Bom, como eu disse, é apenas uma SP, mais nada, se não for melhorando a CPU como fiz, você tem alguma outra solução pra mim?

     

    Obrigado por hora,

    T+
    =)

    segunda-feira, 25 de maio de 2009 22:28
  • Olá Chará,

    Um cursor com mais de 1.000.000 de registros já é naturalmente lento e demandará um excessivo uso de I/O e memória. Eu diria que em um cenário desses talvez o CPU seja o menor dos seus problemas. O uso de múltiplos núcleos para resolver um comando pode acontecer com consultas mais complexas e com demaseado uso de cálculos. Não acho que o cursor por si só possa se paralelizar (a menos que a consulta que ele emita tenha essa necessidade).

    Também não faz sentido tentar descobrir se o SQL Server está certo ou errado no uso dos núcleos (provavelmente não está). Acho muito mais proveitoso tentar concentrar esforços em uma outra maneira de não utilizar um cursor para varrer 1.000.000 de linhas.

    Para avaliar o tempo gasto e o IO gasto, você deve utilizar os comandos SET STATISTICS TIME ON e SET STATISTICS IO ON. Só que a resposta no seu cenário já é bem previsível.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Como executar tarefas ao iniciar o SQL Server ?
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!570.entry
    Classifique as respostas. O seu feedback é imprescindível
    terça-feira, 26 de maio de 2009 13:48
  • Chará,
    blz?

    Então, eu queria realmente confirmar se o problema era CPU, pelo visto vejo que não é.

    Bom, agora veja se você sabe me dizer porque mesmo tendo 16Gb de RAM ele não utiliza mais do que 3Gb. Ele tem esse comportamento mesmo eu setando a configuração mínima como 0, a máxima como 10Gb ou setando a mínima para 10Gb e a máxima para 10Gb, habilitando ou não o AWE, etc. Seguindo o raciocínio que o meu problema atual pode ser o cursor que esta abrindo mais 1.000.000 registro, o SQL Server não deveria utilizar o máximo de memória disponível?, ou também a quantidade de memória não irá resolver?

    Estou chegando a conclusão que meu novo servidor não resolverá meu problema rsrs.

    []s

    terça-feira, 26 de maio de 2009 15:30
  • amigo. pelo que li nos seus posts a unica questão que pode explicar seu gargalo é a versão do seu SQL
    verifique, se for a standard ela realmente limita a 1 nucleo e ai será o caso de executar um update para um versão mais completa.
    veja bem. a standard limita não somente a quantidade de nucleos em operação mas também a memória ram disonibilisada entre outras questões.

    • Sugerido como Resposta Cristiano.PMG sábado, 7 de novembro de 2009 13:58
    sábado, 7 de novembro de 2009 13:58