通过

Gestão de memória – 3GB e USERVA

  • 项目

Como prometido num dos posts anteriores sobre Gestão de memoria, hoje vamos abordar o switch 3GB e o USERVA

Por vezes deparamo-nos com a presença do /3GB no boot.ini da configuração dos servidores e quando questionados sobre o porquê da presença do mesmo, hum… pois… não obtemos resposta a essa questão :o ou porque já estava configurado anteriormente ou foi outro administrador de sistemas que efectuou essa configuração porque leu alguma documentação que falava sobre melhorias de performance nos servidores etc,.. etc,.. etc,…

Importa pois desmistificar alguns dos mitos à volta do /3Gb:

  • o /3GB não vai permitir que um servidor possa detectar memoria adicional colocada num servidor
  • o /3GB não vai necessariamente melhorar a performance das aplicações que estão nesse mesmo servidor
  • o /3GB não deve ser uma configuração standard em todos os servidores

clip_image002

Então, para que serve exactamente o switch /3GB?

Se nos recordarmos do post anterior sobre gestão de memória, verificamos que o sistema de endereçamento baseado em 32bits se traduz em 4Gb de memória virtual: 2 Gb para Kernel Mode e 2Gb para User mode.

Enquanto que o espaço de Kernel é comum para todas as aplicações, todos os processos (User Mode) têm o seu próprio espaço de 2GB até ao qual podem “crescer”.

Quer isto dizer que uma aplicação user mode pode usar até 2Gb de memoria virtual.

clip_image004

É aqui que entra o /3GB. Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows XP SP2/SP3 e todas as versões do Windows Server 2003 suportam a opção /3GB no boot afim de permitir aumentar o endereçamento de User Mode em 1GB. Esta configuração surgiu da necessidade de algumas aplicações, como servidores aplicacionais de Bases de dados, poderem manter em memoria mais informação do que a permitida com os tradicionais 2GB.

Se nos lembrarmos que continuamos a ter os mesmos 4GB de memoria virtual total, ao aumentar o espaço de user mode para 3GB diminuímos o de Kernel para 1Gb. E isso vai ter os seus custos… recursos de Kernel como: drivers, PTE’s, Paged e NonPaged pool todos vão continuar a concorrer por menos espaço disponível…

Vejamos o seguinte exemplo de um Windows Server 2003 Enterprise R2 com 1GB ode RAM e comparemos alguns valores com e sem o /3GB configurado:

Configuração default sem o /3GB:

  

Free System PTE's

251,980 (1,007,920 kb)

NonPaged Pool Max

206,848 kb

Com o /3GB:

  

Free System PTE's

34,884 (139,536 kb)

NonPaged Pool Max

129,312 kb

Como podemos verificar os Free PTE’s (page table entries) caem aproximadamente 200.000; e isto são valores de um sistema sem carga, apenas para demonstrar os valores iniciais. Uma maquina sujeita a alguma carga pode rapidamente cair para valores abaixo dos 10.000 free PTE’s e aí o sistema pode entrar em falha porque não poderá processar mapeamentos I/O, stacks de kernel etc,…

Verificamos que a nonPaged Pool máxima fica também limitada a apenas 130MB; este é um recurso usados por drivers e rapidamente poderá esgotar; nessa altura será logado o famosos event ID 2019:

Event ID 2019
Event Type: Error
Event Source: Srv
Event Category: None
Event ID: 2019
Description:
The server was unable to allocate from the system NonPaged pool because the pool was empty.

Resumindo: verificamos que o /3GB pode ser útil se tivermos uma aplicação que possa tirar partido dos 3GB de espaço de endereçamento User Mode. Não são todas as aplicações que poderão tirar partido desse mesmo endereçamento; para tal, a aplicação deverá ter a seguinte flag no header: IMAGE_FILE_LARGE_ADDRESS_AWARE. Esta flag é especificada aquando da construção do executável da aplicação através do link /LARGEADDRESSAWARE.

Esta flag não terá qualquer efeito quando executada por aplicações em sistemas com 2Gb de espaço User Mode (sem o /3GB no boot.ini). Por outro lado, executando aplicações que não tenham esta flag em servidores com o /3GB definido, vamos estar a limitar o Kernel da máquina a 1GB quando as aplicações apenas poderão usar os “tradicionais” 2GB de memoria; logo 1GB será simplesmente desperdiçado pois não vai estar em uso por ninguém…

Uma questão pertinente que se coloca neste momento é a seguinte: dadas as limitações ao uso do /3Gb, é recomendado o seu uso em algum cenário em particular?

A resposta é sim! Sim, mas com alguns condicionalismos :)

Por exemplo, em servidores com Exchange Server que tenham public folders/mailboxes, afim de permitir que o processo store.exe não esgote o espaço de endereçamento e possa crescer além dos 2GB. E aqui o condicionalismo é o uso do outro switch que mencionei no inicio do post: /USERVA

Com o parâmetro /Userva, podemos personalizar o modo de atribuição de memória quando utilizado em conjunto com o parâmetro /3GB. O número a seguir a /Userva= corresponde à quantidade de memória em megabytes (MB) que será atribuída a cada processo. Se definirmos /3gb /Userva=3030, vamos reservar 3.030 MB de memória para o espaço de processos, comparado com os 3.072 MB quando utilizamos apenas o parâmetro /3GB. Os 42 MB adicionais, após a definição de /Userva=3030, são utilizados para aumentar o espaço da memória kernel de entradas livres da tabela de páginas do sistema (Free PTE’s’).

Exemplo de uma configuração do boot.ini com o /3GB e /USERVA:

[Boot Loader]

Timeout=30

Default=multi(0)disk(0)rdisk(0)partition(2)\WINNT

[Operating Systems]

multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows Server 2003" /fastdetect /3GB /Userva=3030

Idealmente deveremos ter pelo menos 24.000 Free PTE’s aquando do boot e deveremos monitorizar (por exemplo com o Perfmon) afim de garantir que este valor não cai abaixo dos 10.000 PTE’s.

Espero ter contribuído para esclarecer um pouco o uso do temível /3Gb :)

AML