O objetivo deste artigo é apresentar o gerenciamento de memória do SQL
Server e como ele é afetado pelo gerenciamento do Windows, e ainda como
analisar e compreender problemas gerados pela configuração incorreta de memória
dentro do SQL Server.
O tempo de resposta de sistemas deve ser cada vez mais rápido. Ao se deparar com um problema, entender a sua origem torna-se secundário, em vistada necessidade de encontrar uma solução que o resolva.
É como buscar um remédio para uma doença, sem entender os sintomas ou as causas do mal estar. Entretanto, entender a causa do sintoma é essencial para evitar que ele volte a se apresentar.
O escopo deste artigo abrange o gerenciamento do recurso de memória do SQL Server e do Windows. O objetivo dele é apresentar o funcionamento deste recurso, e através disso ser capaz de analisar corretamente a causa raiz de problemas relacionados à memória.
Para entender o gerenciamento de memória por parte do SQL Server é preciso entender o gerenciamento deste recurso pelo Windows. Considerando que o SQL Server roda nesta plataforma, logo ele está subordinado às regras de gerenciamento de memória do sistema operacional.
O gerenciamento de memória no Windows usa a ideia de que cada processo tem seu próprio endereço na memória, este conceito envolve tanto a memória física quanto a virtual. A memória física é a memória RAM (Random Access Memory), e a memória virtual está relacionada com a forma pela qual o sistema operacional endereça a memória RAM, isso através do VAS (Virtual Address Space).
O VAS, como o nome mesmo diz, é um endereço virtual mapeado dentro da memória RAM para cada processo que está rodando no sistema operacional. Uma vez que os processos estejam utilizando o VAS para organizar o endereçamento da memória, o sistema operacional consegue administrar este recurso de forma eficiente, controlando e garantindo que os processos não sobrescrevam os dados uns dos outros. A Figura 1 ilustra dois endereços da memória virtual sendo mapeados na memória RAM.
Figura 1. Mapeamento entre memória virtual e a RAM.
O tamanho deste endereço virtual é determinado pela arquitetura de CPU, se for de 64 bits e ainda rodando em um software de 64 bits, os valores armazenados podem ir até 16 Terabytes. Sendo que 8 TB é reservado para o Kernel, que é o espaço de memória reservado para operações críticas do sistema operacional e 8 TB para as outras aplicações que rodam dentro do sistema operacional, o SQL Server é uma delas.
Para que as aplicações não interferiam ou modifiquem os dados críticos do sistema operacional, o Windows garante uma parte do espaço de memória apenas para o Kernel.
Para arquitetura de CPU de 32 bits o valor é de 4GB. Sendo que 2GB pertencem ao kernel e 2GB são reservados para as aplicações, a não ser que o parâmetro /3GB esteja habilitado. O parâmetro /3GB muda o espaço de memória virtual das aplicações para 3 GB ao invés de 2 GB, e o espaço para o kernel passa a ser de 1GB. Este parâmetro é suportado pelo Windows 2003, XP, 2000.
Dentro do Windows existe um responsável por gerenciar o VAS e ligá-lo à memória física, este é o papel do Virtual Memory Manager (VMM).
Virtual Memory Manager
Considerando que os valores para memória virtual na arquitetura 64 bits são de 16 TB e na arquitetura 32 bits são de 4 GB, e ainda que existem vários processos rodando no decorrer do tempo em um servidor, facilmente percebe-se que os servidores geralmente têm menos memória física do que o total de memória virtual disponível.
Logo é preciso que exista um responsável por organizar o uso deste recurso pelos processos que estão rodando no sistema operacional e ainda linkar a memória física a virtual, o nome deste responsável é Virtual Memory Manager ou VMM. Portanto, o VMM tem por papel decidir o uso de memória do sistema operacional.
O VMM irá decidir por exemplo, qual processo estará rodando na memória virtual e quando transferir ou paginar o conteúdo da memória em uso deste processo para o disco, e desta forma ele vai liberar espaço para que outros processos ocupem aquele endereço de memória que foi paginado. "
[...] continue lendo...