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

Игорь Лейко

Советы

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, число очищенных страниц, то есть количество страниц, которые могут быть высвобождены без записи их содержимого в виртуальную память.

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

Обсуждение результатов

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

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

То, что размер файла подкачки оказывается одинаковым и при 128 Мб ОЗУ, и при 48 Мб, скорее всего, означает, что общее количество места, зарезервированного в файле подкачки (как до запуска программ, так и в процессе работы), зависит от запущенных программ, а вовсе не от объема ОЗУ. Это опять-таки соответствует логике использования файла подкачки, изложенной разработчиками.

Дополнительный эксперимент

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

Описанный выше эксперимент был проделан еще два раза, оба раза при 48 Мб, один раз с выключенным параметром, второй раз - с включенным. На этот раз печать выполнялась дважды. Между операциями печати была сделана небольшая пауза, чтобы в протоколе системного монитора можно было легко и непринужденно отличить одну операцию от другой.

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

Выводы и рекомендации

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

Наибольший эффект оказывает размещение файла подкачки на другом физическом жестком диске (размещение на другом разделе того же диска уменьшит скорость работы). Если жесткий диск один, и на нем достаточно свободного места, чтобы Windows 9х могла избежать чрезмерной фрагментации файла подкачки, то принятие специальных мер по оптимизации этого файла, как правило, не даст заметного эффекта.

Добавление параметра в раздел [386Enh] файла system.ini приводит к уменьшению размера файла подкачки перед началом объемной работы или через некоторое время после нее, не влияет (или мало влияет) на размер файла подкачки во время работы, не оказывает заметного влияния на скорость работы, приводит к более интенсивному использованию виртуальной памяти.

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

А как же быть с множеством случаев, когда при добавлении такого параметра как ConservativeSwapfileUsage=1 наблюдалось улучшение работы системы? Увы, могу объяснить это только эффектом плацебо. Тем более что во всех известных мне таких случаях оценка производилась на глаз, без каких-либо измерений. Подобным оценкам принято доверять только при сравнении двойным слепым методом.

Приведу пример того, как субъективное отношение неверно повлияло на полученный результат, пример из моего личного опыта. Небезызвестный в англоязычном интернете Эндрю Кэмерон писал мне по поводу программы Win2cache: "The log file says 'not installed' - however I am SURE it is, because things seem A LOT faster" (в файле протокола сказано "не установлена", хотя я УВЕРЕН, что она установилась, поскольку видно, что все работает НАМНОГО быстрее). И это при том, что программа не только не установилась, но и в принципе не могла дать никакого улучшения на Pentium III. Налицо обычное самовнушение, тот случай, когда ожидаемое воспринимается как происходящее в действительности.

Так вреден или полезен параметр ConservativeSwapfileUsage=1? Я не стану давать категорического ответа. Конечно, его добавление ухудшает параметры системы, но ухудшение не настолько велико, чтобы быть критически важным. С другой стороны, Windows 9x/Me - это персональная ОС, и настраивать ее следует так, как удобнее и приятнее вам. Если вам кажется, что при добавлении параметра система работает быстрее, и вам при такой настройке работать комфортнее - добавление необходимо. В конце концов, существуют люди, которые оценивают скорость системы не по скорости работы приложений, а по тому, насколько быстро выскакивают окошки или насколько быстро система загружается.

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

Несколько слов о дисковом кэше

Выше уже говорилось о дисковом кэше, но вскользь. Давайте рассмотрим его работу и настройки подробнее. Дисковый кэш - это область памяти, в которую записываются данные, ранее прочитанные с диска. Если эти данные требуются повторно, то они берутся из кэша, а не прочитываются с диска заново. Часто можно услышать, что дисковый кэш ускоряет работу диска. Но такое утверждение в корне неверно.

Дисковый кэш ускоряет работу системы с диском, если случаются попадания в кэш. Обращение же к диску при работающем кэше занимает ровно столько же времени, сколько и при отсутствии кэша: примерно десять-пятнадцать миллисекунд (для жесткого диска).
Рассмотрим процесс чтения более детально. Если системе требуются какие-то данные с диска, а эти данные есть в кэше (попадание в кэш), то данные будут получены практически моментально и обращения к жесткому диску не будет. Если же данные в кэше отсутствуют (промах), то система обращается к диску (здесь и далее все расчеты будем делать для жесткого диска, для конкретности возьмем мой IBM DJNA-371350 - 13 ГБ, 7200 об/мин).

Поскольку система у нас многозадачная, то мы не можем определить, к какому участку диска выполнялось предыдущее обращение и должны предполагать, что головки находятся над каким-то случайным цилиндром. Сначала головки должны установиться на нужный цилиндр - от 2,2 до 15,5 мс, среднее время - 9,0 мс. Затем необходимо дождаться, когда под головками окажется нужный сектор. Согласно теории вероятности среднее время ожидания - половина оборота диска, т.е. 4,17 мс. Затем надо прочитать запрашиваемый блок данных и передать его в оперативную память.

Продолжительность чтения и передачи зависит от скорости работы диска, скорости передачи данных по шине и размера прочитываемых данных. Средний размер одной порции данных при работе в Windows составляет примерно пятнадцать-двадцать килобайт, так что, возьмем для расчетов 20 Кб. Чтобы определить время чтения, делим 20 Кб на параметр media transfer rate (скорость обмена данными с поверхностью) и еще примерно на 1,2 - чтобы учесть межсекторные промежутки и служебные зоны.

Получаем приблизительно 1 мс. Скорость передачи данных по шине зависит от характеристик шины и составит ~ 0,7 мс при шине 33 МБ/с и 0,2 мс при шине 100 МБ/с. Итого - от 14,4 до 14,9 мс в зависимости от скорости шины.

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

Но вероятность такого хода событий не слишком велика: системе может понадобиться обратиться к файлу подкачки, программному файлу, сохранить данные во временном файле, прочитать данные для другой программы…

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

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

Поэтому искусственное ограничение размера кэша - это сознательное ухудшение характеристик системы. Если во время работы имеется свободная оперативная память - это неиспользуемая (напрасно установленная память). И неважно, почему память свободна - то ли потому, что вы установили некую программу, принудительно освобождающую память, то ли потому, что вы не разрешили кэшу ее использовать. С таким же успехом вы можете физически удалить эту свободную память.

Раз она все равно не используется, ее отсутствие ни на что не повлияет.

Источник: http://www.computery.ru/upgrade/