Tamanho de arquivo de página recomendado para o SQL 2008R2 no Windows 2008R2

Este artigo da Microsoft - Como determinar o tamanho do arquivo de paginação apropriado para versões de 64 bits do Windows Server 2008 e ou Windows 2008 R2 fornece orientações para calcular o tamanho do arquivo de paginação para Windows 2008 e Windows 2008R2 de 64 bits. Isso sem dúvida funciona bem para servidores de uso geral. Gostaria de saber qual é a orientação para o SQL Server 2008R2 em execução no Windows 2008 / R2 de 64 bits?

Estou presumindo que queremos que o mínimo de dados de memória esteja atingindo o arquivo de paginação, caso contrário, o SQL pode estar atingindo o disco duas vezes para obter dados. O SQL Server permite que os dados na memória cheguem ao arquivo de paginação? Procurei nos Manuais Online do SQL Server 2008 R2, mas ainda não encontrei nenhuma menção ao uso do arquivo de paginação.

Aqui está um cenário de uso potencial: dado um servidor físico com 64 GB de RAM, um arquivo de paginação é necessário para todos os 64 GB de RAM? Devemos prepará-lo para 96 GB de arquivo de paginação? Isso parece um pouco excessivo para um único arquivo. Sei que o senso comum é que o Windows associa o arquivo de paginação à memória na tentativa de facilitar a troca de aplicativos na RAM, mas isso é verdade? Um arquivo de paginação com menos de 64 GB prejudicará o desempenho aqui?

— Kev
fonte

Respostas:

Não há configurações especiais para o SQL Server que usem apenas memória física normalmente

Basta fazer o que a MS diz para o Windows e é isso

Ah, e compre mais memória RAM de qualquer maneira enquanto somos um assunto ... ;-)

— gbn
fonte

Olhe para dentro lock pages in memory. Dessa forma, você pode dar preferência à sua conta de serviço SQL para usar a RAM disponível em vez de paginar no disco. Para ler mais sobre bloquear páginas na memória, verifique este link . Um trecho a seguir:

A opção Bloquear páginas na memória da política do Windows está desativada por padrão. Esse privilégio deve estar ativado para configurar o AWE (Address Windowing Extensions). Essa política determina quais contas podem usar um processo para manter os dados na memória física, impedindo que o sistema pagine os dados para a memória virtual no disco. Em sistemas operacionais de 32 bits, definir esse privilégio quando não estiver usando o AWE pode prejudicar significativamente o desempenho do sistema. O bloqueio de páginas na memória não é necessário em sistemas operacionais de 64 bits.

Teste este recurso antes de usar em seus sistemas.

— StanleyJohns
fonte

'Bloquear páginas na memória' talvez possa ser melhor descrito como uma salvaguarda, para impedir que a memória SQL seja paginada pelo sistema operacional. support.microsoft.com/kb/918483

— Mark Storey-Smith

Sim, para 64 GB de RAM, você precisa de pelo menos um arquivo de troca de 64 GB (recomenda-se 96 GB). Não por causa da troca potencial, mas por causa do design do Gerenciador de Memória do Windows. Eu escrevi sobre esse problema antes no tamanho do arquivo de paginação do sistema em máquinas com grande RAM :

Quando um processo solicita MEM_COMMITmemória via VirtualAlloc/ VirtualAllocEx, o tamanho solicitado precisa ser reservado no arquivo de paginação. Isso foi verdade no primeiro sistema Win NT e ainda é verdade hoje, consulte Gerenciando a memória virtual no Win32 :

Quando a memória é confirmada, as páginas físicas da memória são alocadas e o espaço é reservado em um arquivo de paginação.

A alternativa seria algo como o oom_killer .

Siga a recomendação, às vezes as coisas são um pouco mais complexas do que parecem. E eu nem toquei nas complicações trazidas pelo AWE e no privilégio das páginas de bloqueio ...

— Remus Rusanu
fonte

Muito interessante ... Como isso funciona quando você define um arquivo de troca menor que a RAM na máquina? Se, de fato, precisamos reservar o espaço no arquivo de paginação para cada alocação de memória, não poderíamos usar mais do que a memória do tamanho do arquivo de paginação? Não sei se é assim que funciona na prática.

— Shlomoid 7/08

É exatamente assim que funciona na prática. Uma região VA comprometida deve ser apoiada por reserva de troca real. Uma região VA reservada não precisa ser, mas o SQL Server praticamente nunca solicita reservas não confirmadas.

— Remus Rusanu

Eu não acho que isso esteja correto. Meu entendimento de várias fontes, como os livros do Windows Internals, é que o espaço de endereço virtual comprometido deve ser apoiado por algo físico , seja o arquivo de paginação ou a RAM. Portanto, se você tentar confirmar a memória virtual> ([Memória física que o Windows vê] + [Tamanho do arquivo de paginação]), você receberá a infame mensagem de erro "Seu sistema está com pouca memória virtual". Mark Russinovich fala sobre isso na seção "memória comprometida" aqui .

— James L

Eu acho que você pode confirmar para si mesmo que as regiões VA comprometidas não precisam ser apoiadas por reservas de troca apenas inicializando um sistema sem arquivo de paginação e confirmando que o Windows é iniciado e, portanto, deve haver mais de 0 bytes de VAS comprometido.

— James L

Esta postagem está errada - é perfeitamente possível executar sem um arquivo de paginação se você tiver mais memória do que seus requisitos de confirmação máxima. Isso significa que você não pode escrever despejos de memória no entanto.

— Steve365