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

Наибольший эффект оказывает размещение файла подкачки на другом физическом жестком диске (размещение на другом разделе того же диска уменьшит скорость работы). Если жесткий диск один, и на нем достаточно свободного места, чтобы 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 - это персональная ОС, и настраивать ее следует так, как удобнее и приятнее вам. Если вам кажется, что при добавлении параметра система работает быстрее, и вам при такой настройке работать комфортнее - добавление необходимо. В конце концов, существуют люди, которые оценивают скорость системы не по скорости работы приложений, а по тому, насколько быстро выскакивают окошки или насколько быстро система загружается.

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

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

Рассмотрим процесс чтения более детально. Если системе требуются какие-то данные с диска, а эти данные есть в кэше (попадание в кэш), то данные будут получены практически моментально и обращения к жесткому диску не будет. Если же данные в кэше отсутствуют (промах), то система обращается к диску (здесь и далее все расчеты будем делать для жесткого диска, для конкретности возьмем мой IBM DJNA-371350 – 13 Гб, 7200 об/мин). Поскольку система у нас многозадачная, то мы не можем определить, к какому участку диска выполнялось предыдущее обращение и должны предполагать, что головки находятся над каким-то случайным цилиндром. Сначала головки должны установиться на нужный цилиндр – от 2,2 до 15,5 мс, среднее время – 9,0 мс. Затем необходимо дождаться, когда под головками окажется нужный сектор. Согласно теории вероятности среднее время ожидания – половина оборота диска, т.е. 4,17 мс. Затем надо прочитать запрашиваемый блок данных и передать его в оперативную память. Продолжительнось чтения и передачи зависит от скорости работы диска, скорости передачи данных по шине и размера прочитываемых данных. Средний размер одной порции данных при работе в Windows составляет примерно 15-20 килобайт, возьмем для расчетов 20 Кб. Чтобы определить время чтения, делим 20 Кб на параметр media transfer rate (скорость обмена данными с поверхностью) и еще примерно на 1,2 – чтобы учесть межсекторные промежутки и служебные зоны. Получаем приблизительно 1 мс. Скорость передачи данных по шине зависит от характеристик шины и составит ~ 0,7 мс при шине 33 Мб/с и 0,2 мс при шине 100 Мб/с. Итого – от 14,4 до 14,9 мс в зависимости от скорости шины.

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

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

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

индекс статьи
страница 1 : страница без заголовка
страница 2 : страница без заголовка
страница 3 : страница без заголовка
страница 4 : страница без заголовка
страница 5 : страница без заголовка
страница 6 : страница без заголовка
страница 7 : страница без заголовка
страница 8 - текущая : страница без заголовка