Desempenho de páginas bloqueadas v Memória nativa em SQL2005 / 2008 de 64 bits

Question

Entendo que a configuração do privilégio Páginas de bloqueio na memória para a conta de serviço que hospeda os serviços SQL2005 / 2008 em um sistema de 64 bits usa a API do AWE e impede efetivamente que o buffer pool do SQL seja paginado para o disco - aumentando a estabilidade.

Mas se você tem uma caixa dedicada com memória livre suficiente para que você esteja confiante de que a SQL não irá pager - o gerenciamento nativo de memória de 64 bits é mais rápido?

    

Answer 1

A resposta curta é, se usada corretamente , as Páginas de bloqueio na memória podem melhorar o desempenho do SQL Server em sistemas de 64 bits.

A resposta longa nos leva alguns passos para trás.

Primeiro de tudo, você precisa entender que há uma diferença entre paginação e paginação para o disco. Com os sistemas operacionais modernos, a ALL memória é alocada em páginas dentro do VAS (espaço de endereço virtual) . Isso não é uma coisa ruim, é assim que funciona.

Existem dois problemas com a maneira como o SQL Server trabalha com a memória do buffer pool quando Lock Pages não é usado:

Primeiro, é mais caro para alocar memória . Quando um processo é iniciado ou pede mais memória, o sistema operacional cria novas páginas para ele sob demanda. Portanto, normalmente, como o SQL Server é executado, ele estará solicitando, recebendo, liberando páginas conversando com o sistema operacional o tempo todo, o que é caro.

Segundo, o NUMA não funciona muito bem. Suporte NUMA apropriado significa que o aplicativo pode contar com uma página residente na memória física que é a mais próxima do processador no qual o encadeamento está, mas quando o SO está assumindo a paginação, o SQL Server não pode garantir isso. É necessário verificar se há residência NUMA para cada solicitação de página, o que também é caro .

Quando você ativa o bloqueio de páginas na memória, o SQL Server não precisa lidar com nenhum desses problemas para o buffer pool porque ele usa a AWE API para gerenciamento de memória.

Em primeiro lugar, quando ele pede memória, faz isso apenas uma vez e obtém uma lista de páginas do sistema operacional de uma só vez. Então, no futuro, ele pode alocar essas páginas da forma que precisar, sem precisar solicitar o sistema operacional para elas.

Em segundo lugar, porque está bloqueando as páginas do sistema operacional, sabe que as propriedades dessas páginas não serão alteradas . Portanto, se a página for uma página NUMA, ela será colocada no pool de buffers NUMA e não precisará se preocupar em verificar se está na NUMA na próxima vez que verificar.

Você observará esses aprimoramentos à medida que o banco de dados aumentar (quando a alocação de memória ocorrer) e também ao longo do tempo (quando normalmente o SQL Server estaria lidando com o SO para alocação / desalocação de páginas).

Se você quiser mais detalhes, há um excelente artigo técnico sobre isso por Slava Oks, quando ele estava na equipe do SQL Server. Ele também fez uma postagem sobre Perguntas e respostas sobre o assunto em outro excelente artigo sobre < a href="http://blogs.msdn.com/slavao/archive/2005/08/02/446648.aspx"> como o NUMA funciona no SQL Server .

    

Answer 2

Pelo que entendi a configuração Páginas bloqueadas na memória de minhas conversas com a equipe de produto do SQL Server, a única coisa que essa configuração controla é que ela permite que o SQL Server ignore as instruções do sistema operacional para enviar todos os dados para o disco e liberar a memória.

Em circunstâncias normais, ter as páginas bloqueadas na configuração de memória desativada não fará nada de bom ou ruim para você. É a ocorrência estranha em que ter páginas de bloqueio na memória ajudará você. Um exemplo é que havia um bug no Windows 2003 RTM que, ao executar o SQL Server e você iniciou uma sessão de área de trabalho remota no servidor, o sistema operacional informaria ao SQL Server para liberar toda a memória para o disco sem nenhum motivo. Se você tivesse a configuração Bloquear Páginas na Memória habilitada, seu SQL Server ignoraria essa instrução, se você não tivesse essa configuração definida, seu SQL Server liberaria o cache de buffer para o disco conforme as instruções.

Existem outros casos de drivers RAID e unidades HBA com erros que causam o mesmo problema.

Eu falo sobre isso aqui aqui .

    

Answer 3

A minha experiência em qualquer ganho de desempenho é compensada pelo problema que um dia isso vai te morder. Eu diria que, se você tiver um crescimento de dados relativamente lento e poucas mudanças no código do banco de dados, você poderá implementá-lo com eficiência e obter um pequeno benefício. Se, no entanto, o banco de dados for muito usado e, às vezes, for sql pages out, eu diria que não ligá-lo. Como o Pergunte ao Equipe de desempenho afirma:

"Once you have configured your server based on the results of the Performance Monitor analysis, that decision really rests with you."

Ainda não encontrei justificativa para ativá-lo, em qualquer um dos meus sistemas