/ 3GB no servidor win2k3 com 6gb de RAM e PAE

2

No momento, estamos avaliando a adição da opção / 3gb a alguns de nossos servidores para aumentar o memeory disponível para um dos processos em execução (que é compilado com o conjunto de sinalizadores IMAGEFILELARGEADDRESSAWARE) que está batendo no limite de 2 gb.

No entanto, o que estou tentando entender é como a memória é dividida entre o kernel e os processos do usuário em um servidor com > 4gb de RAM. De acordo com o doco, o Windows irá dividir a memória de 2gb / 2gb entre o kernel e os processos do usuário em um sistema de 4GB. Quando você ativa / 3gb em um servidor, a memória é dividida em 1gb / 3gb.

O que eu quero saber é como a memória é dividida em um servidor com 6GB de memória RAM e PAE habilitado? O kernel ainda fica restrito a 1gb ??

Felicidades Sam

    
por Sam 23.07.2009 / 07:49

7 respostas

2

Eu pensei em postar um acompanhamento para os outros tentarem consolidar as informações em um único post (com base no que eu aprendi e nas outras informações já postadas).

PAE:

O PAE permitirá que um servidor Windows de 32 bits use ou tenha mais de 4 GB de RAM, com o máximo dependente da versão das janelas que você está executando (a Wikipedia tem uma boa referência aqui )

Uma coisa a ser observada é que, se você tiver o Data Execution Prevention (DEP) ou o NoExecution (NX) ativado, isso ativará o PAE sem ter que ativá-lo explicitamente no boot.ini.

Em resumo, o PAE não tem efeito sobre a quantidade de memória que um único processo de 32 bits pode acessar. Isso afeta apenas a quantidade total de janelas de memória que podem 'ver' e usar (para que você possa ter 2 processos cada usando 2 GB, com o Windows usando 2 GB em um sistema de 6 GB)

3 GB:

Em primeiro lugar, quando estou falando sobre a memória disponível para um único processo de 32 bits, estou me referindo aos processos espaço de endereço virtual . Para um processo de 32 bits em um sistema operacional Windows de 32 bits, isso é limitado a 4 GB.

Em um sistema sem a opção / 3GB, os 4GB de espaço de endereço virtual são divididos em 2GB / 2GB entre o processo em execução e o kernel do Windows.

Quando você ativa o comutador de 3 GB, a divisão no espaço de endereço virtual é alterada para 3 GB / 1 GB. Isso permite que o processo use mais memória, às custas da memória do kernel. Observe: o Windows só permitirá que um processo use mais 2 GB ou memória se o executável tiver sido compilado com o sinalizador IMAGEFILELARGEADDRESSAWARE definido.

Agora, como foi mencionado em outros posts, a penalidade de usar o switch de 3GB é que o kernel tem menos memória para trabalhar. E uma das principais vítimas da memória reduzida é o número de Entradas da Tabela de Páginas (PTEs) disponíveis. Uma tabela de páginas é a estrutura de dados usada pelo Gerenciador de Memória Virtual do Windows para armazenar o mapeamento entre endereços virtuais e endereços físicos na memória. Se você tiver PTEs livres insuficientes, o Windows poderá não alocar memória para um processo quando solicitado, mesmo que o processo ainda não tenha esgotado seu espaço de endereço.

A contagem livre de PTEs pode ser medida usando perfmon (\ Memória \ Entradas Livres de Tabela de Páginas do Sistema). Qualquer coisa abaixo de 5000 é considerado crítico pela Microsoft. Como exemplo, nos servidores mencionados no post original, sem o switch de 3GB e com o processo em execução, a contagem de PTE livre era de cerca de 160k. Depois de habilitar 3 GB, mas antes do início do processo, o Windows informava 3,5k de PTEs gratuitos (uma redução drástica). Esse número teria caído rapidamente se tivéssemos iniciado o processo.

A maneira de compensar essa mudança drástica é ativar o switch USERVA no boot.ini. Definindo USERVA = 2800, isso move a divisão de 3 GB / 1 GB na memória e "devolve" aproximadamente 250 MB de volta ao kernel para seu uso. Por exemplo, depois de definir USERVA = 2800 no boot.ini em nosso sistema, a contagem de PTEs livres agora fica em torno de 60k com o processo em execução (muito melhor do que os 3.5k que estávamos vendo).

Mais informações sobre a opção USERVA podem ser encontradas no artigo do Microsoft KB.

Vale ressaltar também que a habilitação do PAE também tem impacto na contagem gratuita de PTE. A opção PAE faz com que cada entrada PTE use o dobro do espaço de endereço virtual normal atribuído.

Espero que isso forneça um resumo conciso das informações para qualquer pessoa que esteja olhando para uma data posterior.

Felicidades Sam

    
por 13.08.2009 / 08:52
1

Ouça este episódio do RunAs Radio.

O foco principal deste episódio cobre o óbvio "por que 64bits é melhor" - no entanto, o convidado entra em "por que / 3GB deve ser evitado". Basicamente, reduz significativamente o número de entradas disponíveis para o sistema operacional - tanto para que o sistema operacional se torne instável.

Em um nut shell - Pode ser apropriado para um servidor que está atendendo uma única função (como um controlador AD ou SQL Server), no entanto, ele deve ser evitado em um sistema que esteja fornecendo várias funções. No final do dia, "sua milhagem pode variar" - lembre-se de que / 3GB pode tornar o sistema operacional instável.

    
por 29.07.2009 / 06:42
1

Você pode querer considerar um sistema operacional de 64 bits mesmo que o aplicativo tenha apenas 32 bits. No Windows x64, os processos de 32 bits recebem 4 GB de RAM, não 2 GB.

Consulte a seção sobre memória virtual de KB294418 para obter detalhes.

    
por 12.08.2009 / 07:28
0

Pelo que sei, o comutador PAE permite acesso à memória acima de 4 GB para os aplicativos no servidor. De acordo com essa technote , os aplicativos realmente não conhecem essa troca de memória, tudo é tratado no Windows. Acho que usar o switch / 3GB no servidor de 6GB limitaria o kernel a 1GB. Outra limitação introduzida pelo uso simultâneo de / 3GB e / PAE é que o servidor não irá endereçar mais de 16GB.

A menos que você esteja tentando aproveitar cada MB de memória para o aplicativo, você pode querer apenas usar / PAE sem / 3GB. Dessa forma, se algum dia a linha aparecer em um total de 24 ou 32 GB de RAM, você não terá que tentar descobrir por que o Windows usa apenas 16 GB.

    
por 23.07.2009 / 08:16
0

No meu sistema anterior, usei a opção / 3GB porque um dos meus aplicativos precisava de muita memória. Recentemente, atualizei para um sistema Vista de 64 bits e atualizei o aplicativo para uma versão de 64 bits, que garante os 12 GB completos que tenho agora. No entanto, outros aplicativos de 32 bits ainda estão limitados aos mesmos 3 GB de memória (ou 2 GB sem o switch) simplesmente porque não podem ver além do tamanho de um ponteiro de endereço. (E nos sistemas de 32 bits, os ponteiros de endereço são de 32 bits ...)

No entanto, a opção / 3GB combinada com mais de 3 GB de RAM ainda é útil, desde que o próprio Windows seja capaz de lidar com ponteiros de endereços maiores. Ele permite que o Windows mantenha mais aplicativos na memória, portanto, troca muito menos para o disco, o que aumenta o desempenho.

O PAE é um truque de hardware em que o processador tem mais alguns pinos para enviar um endereço. Eles aumentaram de 32 pinos (bits) para 36 pinos. Isso permite até 64 GB de RAM para qualquer aplicativo que esteja ciente desses pinos adicionais. A Microsoft faz bom uso disso em seu software de servidor, portanto, o Windows pode suportar até 64 GB. Se o processo que consome muita memória também estiver ciente desses pinos adicionais, ele também pode alocar até 64 GB de RAM. Essa técnica para aplicativos é chamada Extensões de janela de endereço . Obviamente, isso também requer um código especial dentro do aplicativo para processar essa memória e me lembra da era do MS-DOS em que os ponteiros de aplicativos eram limitados a apenas 16 bits (64 KB), mas porque o processador tinha 20 pinos (mais tarde ), você poderia usar ponteiros especiais de 32 bits  para apontar para um endereço ou apenas ficar com os ponteiros de 16 bits mais antigos e ficar limitado a apenas 64 KB. (20 bits é 1024 KB e o DOS usa tudo acima dos 640 KB inferiores, ou 1 GB. 24 bits é 4 GB, o que era popular para os primeiros 80386 processadores como limite superior.)

    
por 23.07.2009 / 10:01
0

Quando leio o excelente post de Mark Russinovich Empurrando os limites do Windows: memória física , sim ... que 1GB de memória disponível para o kernel em uma instalação de 32 bits do Windows com o switch / 3GB persiste mesmo em sistemas com até 128GB de RAM (com suporte em instalações de 32 bits do W2K3 Datacenter).

The maximum 32-bit limit of 128GB, supported by Windows Server 2003 Datacenter Edition, comes from the fact that structures the Memory Manager uses to track physical memory would consume too much of the system's virtual address space on larger systems. The Memory Manager keeps track of each page of memory in an array called the PFN database and, for performance, it maps the entire PFN database into virtual memory. Because it represents each page of memory with a 28-byte data structure, the PFN database on a 128GB system requires about 930MB. 32-bit Windows has a 4GB virtual address space defined by hardware that it splits by default between the currently executing user-mode process (e.g. Notepad) and the system. 980MB therefore consumes almost half the available 2GB of system virtual address space, leaving only 1GB for mapping the kernel, device drivers, system cache and other system data structures, making that a reasonable cut off:*

    
por 29.07.2009 / 06:55
0

Raymond Chen, um dos programadores de shell do Windows da Microsoft, tem uma ótima série de artigos em seu blog sobre o switch / 3GB, PAE, AWE e NX. Eles devem ser leitura obrigatória para qualquer pessoa que tente entender como tudo funciona, como interage e por que, em muitas circunstâncias, provavelmente não é o que você quer:

link

    
por 12.08.2009 / 22:18