Gestão de memória – Antes e depois de Windows Vista/2008
No seguimento de um post anterior sobre gestão de memória, hoje vamos abordar um pouco algumas alterações introduzidas ao nível do Kernel em Windows Vista/Windows 2008, nomeadamente alterações que afectam a gestão da paged pool e non-paged pool que são os assuntos que temos vindo a debater nesta série de posts.
Como tínhamos visto anteriormente, os recursos de Kernel eram definidos aquando do boot da máquina, quer através de chaves de registo ou ao nível da própria SKU – eg. Stock Keeping Unit – designação usada pela Microsoft para diferenciar as diferentes versões de OS/canais de distribuição dos Sistemas Operativos.
Como a figura demonstra, antes da introdução do Windows Vista o espaço virtual do Kernel era alocado de uma forma estática, com tamanhos fixos; esta alocação virtual impõe limites máximos aos tamanhos das pools, PTE’s e outros recursos de Kernel. Estes recursos têm um tamanho inicial, baseado na quantidade de RAM presente no sistema e podem crescer até um determinado valor especificado aquando do boot da máquina. Como todos eles são recursos finitos, se um desses recursos “esgotar” a máquina entra em falha, mesmo que os restantes estejam aquém dos limites máximos… e quanto a isto, não havia muito a fazer (bom, havia, um reboot à máquina…)
Em Windows Vista/2008, o espaço virtual é alocado de uma forma dinâmica, semelhante ao que acontece com o espaço em User Mode; este espaço de Kernel apenas é limitado pela quantidade de RAM disponível na arquitectura. Os tamanhos de cada um dos recursos em Kernel podem variar de acordo com os requisitos momentâneos do sistema. Desta forma, cada um destes recursos deixou de ter um tamanho definido dentro do próprio espaço de Kernel. O Windows Vista ignora as chaves de registo anteriormente usadas aquando do boot para definir os tamanhos dos diferentes recursos e como resultado desta alocação dinâmica todos os recursos de Kernel estão disponíveis para quem os “requisitar” num determinado momento, seja paged pool, non-paged pool, PTE’s,System cache, etc,… ou seja, enquanto houver por favor sirvam-se à vontade :)
A partir de Vista/2008, algumas funcionalidades como o Special Pool e o Driver Verifier podem ser activadas sem necessitar reboot uma vez que o sistema pode alocar espaço virtual de uma forma dinâmica; estas funcionalidades também já não requerem nenhuma alocação de recursos se não estiverem em uso, ao contrario do que sucedia antes em que, aquando do boot, era-lhes reservado um determinado espaço virtual no Kernel.
Como resumo, verificamos que agora temos uma gestão de memoria mais eficiente, o que permite uma maior estabilidade do sistema operativo. Alguns de vocês poderão questionar: mas isto resolve os problemas de esgotamento de recursos de Kernel (paged, non-paged pool) bem como os infames eventos 2019,2020,333? A resposta é nim :) sim, pode ajudar a minimizar problemas de desenvolvimento de drivers que por exemplo estejam a consumir demasiados recursos; ou num File Server, com “picos” de acesso em que a NPP atinge valores excessivos em determinados momentos; mas não será a solução para um Exchange Server em que o processo store.exe começa a consumir cada vez mais recursos… ou um SQL server já muito “espremido” :) estamos a falar claro de arquitecturas 32 bits, dado que em 64 bits não temos este tipo de problemas; mas este poderá ser o tema de um próximo post: Limites de memoria nas diferentes arquitecturas (x86 vs x64)
Como nota final - e para quem fez skip ao cabeçalho deste post :o) - as alterações introduzidas em Vista/2008 não se resumem aos temas aqui abordados e nem o objectivo seria esmiuçar o núcleo do OS :) mas sim percebermos as principais diferenças ao nível da gestão de alguns recursos de Kernel, nomeadamente paged e non-paged pool.
Até breve
AL