Tamanho apropriado do arquivo de paginação do sistema operacional Windows para SQL Server

Question

Alguém conhece uma boa regra prática para o tamanho apropriado do arquivo de paginação para um servidor Windows 2003 executando o SQL Server?

Answer 1

Independentemente do tamanho da RAM, você ainda precisa de um arquivo de paginação com pelo menos 1,5 vezes a quantidade de RAM física.Isso é verdade mesmo se você tiver uma máquina com 1 TB de RAM, você precisará de um arquivo de paginação de 1,5 TB no disco (parece loucura, mas é verdade).

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

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

Exceto alguns casos extremos e estranhos, o SQL Server sempre solicitará páginas MEM_COMMIT.E dado o fato de que o SQL usa um Gerenciamento Dinâmico de Memória política que reserva antecipadamente o máximo possível de buffer pool (reservas e compromete em termos de VAS), o SQL Server solicitará na inicialização uma enorme reserva de espaço no arquivo de paginação.Se o arquivo de paginação não tiver o tamanho adequado, os erros 801/802 começarão a aparecer no arquivo ERRORLOG e nas operações do SQL.

Isso sempre causa alguma confusão, pois os administradores assumem erroneamente que uma grande RAM elimina a necessidade de um arquivo de paginação.Na verdade acontece o contrário, uma grande RAM aumenta a necessidade de arquivo de paginação, apenas por causa do funcionamento interno do gerenciador de memória do Windows NT.O arquivo de paginação reservado, esperançosamente, nunca é usado.

Answer 2

Com todo o respeito a Remus (a quem respeito muito), discordo veementemente.Se o seu arquivo de paginação for grande o suficiente para suportar um despejo completo, ele sempre executará um despejo completo.Se você tiver uma quantidade muito grande de RAM, isso pode fazer com que um pequeno problema se torne uma grande interrupção.

Você NÃO deseja que seu servidor precise gravar 1 TB de RAM no disco se houver um problema transitório único.Se houver um problema recorrente, você poderá aumentar o arquivo de paginação para capturar um dump completo.Eu esperaria para fazer isso até que você fosse instruído pelo PSS (ou por alguém qualificado para analisar um dump completo) solicitando que você capturasse um dump completo.Uma porcentagem extremamente pequena de DBAs sabe como analisar um dump completo.Um minidespejo é suficiente para solucionar a maioria dos problemas que surgem de qualquer maneira.

Além disso, se o seu servidor estiver configurado para permitir um dump completo de 1 TB e ocorrer um problema recorrente, quanto espaço livre em disco você recomendaria ter disponível?Você poderia preencher uma SAN inteira em um único fim de semana.

Um arquivo de paginação de 1,5*RAM era a norma na época em que você tinha sorte de ter um SQL Server com 3 ou 4 GB de RAM.Este não é mais o caso.Deixo o arquivo de paginação com o tamanho e as configurações padrão do Windows em todos os servidores de produção (exceto em um servidor SSAS que está enfrentando pressão de memória).

E só para esclarecer, já trabalhei com servidores que variam de 2 GB de RAM a 2 TB de RAM.Depois de mais de 11 anos, só precisei aumentar o arquivo de paginação para capturar um despejo completo uma vez.

Answer 3

De acordo com a Microsoft, "À medida que a quantidade de RAM em um computador aumenta, a necessidade de um arquivo de página diminui". O artigo continua descrevendo como usar logs de desempenho para determinar quanto do arquivo de página é na verdade sendo usado.Tente definir seu arquivo de paginação para 1,5X de memória do sistema para começar, depois faça o monitoramento recomendado e faça os ajustes a partir daí.

Como determinar o tamanho apropriado do arquivo de paginação para versões de 64 bits do Windows

Answer 4

Quanto maior, melhor será o tamanho do conjunto de trabalho do aplicativo onde você começará a obter retornos decrescentes.Você pode tentar descobrir isso aumentando ou diminuindo lentamente o tamanho até ver uma mudança significativa nas taxas de acertos do cache.No entanto, se a taxa de acerto do cache for superior a 90% ou mais, você provavelmente estará bem.Geralmente você deve ficar de olho nisso em um sistema de produção para ter certeza de que ele não ultrapassou sua alocação de RAM.

Answer 5

Recentemente, estávamos tendo alguns problemas de desempenho com um de nossos SQL Server que não conseguimos restringir completamente e, na verdade, usamos um de nossos tíquetes de suporte da Microsoft para que eles ajudassem a solucionar o problema.O tamanho ideal do arquivo de paginação para usar com o SQL Server surgiu, e a recomendação da Microsoft é que ele seja 1 1/2 vezes a quantidade de RAM.

Answer 6

Se você procura alto desempenho, evite completamente a paginação, para que o tamanho do arquivo de paginação se torne menos significativo.Invista no máximo de RAM possível para o servidor de banco de dados.

Answer 7

Depois de muita pesquisa, nossos servidores SQL dedicados executando Enterprise x64 no Windows 2003 Enterprise x64 não possuem arquivo de paginação.

Simplesmente, o arquivo de paginação é um cache para arquivos gerenciados pelo sistema operacional, e o SQL possui seu próprio sistema de gerenciamento de memória interno.

O artigo da MS mencionado não qualifica que o conselho é para o sistema operacional que executa serviços prontos para uso, como compartilhamento de arquivos.

Ter um arquivo de paginação simplesmente sobrecarrega a E/S do disco porque o Windows está tentando ajudar, quando apenas o sistema operacional SQL pode fazer o trabalho.

Answer 8

Nesse caso, a recomendação normal de 1,5 vezes a RAM física total não é a melhor.Esta recomendação muito geral é fornecida sob a suposição de que toda a memória está sendo usada por processos "normais", que geralmente podem ter suas páginas menos utilizadas movidas para o disco sem gerar enormes problemas de desempenho para o processo de aplicativo ao qual a memória pertence.

Para servidores que executam o SQL Server (geralmente com grandes quantidades de RAM), a maior parte da RAM física está comprometida com o processo do SQL Server e deve ser (se configurada corretamente) bloqueada na memória física, evitando que seja paginada para o arquivo de paginação .O SQL Server gerencia sua própria memória com muito cuidado, pensando no desempenho, usando grande parte da RAM alocada para seu processo como cache de dados para reduzir a E/S do disco.Não faz sentido paginar essas páginas de cache de dados para o arquivo de paginação, pois o único propósito de ter esses dados na RAM é reduzir a E/S do disco.(Observe que o sistema operacional Windows também usa RAM disponível de forma semelhante ao cache de disco para acelerar a operação do sistema.) Como o SQL Server já gerencia seu próprio espaço de memória, esse espaço de memória não deve ser considerado "paginável" e não incluído em um cálculo para arquivo de paginação tamanho.

Em relação ao MEM_COMMIT mencionado por Remus, a terminologia é confusa porque no jargão da memória virtual, "reservado" nunca se refere à alocação real, mas à prevenção do uso de um espaço de endereço (não espaço físico) por outro processo.A memória disponível para ser "comprometida" é basicamente igual à soma da RAM física e do tamanho do arquivo de paginação, e fazer um MEM_COMMIT apenas diminui a quantidade disponível no pool confirmado.Isso acontece não aloque uma página correspondente no arquivo de paginação naquele momento.Quando uma página de memória confirmada é realmente gravada, é quando o sistema de memória virtual alocará uma página de memória física e possivelmente transferirá outra página de memória da RAM física para o arquivo de paginação.Veja o MSDN Função VirtualAlloc referência.

O sistema operacional Windows monitora as pressões de memória entre os processos do aplicativo e seu próprio mecanismo de cache de disco e decide quando deve transferir as páginas de memória não bloqueadas do físico para o arquivo de paginação.Meu entendimento é que ter um arquivo de paginação muito grande em comparação com o espaço de memória real não bloqueado pode resultar na paginação excessiva da memória do aplicativo para o arquivo de paginação pelo Windows, fazendo com que esses aplicativos sofram as consequências de falhas de página (desempenho lento).

Contanto que o servidor não esteja executando outros processos que consomem muita memória, um tamanho de arquivo de paginação de 4 GB deve ser suficiente.Se você configurou o SQL Server para permitir o bloqueio de páginas na memória, considere também definir a configuração de memória máxima do SQL Server para que ele deixe alguma RAM física disponível para o sistema operacional para si e para outros processos.

Erros 802 no SQL Server indicam que o sistema não pode confirmar mais páginas para o cache de dados.Aumentar o tamanho do arquivo de paginação só ajudará nessa situação, na medida em que o Windows for capaz de paginar a memória de processos que não sejam do SQL Server.Permitir que a memória do SQL Server cresça para o arquivo de paginação nessa situação pode eliminar as mensagens de erro, mas é contraproducente, devido ao ponto anterior sobre o motivo do cache de dados em primeiro lugar.