Гость ОС VMware RHEL5 кэшировал выпуск памяти
Это - типичная запись журнала вперед поведение. Когда страница обновляется в базе данных, обновление сначала записано в журнал, затем относилось в странице памяти. Страница остается грязной в памяти, пока контрольная точка не происходит, в который точка записанный на диске. Журнал должен быть записан перед обновлением для поддержки восстановления и отката. Если один из этих двух не происходит (восстановление или откат), нет никакой потребности когда-либо считать снова журнал. Таким образом, поведение, которое Вы видите, типично для системы, которая изменяет страницы в tempdb. Вы только видели бы чтения журнала, если откат произойдет (так как восстановление не может произойти для tempdb).
Более интересный вопрос состоит в том, почему столько обновлений страницы происходит в tempdb? Типичные преступники являются любой прямыми обновлениями (например, Состояние сеанса в tempdb с ASP) или косвенные (шпульки и виды в планах запроса).
Один механизм для исправления памяти от сервера БД, VM в примере был бы драйвером Воздушного шара VMware (который является частью Инструментов VMware):
This is VMware physical memory management driver which acts
like a "balloon" that can be inflated to reclaim physical pages
by reserving them in the guest and invalidating them in the
monitor, freeing up the underlying machine pages so they can
be allocated to other guests. The balloon can also be deflated
to allow the guest to use more physical memory.
Посмотрите, например, "3.3 Запуска шаров-зондов" в Понимании управления Ресурсом памяти в Сервере VMware® ESX (PDF).
Вы могли также запустить этот небольшой скрипт
#!/bin/sh
sync && echo 3 > /proc/sys/vm/drop_caches
в сервере БД VM для явного освобождения pagecache, dentries и inodes, если Вы уверены, что Вам больше не нужны кэши.