Como o SQL Server oferece suporte a NUMA

Agrupamento de CPUs comuns

O SQL Server agrupa os agendadores para mapear o agrupamento de CPUs, baseado no limite de NUMA de hardware exposto pelo Windows. Por exemplo, uma caixa de 16 modos pode ter 4 nós NUMA, cada nó com 4 CPUs. Isso permite uma localidade maior de memória para aquele grupo de agendadores quando são processadas tarefas no nó. Com o SQL Server você pode subdividir as CPUs associadas a um nó NUMA de hardware em vários nós de CPU. Isso é conhecido como NUMA de software. Normalmente, você subdividiria as CPUs para particionar o trabalho entre os nós de CPU. Para obter mais informações sobre NUMA de software, consulte Compreendendo o Non-uniform Memory Access.

Quando um thread em execução em um nó NUMA de hardware específico aloca memória, o gerenciador de memória do SQL Server tenta alocar memória da memória associada ao nó NUMA da localidade de referência. Da mesma forma, são distribuídas páginas de pool de buffers nos nós NUMA de hardware. É mais eficiente para um thread acessar memória de uma página de buffer alocada na memória local que acessá-la da memória externa. Para obter mais informações, consulte Aumentando e reduzindo o pool de buffers no NUMA.

Cada nó NUMA (NUMA de hardware ou NUMA de software) tem uma porta de conclusão de E/S associada, usada para manipular a E/S da rede. Isso ajuda a distribuir a manipulação de E/S de rede para várias portas. Quando uma conexão de cliente for feita no SQL Server, ela será associada a um dos nós. Serão processadas todas as solicitações de lote desse cliente naquele nó.

Sempre que a instância do SQL Server for iniciada em um ambiente de NUMA, o log de erros do SQL conterá mensagens informativas que descreverão a configuração de NUMA.

Como o SQL Server mapeia nós NUMA de software para nós NUMA de hardware

O NUMA de software é definido uma vez para todas as instâncias SQL Server no computador, portanto, as várias instâncias do Mecanismo de Banco de Dados vêem os mesmos nós NUMA de software. Cada instância do Mecanismo de Banco de Dados usa a opção affinity mask para selecionar as CPUs apropriadas. Cada instância usará quaisquer nós NUMA de software associados a essas CPUs.

Ao iniciar, o Windows aloca memória para o sistema operacional do hardware NODE 0. Conseqüentemente, o hardware NODE 0 tem menos memória local disponível para outros aplicativos que os outros nós. Esse problema é acentuado quando existe um cache de arquivo de sistema grande. Quando o SQL Server é iniciado em um computador com mais de um nó NUMA, ele tenta iniciar em um nó NUMA diferente de NODE 0 de forma que suas estruturas globais possam ser alocadas na memória local. Para configurar NUMA de software, consulte Como configurar o SQL Server para usar o soft-NUMA.

Como as conexões são atribuídas a nós NUMA

TCP e VIA podem relacionar conexões para um ou mais nós NUMA específicos. Quando não relacionados, ou ao conectá-los com pipes nomeados ou memória compartilhada, as conexões são distribuídas para nós NUMA em uma base de rodízio. Em um nó NUMA, a conexão é executada no agendador menos carregado naquele nó. Devido à natureza de rodízio da atribuição de conexões novas, é possível que todas as CPUs dentro de um nó estejam ocupadas enquanto outro nó esteja ocioso. Se você tiver poucas CPUs (por exemplo, 2) e observar grandes desequilíbrios de agendamento por causa de lotes de execução longa, como carregamento em massa, poderá ter um desempenho melhor se desativar o NUMA. Para obter mais informações, consulte Como mapear portas de TCP/IP para nós NUMA.

Limitações da versão do SQL Server

O SQL Server 2000 do Service Pack 3 não inclui suporte especial para NUMA; porém, o Service Pack 4 tem algumas otimizações de NUMA limitadas. O SQL Server 2005 tem muitas melhorias significativas, e os usuários de NUMA são incentivados a atualizar o SQL Server 2005 para aproveitar a arquitetura NUMA ao máximo.

Consulte também

Conceitos