Сбрось память на диск - II

Игорь Лейко
ipl@redline.ru

Советы

1. Если у вас установлен привод компакт-дисков, не уменьшайте размер его кэша, чтобы сэкономить память. Вы сэкономите не столько оперативную, сколько виртуальную память. Дело в том, что этот кэш в Windows 9х является выгружаемым. То есть если он не используется, а память, которую он занимает, требуется другим программам, то он вытесняется в файл подкачки. При обращении к компакт-диску кэш снова загружается в память.

2. Если вам остро не хватает места на диске, то, возможно, вы сталкивались с ситуацией, когда файл подкачки занимал все свободное место. В этом случае вам поможет строка
MinUserDiskSpace=количество_килобайт,
добавленная в раздел [386 Enh] файла System.ini. После этого Windows будет оставлять на диске свободное место указанного размера, ограничивая увеличение размера файла подкачки.

Размер имеет значение

Теперь несколько слов о том, как на скорость работы влияет частое изменение размера файла подкачки. Начнем с небольшого, но необходимого экскурса в историю. В Windows 3.1 файл подкачки мог быть либо постоянным, либо временным. Постоянный файл подкачки находился на диске и занимал на нем место всегда. А временный файл подкачки создавался лишь на то время, когда у Windows появлялась нужда в виртуальной памяти, что несколько экономило место на диске.

Зато с постоянным файлом подкачки система работала быстрее. В представлении основной массы пользователей и многочисленных так называемых "специалистов" это ускорение работы было связано с тем, что Windows тратила много времени на увеличение и уменьшение размера файла подкачки. Как сказал один мудрый человек, нет ничего легче, чем найти простое и ясное для понимания неправильное решение (в данном случае - объяснение).

На самом деле разница в скорости работы системы объяснялась отнюдь не увеличением и уменьшением размера файла подкачки. Эти процедуры занимали мало времени и выполнялись, в основном, при запуске и завершении работы программ. С постоянным файлом подкачки система работала в обход подпрограмм обслуживания дисков, записанных в ПЗУ компьютера (BIOS). Доступ к временному файлу подкачки осуществлялся через эти процедуры (если такие процедуры вынуждена использовать Windows 9х, то на вкладке "Быстродействие" появляется сообщение "Страничный обмен в режиме MS-DOS снижает быстродействие").

Windows 9х использует временный файл подкачки, но обращается к нему в обход процедур ДОС и BIOS. Для нее это нормальный режим работы с диском. Создать в этой системе постоянный файл подкачки невозможно. Хотя она и может использовать постоянный файл подкачки, оставшийся от Windows 3.x, но использует его не как постоянный, а как временный. Можно создать файл подкачки постоянного размера, задав для него одинаковые верхнюю и нижнюю границы, но постоянным он от этого не станет.

Постоянный файл подкачки имел заданный размер и был непрерывным, но помимо этого располагался в строго определенном месте диска, которое указывалось во вспомогательном файле. Если файла подкачки на этом месте не оказывалось, то вы получали сообщение, что он недоступен.

Чтобы убедиться, что изменение размера файла подкачки не оказывает сколько-нибудь заметного влияния на скорость работы программ, выполните небольшой эксперимент. Возьмите файл с какой-нибудь небольшой программой для ДОС, например редактор Edit, находящийся в папке Command. Откройте окно свойств этой программы и установите очень большие требования (например, 32 768 Кб) к дополнительной (XMS), отображаемой (EMS) памяти и памяти защищенного режима ДОС (DPMI). Если вы установили файлу подкачки постоянный размер, уберите верхнюю границу и перегрузите компьютер.

Запустите системный монитор и задайте отслеживание загрузки процессора и размера файла подкачки и обновление информации через одну секунду. Теперь запустите программу для ДОС, свойства которой вы устанавливали, и посмотрите, много ли времени потребовалось системе на увеличение размера файла подкачки. Если вы задали довольно большой минимальный размер этого файла, то, возможно, придется запустить не одну, а несколько копий программы, прежде чем система увеличит его размер.

Теперь закройте запущенную программу (программы) и подождите, пока размер файла подкачки уменьшится. И опять это произойдет почти моментально. Правда, если в "отсекаемой" части файла подкачки окажутся выгруженные страницы, то тогда система предварительно переместит их в оставляемую часть файла, а на это потребуется некоторое время и довольно большое число операций ввода/вывода. Но значительную часть этого времени процессор будет простаивать.

Параметр ConservativeSwapfileUsage=1 был документирован некоторое время спустя после выхода Windows 98. В описании к нему сказано, что он предназначен для обеспечения совместимости с некоторыми программами для Windows 95, которые отслеживают обращения Windows к файлу подкачки. 
Внутренний механизм работы с файлом подкачки в Windows 98 изменен. При необходимости выгрузки какой-либо области памяти в файл подкачки Windows 95 ждала момента, когда система в целом оказывалась в состоянии простоя, а Windows 98 ждет момента, когда простаивает VFAT, то есть лишь одна из подсистем - дисковая.

Такой подход должен повышать быстродействие системы. На практике повышение оказывается практически незаметным из-за относительной редкости операций записи в файл подкачки. К тому же дополнительное условие для заметности - высокая загруженность процессора при невысокой интенсивности обращений к дискам, что встречается не так уж часто.

Впрочем, как заявлял герой одного анекдота, не сильно любивший жадных старушек-процентщиц "десять старушек - уже рубль". И именно набор таких небольших выигрышей приводит к тому, что быстродействие новых систем (подчеркну: при прочих равных условиях) оказывается выше, чем у старых систем. Предвидя возмущенные письма с утверждениями, что Windows 95 всегда работает быстрее, чем Windows 98, напомню один факт.

Информационный компьютерный ресурс ZDNet, которая отнюдь не с симпатией относится к "Майкрософт", в 1998 году обнародовала результаты своих исследований. Согласно им, при 16 МБ ОЗУ связка Windows 95 + Internet Explorer 4 работает быстрее, чем Windows 98. Но уже при 32 Мб, Windows 98 оказывается на 9 процентов быстрее своей предшественницы. С ростом объема памяти выигрыш увеличивается, хотя уже и не так быстро.

Но вернемся, собственно, к предмету разговора. Помимо документированного эффекта параметр ConservativeSwapfileUsage=1 обладает еще недокументированным. Он также включает использование алгоритма управления файла подкачки от Windows 95. То есть отменяет предварительное увеличение размера файла подкачки и выгрузку в файл подкачки неиспользуемых модулей ради увеличения размера дискового кэша.

Народная молва тут же приписала ему чудодейственный эффект: якобы, параметр заставляет Windows максимально эффективно использовать оперативную память, минимизируя использование файла подкачки. Внешне объяснение действительно логичное: если у вас 128 Мб памяти, то после загрузки, хоть несколько десятков мегабайт физической памяти и свободно, Windows 98 создает файл подкачки в двадцать-тридцать мегабайт.

А если добавить в файл system.ini упомянутый параметр, то размер файла подкачки оказывается нулевым. Казалось бы, уменьшение подкачки налицо?
В том то и дело, что нет. Подкачки не было и в первом случае (системный монитор показывает, что занято в файле подкачки 0 байт). Но кому нужно запускать системный монитор и разбираться в его показаниях? А команда DIR, такая простая и наглядная, всегда под руками.

Эксперимент

Так что же в действительности дает этот параметр? Я решил выяснить это экспериментальным путем. Но чем измерять? Имеющаяся у меня версия WinStone уж очень старая и нормально под Windows 98 работать не хочет. Известная вам SiSoft Sandra и схожая программа из NU не годятся, поскольку не измеряют быстродействие компьютера, а оценивают его. Они меряют отдельные характеристики, каждую независимо от других, а потом, по каким-то своим соображениям, выводят итоговое значение. В результате получаем некое конкретное число, но на него можно только лишь ориентироваться. 
Я выбрал в качестве тестового задания печать большого документа Word (30 Мб, свыше 400 страниц) с множеством рисунков и таблиц.

Word запускался командой печати данного документа, после чего автоматически закрывался. В свойствах принтера была включена отложенная печать, так что собственно печать документа не выполнялась, а только формировались данные для печати. Сама процедура эксперимента выглядела так. Использовалась рабочая копия Windows 98 SE на машине следующей конфигурации: Pentium III 667 МГц, 128 МБ ОЗУ, винчестер 7200 об/мин с двухмегабайтным кэшем.

Настройки виртуальной памяти и кэша - принятые по умолчанию.

В этой системе последовательно выполнялась печать сначала с отключенным параметром ConservativeSwapfileUsage=1, затем, после перезагрузки, - с включенным. Перед каждой перезагрузкой файл подкачки и файл с данными для печати удалялись.

Для накопления статистических данных эти эксперименты были повторены трижды. Затем то же самое я проделал для памяти, ограниченной размером 48 Мб.

Параметры системы измерялись системным монитором, включенным на запись данных в файл. Периодичность замеров была задана равной 0,1 секунды. Итого - 12 перезагрузок и 12 тестов.

Результаты

Прежде всего, меня удивило то, что во всех двенадцати случаях после печати размер файла подкачки был одинаков: девятнадцать четырехмегабайтных кусков. Исходя из общепринятых представлений, логично было бы ожидать, что при меньшем объеме памяти файл подкачки должен был бы быть больше.

Добавление параметра действительно уменьшало исходный размер файла подкачки: с 68 Мб до 0 при 128 Мб памяти и с 68 Мб до 52 Мб - при 48 Мб ОЗУ. При 128 Мб занято в файле подкачки перед началом печати (т. е. после загрузки) в обоих случаях было 0 байт, при 48 Мб - около 2 Мб при выключенном и 0 - при включенном параметре. Напомню, что сразу после выполнения задания размер файла подкачки был одинаков во всех 12 экспериментах. То есть, место на диске добавлением этого параметра сэкономить не удалось.

А как обстоят дела с другими характеристиками, в частности, собственно объемом подкачки и скоростью? Ведь чем меньше обращений к файлу подкачки, тем выше должна быть скорость работы.
Среднее время выполнения задания (около минуты для 128 Мб и примерно 70 секунд для 48 Мб) при включенном параметре незначительно отличалось в меньшую сторону на 128 Мб и в большую - на 48 Мб.

Но статистически эти отличия были недостоверны: различия между сериями оказались меньше или сопоставимы с разбросом значений внутри серий (пришлось вспоминать правила обработки результатов экспериментов, которые я когда-то изучал в курсе матстатистики).

Одинаковым, независимо от параметра (опять-таки в пределах разброса внутри серии), было:

• число байтов, прочитанных с диска и записанных на диск, что вполне логично;

• количество прочитанных (с диска) страниц виртуальной памяти, что нелогично, если считать общепринятое мнение о параметре правильным.

Подкачка должна была бы быть меньше;

• количество страниц, записанных на диск диспетчером памяти при 128 Мб ОЗУ, что также нелогично при вышеуказанном предположении.

У двух параметров разница была статистически достоверной. При ОЗУ 48 Мб добавление параметра ConservativeSwapfileUsage=1 увеличивало количество выгрузок страниц в файл подкачки с полутора тысяч до ~1800 при разбросе внутри серий всего около процента.

При этом уменьшалось, также примерно на 300, число очищенных страниц, то есть количество страниц, которые могут быть высвобождены без записи их содержимого в виртуальную память.

Говоря проще, добавление этого параметра увеличивало число случаев, когда перед выделением памяти другому модулю ее содержимое было необходимо выгрузить в файл подкачки. Согласитесь, что о такой ситуации трудно сказать, как об улучшении использования имеющейся оперативной памяти. Скорее, наоборот.