Распределение оперативной памяти

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

В отличие от тех мультитерминальных систем, в которых операционная система должна заботиться о равноправном совместном использовании ресурсов, в систе­мах Windows 9x сделано иначе. Поскольку это однопользовательские операцион­ные системы, они позволяют заполнять память так, как это нужно пользователю и его программам. Динамически загружаемые компоненты системы конкурируют за память с прикладными программами. Если пользователь хочет, чтобы его при­ложение работало быстрее, ему будет позволено занять столько памяти, сколько вообще возможно. Система накладывает ограничение на максимальный объем памяти, который может быть отдай в распоряжение отдельных приложений, — если не следить за этим, становится возможным возникновение тупиковых ситуаций. После того как вся физическая память заполнена, первый же новый запрос на вы­деление памяти инициирует замещение страниц. Интересным побочным эффек­том такого подхода является то, что у приложений нет надежного способа опреде­ления объема памяти, доступного в системе. Функция API GlobalMemorySatus() возвращает целый ряд параметров, характеризующих состояние системной памя­ти, однако это не более чем «мгновенный снимок» текущей обстановки — еще один вызов этой функции вполне может дать другие значения.

Для того чтобы облегчить управление всем разнообразием типов страниц памяти, каждая активная страница, то есть каждая страница, которая является частью вы­полняющегося в данный момент системного модуля или приложения, снабжена хра­нящимся совместно с ней страничным дескриптором(Page Descriptor, PD). В этом дескрипторе содержатся адреса процедур, которые занимаются перемещением стра­ницы из памяти на диск и обратно. Независимо от того, что именно находится в данной странице, диспетчер физической памяти, чтобы переместить страницу в опе­ративную память или из нее, просто вызывает соответствующую функцию, адрес которой определен в поле дескриптора страницы. В случае, если некоторая страни­ца еще никогда не заполнялась, она называется абсолютно чистой(virgin”). Напри­мер, именно так обозначаются страницы, содержащие код, использующий вызовы Win32. После того как с момента размещения страницы в памяти в нее будет в первый раз произведена запись данных, она считается испорченной(tainted) и может быть либо грязной(dirty), либо чистой(clean), в зависимости от того, осуществлялась ли в нее запись с момента последней ее подкачки в физическую память. Если запись в эту страницу производилась, и в этой физической странице требуется разместить иную виртуальную страницу, ее содержимое должно быть сохранено в файле подкачки.

В операционных системах Windows 9x младшие адреса виртуального адресного пространства совместно используются всеми процессами. Это сделано для совме­стимости с драйверами устройств реального режима, резидентными программами и некоторыми 16-разрядными программами Windows. Безусловно, это плохое ре­шение с точки зрения надежности, поскольку оно приводит к тому, что любой про­цесс может непреднамеренно (или же, наоборот, специально) испортить компо­ненты, находящиеся в этих адресах.

В Windows 9x каждая 32-разрядная прикладная программа выполняется в соб­ственном адресном пространстве, но все они используют совместно один и тот же 32-разрядный системный код. Доступ к чужим адресным пространствам в прин­ципе возможен. Другими словами, виртуальные адресные пространства не задей­ствуют всех аппаратных средств защиты, заложенных в микропроцессор. В резуль­тате неправильно написанная 32-разрядная прикладная программа может привести к аварийному сбою всей системы. Все 16-разрядные прикладные программы Win­dows разделяют общее адресное пространство, поэтому они так же уязвимы друг для друга, как и в среде Windows 3.X.

Собственно системный код Windows 9x размещается выше границы 2 Гбайт. В про­странстве с отметками 2 и 3 Гбайт находятся системные библиотеки DLL, использу­емые несколькими программами. Напомним, что в 32-разрядных микропроцессорах семейства i80x86 имеется четыре уровня защиты, именуемые кольцами с номерами от 0 до 3. Кольцо с номером 0 является наиболее привилегированным, то есть мак­симально защищенным. Компоненты операционных систем Windows 9x, относя­щиеся к кольцу 0, отображаются на виртуальное адресное пространство между 3 и 4 Гбайт. К этим компонентам относятся собственно ядро Windows, подсистема управления виртуальными машинами, модули файловой системы и драйверы вир­туальных устройств (VxD).

Область памяти между 2 и 4 Гбайт адресного пространства каждой 32-разрядной прикладной программы совместно используется всеми 32-разрядными приклад­ными программами. Такая организация позволяет обслуживать вызовы API не­посредственно в адресном пространстве прикладной программы и ограничивает размер рабочего множества. Однако за это приходится расплачиваться снижени­ем надежности. Ничто не может помешать программе, содержащей ошибку, про­извести запись в адреса, принадлежащие системным библиотекам DLL, и вызвать крах всей системы.

В области между 2 и 3 Гбайт также находятся все запускаемые 16-разрядные при­кладные программы Windows. С целью обеспечения совместимости эти программы выполняются в совместно используемом адресном пространстве, где они мо­гут испортить друг друга так же, как и в Windows 3.x.

Адреса памяти ниже 4 Мбайт также отображаются в адресное пространство каж­дой прикладной программы и совместно используются всеми процессами. Благо­даря этому становится возможной совместимость с существующими драйверами реального режима, которым необходим доступ к этим адресам. Это делает еще одну область памяти не защищенной от случайной записи. К самым нижним адресам (менее 64 Кбайт) этого адресного пространства 32-разрядные прикладные програм­мы обращаться не могут, что дает возможность перехватывать неверные указате­ли, но 16-разрядные программы, которые, возможно, содержат ошибки, могут за­писывать туда данные.

Вышеизложенную модель распределения памяти можно проиллюстрировать с помощью рисунка 23.

Рисунок 23

Минимально допустимый объем оперативной памяти, начиная с которого эти операционные системы могут функционировать, равен 4 Мбайт для Windows 95 и 8 Мбайт для Windows 98. Однако при таких маленьких объемах физической па­мяти пробуксовка столь велика, что быстродействие системы становится слиш­ком малым, и практически работать нельзя.

Страничный файл, с помощью которого реализуется механизм виртуальной памя­ти, по умолчанию располагается в каталоге самой системы Windows и имеет пере­менный размер. Система отслеживает его длину, увеличивая или сокращая этот файл при необходимости. Вместе с фрагментацией файла подкачки это приводит к тому, что быстродействие системы становится меньше, чем если бы этот файл был фиксированного размера и располагался в смежных кластерах (был бы де-фрагментирован). Создать файл подкачки заданного размера можно либо через специально разработанный для этого апплет (Панель управления ► Система ► Быс­тродействие ► Файловая система), либо просто прописав в секции [ 386Enh ] файла SYSTEM.INI строки с указанием диска и имени файла подкачки, например:

PagingDrive=C:

PagingFi1е-С:\PageFile.sys

MinPagingFileSize=65536. ^:

MaxPagi ngFi1eSize=262144

Здесь первая и вторая строки описывают размещение страничного файла и его имя, а две последних — начальный и предельный размеры страничного файла (значения указываются в килобайтах). Для определения необходимого минималь­ного размера можно рекомендовать запустить уже упомянутую выше программу

SYSMON.EXE (системный монитор) и, выбрав в качестве наблюдаемых параметров размер файла подкачки и объем свободной памяти, оценить потребности в памя­ти, запуская те приложения, с которыми чаще всего приходится работать. Большое влияние на использование оперативной памяти и общую производитель­ность системы оказывает драйвер виртуального устройства VCache, занимающийся кэшированием файлов. Он взаимодействует с менеджером физической памяти, запрашивая и освобождая области памяти, которые впоследствии могут быть вы­делены отдельным драйверам файловой системы для выполнения операций кэ­ширования. Этот драйвер работает по методу агрессивного кэширования, в резуль­тате он может захватывать почти всю свободную оперативную память. Как ни странно, это не всегда приводит к увеличению скорости работы с файлами, по­скольку поиск нужных блоков данных среди блоков, находящихся в кэше, осуще­ствляется простым последовательным перебором, а количество просматриваемых блоков в этом случае существенно больше. Поэтому в ряде случаев имеет смысл ограничивать «аппетит» драйвера VCache. Сделать это можно путем редактирова­ния все того же файла SYSTEM.INI. Только теперь нужно найти другую секцию фай­ла — [ VCache ]. В эту секцию следует добавить строки и прописать значения для максимального и минимально объемов оперативной памяти, которую операцион­ная система будет предоставлять подсистеме кэширования. Выглядеть эти новые строки могут, например, так:

MinFileCache=16384

MaxFileCache=65536

ChunkS1ze=2048

NameCache-4096

DirectoryCache=128

Назначение первой и второй строк представляется очевидным. Третья строка опи­сывает размер блока, четвертая строка — количество хранимых в кэше имен фай­лов, а последняя — количество каталогов. Прописанные в приведенных строках значения, естественно, зависят от объема оперативной памяти, имеющейся в ком­пьютере. В данном случае компьютер имеет 512 Мбайт оперативной памяти. Кста­ти, если персональный компьютер имеет более 256 Мбайт памяти, то наличие пер­вых двух строк в секции [ VCache ] файла SYSTEM.INI обязательно. В противном случае из-за недальновидности разработчиков драйвера виртуального устройства VCache он может запросить у системы более 256 Мбайт памяти, причем она может выде­лить ему эту память. Это неминуемо приведет к критической ошибке в его даль­нейшей работе и краху вычислительного процесса.