O gerenciamento de memória do Sql Server é um tópico muito amplo, mas há algumas coisas mencionadas aqui que devem ser abordadas.
Suponho que você esteja olhando para o Gerenciador de Tarefas para obter o que está se referindo como o Uso do Arquivo de Página. Isso NÃO é o tamanho do seu arquivo de página física ou a quantidade de espaço físico no arquivo de páginas usado - isso é chamado de commit charge , que é basicamente a quantidade potencial de espaço total no arquivo de páginas físicas que seria necessário para armazenar todos os VAS (VAS e memória física não são a mesma coisa) . Se você deseja ver o uso real do arquivo de paginação, consulte o contador de desempenho PagingFile:% Usage - ele será quase certamente uma porcentagem muito pequena. O tamanho total de sua taxa de confirmação (ou seja, o que o Gerenciador de Tarefas exibirá como Uso de PF) é basicamente a soma de todos os possíveis VAS (ou seja, todo o espaço no arquivo de páginas + memória física total no sistema).
O Sql Server NÃO substitui os recursos de gerenciamento de memória do SO - ele usa as mesmas APIs de memória fornecidas pelo Windows que qualquer aplicativo de modo de usuário (principalmente o VirtualAlloc família e a AWE family , que ainda é usado em sistemas de 64 bits ,. O Sql Server tem, de fato, um subsistema dedicado a gerenciar sua própria utilização de memória , no entanto este subsistema não faz nada de especial que não esteja disponível para qualquer aplicativo em modo de usuário em termos de solicitação, recebimento, confirmação, etc. de memória do SO subjacente.
Como outros já mencionaram, o Sql Server foi definitivamente projetado para usar o máximo de memória possível com base nas restrições definidas pelo sistema / usuário. No entanto, ela crescerá com base no uso da memória com base na utilização do sistema (ou seja, reservará uma quantidade relativamente pequena de memória na inicialização e continuará solicitando / reservando do sistema operacional conforme necessário). Ele também é projetado para (e bastante bom) responder à pressão de memória do SO conforme necessário, e também manter sua memória reservada até / a menos que o sistema operacional "solicite" de volta (para uma compreensão mais completa disso, consulte este blog e este blog e este blog ).
Se você quiser forçar o Sql Server a liberar / encolher seu espaço de memória atual, você pode simplesmente dizer a ele para fazer isso (assumindo que você está executando o Sql 2005 e superior) diminuindo o valor especificado no configuração do sistema" max server memory " e executando uma reconfiguração. Certamente há limitações para isso (isto é, essa configuração limita apenas o buffer pool, no entanto este é de longe o maior consumidor de memória). Isto é NÃO uma configuração de nível de conexão como aludido em outro lugar, é uma configuração de todo o sistema (Existem configurações de nível de conexão relacionadas à memória, no entanto nada que tenha algo a ver com essa questão) . Se você estiver executando o Sql 2000, precisará fazer o ajuste e reciclar o Sql Service - OBSERVE que no Sql 2000 o gerenciamento de memória era muito, muito diferente em quase todos os aspectos (e provavelmente exigiria uma questão / discussão separada).
Recomendamos que você leia um casal de blogs para obter uma compreensão de windows básicos e gerenciamento de memória do sql server , não deve demorar muito e vale a pena o conhecimento ao tentar entender o que está acontecendo em situações como esta.