O Windows O / S tamanho arquivo de paginação apropriado para SQL Server

votos
16

Será que algum sabe uma boa regra de ouro para o tamanho do arquivo de paginação apropriado para um servidor em execução SQL Server Windows 2003?

Publicado 05/08/2008 em 18:07
fonte usuário
Em outras línguas...                            


8 respostas

votos
11

Com todo o respeito ao Remus (a quem eu respeito muito), eu discordo. Se o seu arquivo de página é grande o suficiente para suportar um despejo completo, ele irá realizar um despejo completo de cada vez. Se você tem uma grande quantidade de RAM, isso pode causar um minúsculo pontinho para se tornou uma grande interrupção.

Você não quer que seu servidor ter que escrever 1 TB de RAM para o disco se houver um problema transitório de uma só vez. Se há um problema recorrente, você pode aumentar o arquivo de página para capturar um despejo completo. Eu esperaria para fazer isso até que tenha sido isntructed pelo PSS (ou outra pessoa qualificada para analisar um despejo completo) pedir-lhe para capturar um despejo completo. Uma porcentagem extremamente pequena de DBAs sabem como analisar um despejo completo. Um mini-dump é sufficent para solucionar a maioria dos problemas que surgem de qualquer maneira.

Além disso, se o servidor está configurado para permitir uma descarga completa 1 TB e uma questão recorrente ocorre, quanto espaço livre no disco que você recomendaria ter na mão? Você poderia preencher um SAN inteira em um único fim de semana.

A página de arquivo 1.5 * RAM era a norma nos dias em que você era 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 no tamanho padrão do Windows e configurações em todos os servidores de produção (exceto para um servidor SSAS que está enfrentando pressão de memória).

E apenas para esclarecimento, eu tenho trabalhado com servidores que variam de 2 GB de RAM e 2 TB de RAM. Depois de mais de 11 anos, eu só tive que increae o arquivo de paginação para capturar um despejo completo uma vez.

Respondeu 05/10/2011 em 22:39
fonte usuário

votos
10

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

Quando um processo pede MEM_COMMIT memória através VirtualAlloc / VirtualAllocEx, o tamanho solicitado precisa ser reservado no arquivo de paginação. Isto era verdade no primeiro sistema Windows NT, e ainda é verdade hoje veja Gerenciando a Memória Virtual no Win32 :

Quando a memória está comprometida, páginas físicas de memória são alocados e espaço é reservado em um arquivo de paginação .

Nua alguns casos estranhos extremos, SQL Server irá sempre pedir páginas MEM_COMMIT. E dado o fato de que o SQL usa um gerenciamento de memória dinâmica política que reserva antecipadamente tanto pool de buffer possível (reservas e compromete em termos de VAS), SQL Server irá solicitar no arranque uma enorme reserva de espaço no arquivo de paginação. Se o arquivo de paginação não é propriamente erros porte 801/802 começarão a aparecer no arquivo de log de erros de SQL e operações.

Isso sempre causa alguma confusão, como administradores assumem erroneamente que um grande RAM elimina a necessidade de um arquivo de paginação. Na verdade, o contrário acontece, uma grande RAM aumenta a necessidade de arquivo de paginação, só porque do funcionamento interno do gestor de memória do Windows NT. O arquivo de paginação reservado é, felizmente, nunca usado.

Respondeu 22/11/2009 em 23:11
fonte usuário

votos
3

Segundo a Microsoft, "como a quantidade de RAM em um computador aumenta, a necessidade de um arquivo de página diminui." O artigo, em seguida, passa a descrever como usar registos de desempenho para determinar o quanto do arquivo de paginação está realmente sendo usado. Tente definir o seu arquivo de paginação para a memória do sistema 1.5X para começar, em seguida, fazer o acompanhamento recomendado e fazer ajustes de lá.

Como determinar o tamanho do arquivo de página apropriado para versões de 64 bits do Windows

Respondeu 03/08/2010 em 19:58
fonte usuário

votos
2

Fomos recentemente ter alguns problemas de desempenho com um dos nossos SQL Server que não foram capazes de completamente estreita para baixo, e realmente usado um dos nossos bilhetes de suporte da Microsoft para tê-los ajudar a solucionar problemas. O tamanho do arquivo de paginação ideal para usar com SQL Server surgiu, ea recomendação da Microsoft é que seja 1 1/2 vezes a quantidade de RAM .

Respondeu 10/09/2009 em 06:05
fonte usuário

votos
2

Quanto maior, melhor até do tamanho do conjunto de trabalho do aplicativo onde você vai começar a entrar em retornos decrescentes. Você pode tentar encontrar isso lentamente aumentando ou diminuindo o tamanho até ver uma mudança significativa nas taxas de acerto de cache. No entanto, se o cache taxa de acerto é superior a 90% ou mais provavelmente você está OK. Geralmente, você deve manter um olho sobre isso em um sistema de produção para se certificar de que não se sobrepôs à sua alocação de memória RAM.

Respondeu 23/12/2008 em 15:45
fonte usuário

votos
1

Depois de muita pesquisa nossos servidores SQL dedicados executando Enterprise x64 no Windows 2003 Enterprise x64 não têm nenhum arquivo de paginação.

Simplesmente, o arquivo de paginação é um cache para arquivos que é gerenciado pelo sistema operacional, e SQL tem seu próprio sistema de gerenciamento de memória interna.

O artigo MS referenciada não se qualificar que o conselho é para o sistema operacional em execução out-of-the-box serviços como compartilhamento de arquivos.

Ter um arquivo de página simplesmente sobrecarrega o disco I / O porque o Windows está tentando ajudar, quando somente o sistema operacional SQL pode fazer o trabalho.

Respondeu 24/05/2011 em 13:47
fonte usuário

votos
1

Se você está à procura de alto desempenho, você vai querer evitar paginação completamente, de modo que o tamanho do arquivo de página torna-se menos significativa. Investir em mais memória RAM quanto possível para o servidor DB.

Respondeu 11/08/2008 em 13:22
fonte usuário

votos
0

Neste caso, a recomendação normal 1,5 vezes total de RAM física não é a melhor. Esta recomendação muito geral é fornecido sob a suposição de que toda a memória está sendo usado por processos "normais", que podem geralmente têm suas páginas menos utilizadas movida para o disco sem gerar problemas de desempenho enorme para o processo de candidatura a memória pertence.

Para os servidores que executam o SQL Server (geralmente com grandes quantidades de RAM), a maior parte da RAM física está comprometida com o processo de SQL Server e deve ser (se configurado corretamente) bloqueado na memória física, impedindo que ele seja paginada para o arquivo de paginação . SQL Server gerencia a sua própria memória muito cuidado com desempenho em mente, usando uma grande parte da RAM alocados para o seu processo como um cache de dados para reduzir disco I / O. Não faz sentido para a página fora aqueles dados páginas de cache para o arquivo de paginação, como o único propósito de ter que os dados na RAM, em primeiro lugar é reduzir disco I / O. (Note-se que o sistema operacional Windows também usa memória RAM disponível da mesma forma como cache de disco para acelerar a operação do sistema.) Uma vez que o SQL Server já administra seu próprio espaço de memória, este espaço de memória não deve ser considerado "pageable",

Em relação ao MEM_COMMIT mencionado por Remus, a terminologia é confusa porque na linguagem de memória virtual, "reservado" nunca se refere a alocação real, mas para prevenir o uso de um espaço de endereço (espaço não físico) por outro processo. Memória disponível para ser "comprometido" é basicamente igual à soma de RAM e arquivo de paginação tamanho físico, e fazendo um MEM_COMMIT apenas diminui a quantidade disponível no pool comprometido. Ele não alocar uma página correspondente no arquivo de paginação na época. Quando uma página de memória comprometida é realmente escrito para, que é quando o sistema de memória virtual irá alocar uma página de memória física e possivelmente bater outra página de memória RAM física para o arquivo de paginação. Veja MSDN função VirtualAlloc referência.

O sistema operacional Windows mantém o controle de pressões de memória entre processos de aplicação e seu próprio mecanismo de cache de disco e decide quando deve bater páginas não-bloqueado memória do físico para o arquivo de paginação. O meu entendimento é que ter um arquivo de paginação que é muito grande em comparação com o espaço real não-bloqueado de memória pode resultar no Windows overzealously paginação fora de memória de aplicativo para o arquivo de paginação, resultando em aquelas aplicações que sofrem as consequências de erros de página (desempenho lento).

Enquanto o servidor não está executando outros processos de memória com fome, um tamanho de arquivo de paginação de 4 GB deve ser suficiente. Se você tiver configurado o SQL Server para permitir que páginas de bloqueio na memória, você também deve considerar a criação configuração de memória máxima do SQL Server para que ele deixa alguma RAM física disponível para o sistema operacional para si e para outros processos.

802 erros no SQL Server indicam que o sistema não pode cometer mais páginas para o cache de dados. Aumentar o tamanho do arquivo de paginação só irá ajudar nesta situação na medida em que o Windows é capaz de página fora de memória de processos não-SQL Server. Permitindo memória do SQL Server para crescer no arquivo de paginação nesta situação pode se livrar das mensagens de erro, mas é contraproducente, devido ao ponto anterior sobre a razão para o cache de dados em primeiro lugar.

Respondeu 04/04/2014 em 00:51
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more