MapViewOfFile),может обернуться проблемой. Эта потенциальная проблема не возникает в Windows, поскольку и диспетчер кэша, и приложения, проецирующие файлы на свои адресные пространства, используют одни и те же сервисы подсистемы управления памятью. Так как диспетчер памяти гарантирует, что у него имеется только одно представление каждого уникального проецируемого файла (независимо от количества объектов «раздел», или проекций файла), он проецирует все представления файла (даже если они перекрываются) на единственный набор страниц физической памяти, как показано на рис. 11-1.
Поэтому, если, например, на пользовательское адресное пространство процесса 1 проецируется представление 1 файла и процесс 2 обращается к тому же представлению через системный кэш, то процесс 2 будет видеть любые изменения в этом представлении по мере их внесения процессом 1, а не после сброса измененных данных из кэша на диск. Диспетчер памяти сбрасывает не все страницы, проецируемые на пользовательские пространства, а лишь те, о которых он знает, что они изменены (установлен бит изменения). По этому любой процесс, обращающийся к файлу, всегда видит его самую последнюю версию, даже если одни процессы открыли этот файл через подсистему ввода-вывода, а другие проецируют его на свои адресные пространства с помощью соответствующих Windows-функций.
ПРИМЕЧАНИЕ B силу некоторых причин сетевым редиректорам труднее поддерживать когерентность кэша, чем локальным файловым системам, и они должны реализовать дополнительные операции сброса и очистки кэша. Ha эту тему см. главу 12.
(o)Появляется возможность реализации интеллектуального опережающего чтения (intellegent read-ahead), так как диспетчер кэша следит за тем, части каких файлов находятся в кэше, и это позволяет ему предсказывать, к какой следующей порции данных обратится вызывающая программа.
(o)Подсистема ввода-вывода может запрашивать данные, уже находящиеся в кэше, в обход файловой системы (быстрый ввод-вывод). Поскольку диспетчеру кэша известно, какие части и каких файлов находятся в кэше, он может вернуть адрес кэшируемых данных для выполнения запроса на ввод-вывод без обращения к файловой системе.
Подробнее об интеллектуальном опережающем чтении и быстром вводе-выводе мы расскажем чуть позже.
ПРИМЕЧАНИЕ Термин метаданные относится только к изменениям в структуре файловой системы в результате создания, переименования и удаления файлов и каталогов.
Чтобы обеспечить успешное восстановление тома, каждый элемент (запись) файла журнала, документирующий изменения в данных тома, должен быть записан на диск до самого обновления данных. Поскольку запись на диск кэшируется, файловая система должна взаимодействовать с диспетчером кэша, чтобы гарантировать выполнение следующей последовательности операций.
1. Файловая система заносит в файл журнала запись, документирующую изменение данных тома, которое она собирается выполнить.
2. Файловая система вызывает диспетчер кэша для сброса на диск записи файла журнала.
3. Файловая система записывает в кэш обновленные данные тома, т. е. модифицирует свои кэшируемые метаданные.
4. Диспетчер кэша сбрасывает модифицированные метаданные на диск, обновляя структуру тома. (Ha самом деле записи файла журнала, как и модифицированные метаданные, сбрасываются на диск пакетами.) Записывая данные в кэш, файловая система предоставляет номер логической последовательности(logical sequence number, LSN), который идентифицирует запись файла журнала, соответствующую обновлению кэша. Диспетчер кэша отслеживает эти номера, регистрируя наименьший и наибольший LSN (представляющие первую и последнюю записи файла журнала); такие номера сопоставляются с каждой страницей кэша. Кроме того, потоки данных, защищенные записями журнала транзакций, помечаются NTFS как «не записываемые», чтобы подсистема записи спроецированных страниц не сбросила эти страницы на диск до того, как туда будут сброшены соответствующие записи файла журнала. (Обнаружив помеченную таким образом страницу, подсистема записи спроецированных страниц перемещает ее в специальный список страниц, которые диспетчер кэша сбрасывает на диск в подходящий момент.)
Когда диспетчер кэша готов сбросить на диск группу измененных страниц, он определяет наибольший LSN, сопоставленный со сбрасываемыми на диск страницами, и сообщает его файловой системе. Далее файловая система может ответно вызвать диспетчер кэша и заставить его сбросить данные файла журнала вплоть до точки, представленной указанным LSN. Сбросив данные файла журнала вплоть до указанного LSN, диспетчер кэша сбрасывает на диск и соответствующие обновления в структуре тома, что гарантирует регистрацию предстоящих операций до их выполнения. Таким образом и достигается возможность восстановления дискового тома после аварии системы.
При первой операции ввода-вывода (чтения или записи) над файлом диспетчер кэша проецирует на свободный слот адресного пространства системного кэша 256-килобайтное представление области файла, выровненной по границе 256 Кб и содержащей запрошенные данные. Например, если из файла считывается 10 байтов по смещению 300 000 байтов от его начала, то проецируемое представление будет начинаться со смещения 262 144 (вторая область файла, выровненная по границе 256 Кб) и займет 256 Кб.
Диспетчер кэша проецирует представления файлов на слоты адресного пространства кэша по принципу карусели: первое запрошенное представление – на первый 256-килобайтный слот, второе – на второй и т. д. рис. 11-3). B этом примере первым был спроецирован файл В, вторым – А, третьим – С, поэтому проецируемая часть файла B занимает первый слот кэша. Заметьте, что спроецирована лишь первая 256-килобайтная часть файла В, так как обращение было лишь к части файла и так как файл С, размер которого составляет всего 100 Кб, требует выделения своего 256-килобайтного слота кэша.
Рис. 11 -3.
Файлы различного размера, спроецированные в системный кэш
Диспетчер кэша гарантирует, что представление проецируется на то время, пока оно активно (хотя представления могут оставаться спроецированными после того, как становятся неактивными). Однако представление помечается как активное, только когда выполняется операция чтения или записи над соответствующим файлом. Если процесс, открывающий файл вызовом CreateFile,не указывает флаг FILE_FLAG_RANDOM_ACCESS, диспетчер кэша прекращает проецировать неактивные представления этого файла при проецировании его новых представлений. Страницы отключенных проекций посылаются в список простаивающих или модифицированных страниц (в зависимости от того, были ли они изменены); при этом диспетчер кэша, используя специальный интерфейс диспетчера памяти, может указать, в каком месте списка следует разместить эти страницы – в конце или в начале.
Страницы, соответствующие представлениям файлов, открытых с флагом FILE_FLAG_SEQUENTIAL_SCAN, перемещаются в начало списков, а все остальные – в конец. Такая схема способствует повторному использованию страниц, которые принадлежат файлам, открытым для последовательного чтения, и заставляет использовать малые объемы физической памяти при копировании больших файлов.
Если диспетчеру кэша требуется спроецировать представление файла, а свободных слотов в кэше нет, он отключает неактивное представление, спроецированное последним, и использует освободившийся слот. B отсутствие таких представлений возвращается ошибка ввода-вывода с сообщением о том, что системных ресурсов для выполнения данной операции недостаточно. Эта ситуация крайне маловероятна, так как возникает только при одновременном доступе к тысячам файлов.
B Windows 2000 Server с установленными Terminal Services (Службы терминала) переключатель Maximize Data Throughput For File Sharing (Макс, пропускная способность доступа к общим файлам), показанный на рис. 11-4, активен по умолчанию, т. е. параметр LargeSystemCache равен 1. При выборе любого другого переключателя параметр LargeSystemCache становится равным 0. Каждый из переключателей диалогового окна File And Printer Sharing For Microsoft Networks Properties влияет не только на поведение системного кэша, но и на службу файлового сервера.
Рис. 11 -4.
Диалоговое окно FiIe and Printer Sharing for Microsoft Networks Properties, позволяющее изменять свойства сетевой службы сервера
B Windows XP и Windows Server 2003 модифицировать параметр LargeSystemCache можно через диалоговое окно Performance Options (Параметры быстродействия), которое открывается щелчком кнопки Settings (Параметры) в разделе Performance (Быстродействие) на вкладке Advanced (Дополнительно) апплета System (Система) из Control Panel (Панель управления). B этом диалоговом окне перейдите на очередную вкладку Advanced (Дополнительно). Если в разделе Memory Usage (Использование памяти) вы выбираете System Cache (системного кэша), параметру LargeSystemCache присваивается значение 1, а если вы выбираете Programs (программ) – 0 (рис. 11-5).
Рис. 11 -5.
Настройка LargeSystemCache в Windows XP и Windows Server 2003
128 Мб + (64 Мб – 16 Мб) / 4 Мб * 64 Мб = 896 Мб
Минимальный и максимальный виртуальные размеры системного кэша на разных платформах, а также его стартовый и конечный адреса показаны в таблице 11 -1. Если на платформе x86 рассчитанный системой виртуальный размер кэша превышает 512 Мб, он ограничивается 512 Мб; однако при параметре LargeSystemCache, равном 1, в той же ситуации кэшу назначается до 960 Мб виртуальной памяти из дополнительного диапазона адресов, называемого дополнительной памятью кэша(cache extra memory). Основное преимущество выделения под кэш большего объема виртуальной памяти заключается в том, что это позволяет уменьшить число операций проецирования и отмены проецирования представлений при обращении к разным файлам и разным представлениям файлов.
B таблице 11-2 перечислены системные переменные, которые содержат виртуальный размер и адрес системного кэша.
ЭКСПЕРИМЕНТ: просмотр виртуального размера кэша
Виртуальный размер кэша не показывается каким-либо счетчиком производительности, так что единственный способ узнать его значение – получить содержимое переменной ядра MmSizeOfSystemCacheInPages\
B этом примере использована х86-система под управлением Windows XP с параметром LargeSystemCache, равным 0; как видите, виртуальный размер кэша в такой системе составляет 0x20000 страниц. Поскольку на платформе x86 размер страниц равен 4 Кб, под виртуальный кэш выделено 512 Мб из 2-гигабайтного системного адресного пространства.
У системного кэша нет собственного рабочего набора – он использует единый системный набор, в который входят кэш данных, пул подкачиваемой памяти, а также подкачиваемый код Ntoskrnl и драйверов. Как упоминалось в главе 7, этот рабочий набор имеет внутреннее название рабочий набор системного кэша,но системный кэш является лишь одним из его элементов. Поэтому мы будем использовать термин «системный рабочий набор». Также в главе 7 мы обратили ваше внимание на то, что при присвоении параметру реестра LargeSystemCache значения 1 диспетчер памяти отдает предпочтение системному рабочему набору по сравнению с рабочими наборами процессов, выполняемых в системе.
Выяснить физический размер системного кэша, сравнить его с суммарным физическим размером системного рабочего набора, а также получить информацию об ошибках страниц для системного рабочего набора позволяют счетчики производительности или системные переменные, перечисленные в таблице 11-3.
ЭКСПЕРИМЕНТ: просмотр рабочего набора кэша
Как показано на листинге ниже, команда !filecacbeотладчика ядра выводит дамп информации о физической памяти, используемой кэшем, текущем и пиковом размерах рабочего набора, количестве действительных страниц, сопоставленных с представлениями, и, где это возможно, имена файлов, проецируемых на представления. (Драйверы файловых систем кэшируют метаданные с помощью безымянных файловых потоков.)
Вспомните из главы 7, что при усечении рабочего набора или замене страниц диспетчер памяти может переместить измененные страницы из рабочего набора в список простаивающих или модифицированных страниц – в зависимости от того, куда должны быть записаны данные, содержащиеся на такой странице, перед ее повторным использованием – в страничный файл или в какой-то другой. Если бы у диспетчера памяти не было таких списков, то всякий раз, когда какой-нибудь процесс обращался бы к данным, ранее удаленным из его рабочего набора, диспетчеру памяти приходилось бы считывать их с диска. A так диспетчер памяти может просто вернуть нужную страницу в рабочий набор процесса (если она, конечно, присутствует в одном из этих списков). To есть списки служат кэшами данных из страничного файла, исполняемых образов или файлов данных. Значит, общий объем файловых данных, кэшируемых в системе, складывается не только из размера системного рабочего набора, но и из размеров списков простаивающих и модифицированных страниц.
Вот пример, иллюстрирующий, как диспетчер кэша способен привести к кэшированию в физической памяти гораздо большего объема файловых данных, чем может содержаться в системном рабочем наборе. Рассмотрим систему, выступающую в роли выделенного файл-сервера. B этой системе имеется 8 Гб физической памяти, и виртуальный размер кэша составляет 960 Мб (максимальный размер в х8б-системах). Таким образом, предельный размер файловых данных, которые можно напрямую спроецировать в виртуальную память кэша, составляет 960 Мб. Клиентское приложение обращается к файловым данным на сервере через сеть. Драйвер файл-сервера (\Windows\System32\Drivers\Srv.sys) (см. главу 12) использует интерфейсы диспетчера кэша для чтения и записи файловых данных в интересах клиента. Если клиенты считывают несколько тысяч файлов, каждый размером по 1 Мб, диспетчеру кэша придется повторно использовать представления при проецировании 961-го файла. При последующих операциях чтения он будет отменять проецирование представлений для старых файлов и заново проецировать их для новых. Когда диспетчер кэша отменяет проецирование какого-либо представления, диспетчер памяти не отбрасывает файловые данные в рабочем наборе кэша, соответствующие этому представлению, а перемещает их в список простаивающих страниц. B отсутствие запросов на выделение физической памяти под любые другие задачи список простаивающих страниц может занимать почти всю физическую память за вычетом системного рабочего набора. Иначе говоря, практически все 8 Гб физической памяти сервера будут задействованы для кэширования файловых данных, как показано на рис. 11-6.
Рис. 11 -6.
Пример использования почти всей физической памяти под файловый кэш
Поскольку общий объем кэшируемых файловых данных складывается из размеров системного рабочего набора, списка модифицированных страниц и списка простаивающих страниц, а эти размеры контролируются диспетчером памяти, в каком-то смысле его можно назвать истинным диспетчером кэша. Подсистема диспетчера кэша просто предоставляет удобные интерфейсы для доступа к файловым данным через диспетчер памяти и определяет политики опережающего чтения (read-ahead) и отложенной записи (write-behind), которые влияют на то, какие данные диспетчер памяти будет удерживать в физической памяти.
Для более точного отображения полного объема файловых данных, кэшируемых в системе, диспетчер задач и Process Explorer предоставляют параметр System Cache (Системный кэш), отражающий суммарный размер системного рабочего набора и списков простаивающих и модифицированных страниц. Пример для Process Explorer представлен на рис. 11-7.
(o)Каждый 256-килобайтный слот системного кэша описывается VACB.
(o)У каждого отдельно открытого кэшируемого файла есть закрытая карта кэша с информацией, применяемой для контроля опережающего чтения.
(o)Каждый кэшируемый файл имеет общую структуру карты кэша, которая указывает на слоты системного кэша, содержащие проецируемые представления файла.
Эти структуры и их взаимосвязи описываются в следующих разделах.
Как видно на рис. 11-9, в первом поле VACB содержится виртуальный адрес данных системного кэша. Второе поле является указателем на общую (совместно используемую) структуру карты кэша, которая идентифицирует кэшируемый файл. Третье поле определяет смещение начала представления (внутри файла). Наконец, VACB содержит счетчик ссылок на представление, т. е. число активных операций чтения или записи над данным представлением. При выполнении операции ввода-вывода над файлом счетчик ссылок VACB увеличивается на 1, а по окончании такой операции уменьшается на 1. Когда счетчик ссылок не равен 0, VACB считается активным. B случае обращения к метаданным файловой системы счетчик активных операций отражает число драйверов файловых систем, которые владеют заблокированными в памяти страницами данного представления.
У каждого кэшируемого файла (в противоположность объекту «файл») есть структура общей карты кэша(shared cache map), которая описывает состояние кэшируемого файла, в том числе его размер и (из соображений безопасности) длину его действительных данных. (O назначении поля длины действительных данных файла см. раздел «Кэширование с обратной записью и отложенная запись» далее в этой главе). Общая карта кэша также указывает на объект-раздел (поддерживаемый диспетчером памяти и описывающий проекцию файла на виртуальную память), список закрытых карт памяти, сопоставленных с этим файлом, и все VACB, описывающие представления файлов, проецируемые в данный момент на системный кэш. Взаимосвязи между этими структурами данных показаны на рис. 11-10.
При запросе на чтение данных из какого-либо файла диспетчер кэша должен ответить на два вопроса.
1. Находится ли файл в кэше?
2. Если да, то какие VACB (если таковые есть) ссылаются на запрошенный адрес?
Иначе говоря, диспетчер кэша должен выяснить, проецируется ли представление файла (с нужным смещением) на системный кэш. Если ни один VACB не содержит нужное смещение в файле, запрошенные данные в настоящий момент не проецируются на системный кэш.
Для учета представлений данного файла, проецируемых на системный кэш, диспетчер кэша поддерживает массив указателей на VACB – массив индексов VACB (VACB index array). Первый элемент массива индексов VACB ссылается на первые 256 Кб файла, второй – на следующие 256 Кб и т.д.
Схема на рис. 11-11 иллюстрирует четыре раздела из трех файлов, проецируемых в данный момент на системный кэш.
Когда процесс обращается к файлу по заданному адресу, диспетчер кэша ищет подходящий элемент в массиве индексов VACB для этого файла, чтобы определить, проецируются ли на кэш запрошенные данные. Если элемент массива отличен от 0 (и, следовательно, содержит указатель на VACB), нужная область файла находится в кэше. VACB в свою очередь указывает на адрес, по которому на системный кэш проецируется представление файла. A если элемент массива равен 0, диспетчер кэша должен найти в системном кэше свободный слот (а значит, свободный VACB) для проецирования необходимого представления.
ПРИМЕЧАНИЕ B силу некоторых причин сетевым редиректорам труднее поддерживать когерентность кэша, чем локальным файловым системам, и они должны реализовать дополнительные операции сброса и очистки кэша. Ha эту тему см. главу 12.
Кэширование виртуальных блоков
Диспетчеры кэша многих операционных систем (включая Novell NetWare, OpenVMS и ранние версии UNIX) кэшируют данные на основе логических блоков.B этом случае диспетчер кэша отслеживает, какие блоки дискового раздела находятся в кэше. Диспетчер кэша Windows, напротив, использует кэширование виртуальных блоков.Этот метод заключается в том, что диспетчер кэша отслеживает, какие части и каких файлов находятся в кэше. Диспетчер кэша реализует этот метод за счет проецирования их 256-кило-байтных представлений на системную часть виртуальных адресных пространств с помощью специальных процедур диспетчера памяти. Основные преимущества такого подхода описываются ниже.(o)Появляется возможность реализации интеллектуального опережающего чтения (intellegent read-ahead), так как диспетчер кэша следит за тем, части каких файлов находятся в кэше, и это позволяет ему предсказывать, к какой следующей порции данных обратится вызывающая программа.
(o)Подсистема ввода-вывода может запрашивать данные, уже находящиеся в кэше, в обход файловой системы (быстрый ввод-вывод). Поскольку диспетчеру кэша известно, какие части и каких файлов находятся в кэше, он может вернуть адрес кэшируемых данных для выполнения запроса на ввод-вывод без обращения к файловой системе.
Подробнее об интеллектуальном опережающем чтении и быстром вводе-выводе мы расскажем чуть позже.
Кэширование потоков данных
B диспетчер кэша заложена поддержка не только кэширования файлов, но и кэширования потоков данных(stream caching) – последовательности байтов в файле. B файлах таких файловых систем, как NTFS, может быть более одного потока данных. Диспетчер кэша поддерживает эти файловые системы за счет независимого кэширования каждого потока. NTFS способна использовать эту функциональность (см. главу 12). И хотя о диспетчере кэша можно сказать, что он кэширует файлы, фактически он кэширует именно потоки данных (в любом файле есть минимум один поток данных), идентифицируемые по имени файла и, если в нем более одного потока, по имени потока.Поддержка восстанавливаемых файловых систем
Восстанавливаемые файловые системы вроде NTFS способны реконструировать структуру дискового тома после аварии системы. Это означает, что операции ввода-вывода, еще выполнявшиеся на момент аварии, должны быть либо доведены до конца, либо корректно отменены после перезагрузки системы. Частично выполненные операции ввода-вывода могут повредить дисковый том и даже сделать его недоступным. Bo избежание такой проблемы восстанавливаемая файловая система ведет файл журнала, в котором регистрирует каждое предполагаемое обновление структуры файловой системы (метаданные файловой системы) – еще до того, как оно будет выполнено. Если сбой происходит во время изменения данных тома, восстанавливаемая файловая система использует информацию из файла журнала и выполняет нужные операции.ПРИМЕЧАНИЕ Термин метаданные относится только к изменениям в структуре файловой системы в результате создания, переименования и удаления файлов и каталогов.
Чтобы обеспечить успешное восстановление тома, каждый элемент (запись) файла журнала, документирующий изменения в данных тома, должен быть записан на диск до самого обновления данных. Поскольку запись на диск кэшируется, файловая система должна взаимодействовать с диспетчером кэша, чтобы гарантировать выполнение следующей последовательности операций.
1. Файловая система заносит в файл журнала запись, документирующую изменение данных тома, которое она собирается выполнить.
2. Файловая система вызывает диспетчер кэша для сброса на диск записи файла журнала.
3. Файловая система записывает в кэш обновленные данные тома, т. е. модифицирует свои кэшируемые метаданные.
4. Диспетчер кэша сбрасывает модифицированные метаданные на диск, обновляя структуру тома. (Ha самом деле записи файла журнала, как и модифицированные метаданные, сбрасываются на диск пакетами.) Записывая данные в кэш, файловая система предоставляет номер логической последовательности(logical sequence number, LSN), который идентифицирует запись файла журнала, соответствующую обновлению кэша. Диспетчер кэша отслеживает эти номера, регистрируя наименьший и наибольший LSN (представляющие первую и последнюю записи файла журнала); такие номера сопоставляются с каждой страницей кэша. Кроме того, потоки данных, защищенные записями журнала транзакций, помечаются NTFS как «не записываемые», чтобы подсистема записи спроецированных страниц не сбросила эти страницы на диск до того, как туда будут сброшены соответствующие записи файла журнала. (Обнаружив помеченную таким образом страницу, подсистема записи спроецированных страниц перемещает ее в специальный список страниц, которые диспетчер кэша сбрасывает на диск в подходящий момент.)
Когда диспетчер кэша готов сбросить на диск группу измененных страниц, он определяет наибольший LSN, сопоставленный со сбрасываемыми на диск страницами, и сообщает его файловой системе. Далее файловая система может ответно вызвать диспетчер кэша и заставить его сбросить данные файла журнала вплоть до точки, представленной указанным LSN. Сбросив данные файла журнала вплоть до указанного LSN, диспетчер кэша сбрасывает на диск и соответствующие обновления в структуре тома, что гарантирует регистрацию предстоящих операций до их выполнения. Таким образом и достигается возможность восстановления дискового тома после аварии системы.
Управление виртуальной памятью кэша
Поскольку диспетчер кэша Windows кэширует файлы на основе виртуальных блоков, ему передается регион в системной части виртуальных адресных пространств (а не область физической памяти). Диспетчер кэша разбивает такой регион на 256-килобайтные слоты, называемые также представлениями (рис. 11-2). (Подробнее о структуре системного пространства см. главу 7.)Диспетчер кэша проецирует представления файлов на слоты адресного пространства кэша по принципу карусели: первое запрошенное представление – на первый 256-килобайтный слот, второе – на второй и т. д. рис. 11-3). B этом примере первым был спроецирован файл В, вторым – А, третьим – С, поэтому проецируемая часть файла B занимает первый слот кэша. Заметьте, что спроецирована лишь первая 256-килобайтная часть файла В, так как обращение было лишь к части файла и так как файл С, размер которого составляет всего 100 Кб, требует выделения своего 256-килобайтного слота кэша.
Диспетчер кэша гарантирует, что представление проецируется на то время, пока оно активно (хотя представления могут оставаться спроецированными после того, как становятся неактивными). Однако представление помечается как активное, только когда выполняется операция чтения или записи над соответствующим файлом. Если процесс, открывающий файл вызовом CreateFile,не указывает флаг FILE_FLAG_RANDOM_ACCESS, диспетчер кэша прекращает проецировать неактивные представления этого файла при проецировании его новых представлений. Страницы отключенных проекций посылаются в список простаивающих или модифицированных страниц (в зависимости от того, были ли они изменены); при этом диспетчер кэша, используя специальный интерфейс диспетчера памяти, может указать, в каком месте списка следует разместить эти страницы – в конце или в начале.
Страницы, соответствующие представлениям файлов, открытых с флагом FILE_FLAG_SEQUENTIAL_SCAN, перемещаются в начало списков, а все остальные – в конец. Такая схема способствует повторному использованию страниц, которые принадлежат файлам, открытым для последовательного чтения, и заставляет использовать малые объемы физической памяти при копировании больших файлов.
Если диспетчеру кэша требуется спроецировать представление файла, а свободных слотов в кэше нет, он отключает неактивное представление, спроецированное последним, и использует освободившийся слот. B отсутствие таких представлений возвращается ошибка ввода-вывода с сообщением о том, что системных ресурсов для выполнения данной операции недостаточно. Эта ситуация крайне маловероятна, так как возникает только при одновременном доступе к тысячам файлов.
Размер кэша
B следующих разделах мы объясним, как Windows вычисляет размер системного кэша. Как и в большинстве других вычислений, связанных с управлением памятью, размер системного кэша определяется несколькими факторами, в том числе объемом памяти и конкретным выпуском Windows.LargeSystemCache
Как вы увидите в дальнейшем, параметр LargeSystemCache в разделе реестра HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management влияет как на виртуальный размер кэша, так и на физический. По умолчанию в Windows 2000 Professional и Windows XP это значение равно 0, а в системах Windows Server – 1. B Windows 2000 Server данное значение можно регулировать через GUI, изменяя свойства службы файлового сервера; для этого надо открыть окно свойств сетевого соединения и выбрать File And Printer Sharing For Microsoft Networks (Служба доступа к файлам и принтерам сетей Microsoft). Эта служба имеется и в Windows 2000 Professional, но там ее параметры настраивать нельзя. Ha рис. 11 -4 показано диалоговое окно, через которое в Windows 2000 Server можно изменить объем памяти, выделяемой для локальных и сетевых приложений сетевой службой сервера.B Windows 2000 Server с установленными Terminal Services (Службы терминала) переключатель Maximize Data Throughput For File Sharing (Макс, пропускная способность доступа к общим файлам), показанный на рис. 11-4, активен по умолчанию, т. е. параметр LargeSystemCache равен 1. При выборе любого другого переключателя параметр LargeSystemCache становится равным 0. Каждый из переключателей диалогового окна File And Printer Sharing For Microsoft Networks Properties влияет не только на поведение системного кэша, но и на службу файлового сервера.
B Windows XP и Windows Server 2003 модифицировать параметр LargeSystemCache можно через диалоговое окно Performance Options (Параметры быстродействия), которое открывается щелчком кнопки Settings (Параметры) в разделе Performance (Быстродействие) на вкладке Advanced (Дополнительно) апплета System (Система) из Control Panel (Панель управления). B этом диалоговом окне перейдите на очередную вкладку Advanced (Дополнительно). Если в разделе Memory Usage (Использование памяти) вы выбираете System Cache (системного кэша), параметру LargeSystemCache присваивается значение 1, а если вы выбираете Programs (программ) – 0 (рис. 11-5).
Виртуальный размер кэша
Виртуальный размер системного кэша является функцией объема установленной физической памяти. По умолчанию это значение равно 64 Мб. Если в системе более 4032 страниц (16 Мб) физической памяти, виртуальный размер кэша устанавливается равным 128 Мб плюс 64 Мб на каждые дополнительные 4 Мб физической памяти. Используя этот алгоритм, можно подсчитать виртуальный размер системного кэша на компьютере, например, с 64 Мб физической памяти:128 Мб + (64 Мб – 16 Мб) / 4 Мб * 64 Мб = 896 Мб
Минимальный и максимальный виртуальные размеры системного кэша на разных платформах, а также его стартовый и конечный адреса показаны в таблице 11 -1. Если на платформе x86 рассчитанный системой виртуальный размер кэша превышает 512 Мб, он ограничивается 512 Мб; однако при параметре LargeSystemCache, равном 1, в той же ситуации кэшу назначается до 960 Мб виртуальной памяти из дополнительного диапазона адресов, называемого дополнительной памятью кэша(cache extra memory). Основное преимущество выделения под кэш большего объема виртуальной памяти заключается в том, что это позволяет уменьшить число операций проецирования и отмены проецирования представлений при обращении к разным файлам и разным представлениям файлов.
ЭКСПЕРИМЕНТ: просмотр виртуального размера кэша
Виртуальный размер кэша не показывается каким-либо счетчиком производительности, так что единственный способ узнать его значение – получить содержимое переменной ядра MmSizeOfSystemCacheInPages\
Размер рабочего набора кэша
Как уже упоминалось, одно из ключевых отличий архитектуры диспетчера кэша Windows от таковой в других операционных системах – делегирование управления физической памятью диспетчеру памяти. Ввиду этого размером кэша управляет уже имеющийся в операционной системе код, отвечающий за обработку расширения и усечения рабочего набора, а также за управление списками модифицированных и простаивающих страниц.У системного кэша нет собственного рабочего набора – он использует единый системный набор, в который входят кэш данных, пул подкачиваемой памяти, а также подкачиваемый код Ntoskrnl и драйверов. Как упоминалось в главе 7, этот рабочий набор имеет внутреннее название рабочий набор системного кэша,но системный кэш является лишь одним из его элементов. Поэтому мы будем использовать термин «системный рабочий набор». Также в главе 7 мы обратили ваше внимание на то, что при присвоении параметру реестра LargeSystemCache значения 1 диспетчер памяти отдает предпочтение системному рабочему набору по сравнению с рабочими наборами процессов, выполняемых в системе.
Выяснить физический размер системного кэша, сравнить его с суммарным физическим размером системного рабочего набора, а также получить информацию об ошибках страниц для системного рабочего набора позволяют счетчики производительности или системные переменные, перечисленные в таблице 11-3.
ЭКСПЕРИМЕНТ: просмотр рабочего набора кэша
Как показано на листинге ниже, команда !filecacbeотладчика ядра выводит дамп информации о физической памяти, используемой кэшем, текущем и пиковом размерах рабочего набора, количестве действительных страниц, сопоставленных с представлениями, и, где это возможно, имена файлов, проецируемых на представления. (Драйверы файловых систем кэшируют метаданные с помощью безымянных файловых потоков.)
Физический размер кэша
Хотя системный рабочий набор включает объем физической памяти, проецируемой на представления в виртуальном адресном пространстве кэша, он не обязательно отражает общий объем файловых данных, кэшируемых в физической памяти. Между этими двумя значениями нередко бывают расхождения, потому что часть файловых данных может находиться в принадлежащем диспетчеру памяти списке простаивающих или модифицированных страниц.Вспомните из главы 7, что при усечении рабочего набора или замене страниц диспетчер памяти может переместить измененные страницы из рабочего набора в список простаивающих или модифицированных страниц – в зависимости от того, куда должны быть записаны данные, содержащиеся на такой странице, перед ее повторным использованием – в страничный файл или в какой-то другой. Если бы у диспетчера памяти не было таких списков, то всякий раз, когда какой-нибудь процесс обращался бы к данным, ранее удаленным из его рабочего набора, диспетчеру памяти приходилось бы считывать их с диска. A так диспетчер памяти может просто вернуть нужную страницу в рабочий набор процесса (если она, конечно, присутствует в одном из этих списков). To есть списки служат кэшами данных из страничного файла, исполняемых образов или файлов данных. Значит, общий объем файловых данных, кэшируемых в системе, складывается не только из размера системного рабочего набора, но и из размеров списков простаивающих и модифицированных страниц.
Вот пример, иллюстрирующий, как диспетчер кэша способен привести к кэшированию в физической памяти гораздо большего объема файловых данных, чем может содержаться в системном рабочем наборе. Рассмотрим систему, выступающую в роли выделенного файл-сервера. B этой системе имеется 8 Гб физической памяти, и виртуальный размер кэша составляет 960 Мб (максимальный размер в х8б-системах). Таким образом, предельный размер файловых данных, которые можно напрямую спроецировать в виртуальную память кэша, составляет 960 Мб. Клиентское приложение обращается к файловым данным на сервере через сеть. Драйвер файл-сервера (\Windows\System32\Drivers\Srv.sys) (см. главу 12) использует интерфейсы диспетчера кэша для чтения и записи файловых данных в интересах клиента. Если клиенты считывают несколько тысяч файлов, каждый размером по 1 Мб, диспетчеру кэша придется повторно использовать представления при проецировании 961-го файла. При последующих операциях чтения он будет отменять проецирование представлений для старых файлов и заново проецировать их для новых. Когда диспетчер кэша отменяет проецирование какого-либо представления, диспетчер памяти не отбрасывает файловые данные в рабочем наборе кэша, соответствующие этому представлению, а перемещает их в список простаивающих страниц. B отсутствие запросов на выделение физической памяти под любые другие задачи список простаивающих страниц может занимать почти всю физическую память за вычетом системного рабочего набора. Иначе говоря, практически все 8 Гб физической памяти сервера будут задействованы для кэширования файловых данных, как показано на рис. 11-6.
Поскольку общий объем кэшируемых файловых данных складывается из размеров системного рабочего набора, списка модифицированных страниц и списка простаивающих страниц, а эти размеры контролируются диспетчером памяти, в каком-то смысле его можно назвать истинным диспетчером кэша. Подсистема диспетчера кэша просто предоставляет удобные интерфейсы для доступа к файловым данным через диспетчер памяти и определяет политики опережающего чтения (read-ahead) и отложенной записи (write-behind), которые влияют на то, какие данные диспетчер памяти будет удерживать в физической памяти.
Для более точного отображения полного объема файловых данных, кэшируемых в системе, диспетчер задач и Process Explorer предоставляют параметр System Cache (Системный кэш), отражающий суммарный размер системного рабочего набора и списков простаивающих и модифицированных страниц. Пример для Process Explorer представлен на рис. 11-7.
Структуры данных кэша
Для отслеживания кэшируемых файлов диспетчер кэша использует следующие структуры данных.(o)Каждый 256-килобайтный слот системного кэша описывается VACB.
(o)У каждого отдельно открытого кэшируемого файла есть закрытая карта кэша с информацией, применяемой для контроля опережающего чтения.
(o)Каждый кэшируемый файл имеет общую структуру карты кэша, которая указывает на слоты системного кэша, содержащие проецируемые представления файла.
Эти структуры и их взаимосвязи описываются в следующих разделах.
Общесистемные структуры данных кэша
Диспетчер кэша отслеживает состояние спроецированных на системный кэш представлений с помощью массива структур данных, называемых блоками управления виртуальными адресами(virtual address control blocks, VACB). При инициализации системы диспетчер кэша выделяет часть пула неподкачиваемой памяти под VACB, необходимые для описания системного кэша. Адрес массива VACB запоминается в переменной CcVacbs.Каждый VACB описывает одно 256-килобайтное представление в системном кэше (рис. 11-8). Структура VACB показана на рис. 11-9.Структуры данных кэша, индивидуальные для каждого файла
Каждому открытому описателю файла соответствует объект «файл» (см. главу 9). Если файл кэшируется, его объект «файл» указывает на структуру закрытой карты кэша (private cache map), которая содержитдва адреса, по которым в последний раз происходило чтение данных. Кроме того, все закрытые карты кэша для открытых экземпляров файла связаны друг с другом.У каждого кэшируемого файла (в противоположность объекту «файл») есть структура общей карты кэша(shared cache map), которая описывает состояние кэшируемого файла, в том числе его размер и (из соображений безопасности) длину его действительных данных. (O назначении поля длины действительных данных файла см. раздел «Кэширование с обратной записью и отложенная запись» далее в этой главе). Общая карта кэша также указывает на объект-раздел (поддерживаемый диспетчером памяти и описывающий проекцию файла на виртуальную память), список закрытых карт памяти, сопоставленных с этим файлом, и все VACB, описывающие представления файлов, проецируемые в данный момент на системный кэш. Взаимосвязи между этими структурами данных показаны на рис. 11-10.
При запросе на чтение данных из какого-либо файла диспетчер кэша должен ответить на два вопроса.
1. Находится ли файл в кэше?
2. Если да, то какие VACB (если таковые есть) ссылаются на запрошенный адрес?
Иначе говоря, диспетчер кэша должен выяснить, проецируется ли представление файла (с нужным смещением) на системный кэш. Если ни один VACB не содержит нужное смещение в файле, запрошенные данные в настоящий момент не проецируются на системный кэш.
Для учета представлений данного файла, проецируемых на системный кэш, диспетчер кэша поддерживает массив указателей на VACB – массив индексов VACB (VACB index array). Первый элемент массива индексов VACB ссылается на первые 256 Кб файла, второй – на следующие 256 Кб и т.д.
Схема на рис. 11-11 иллюстрирует четыре раздела из трех файлов, проецируемых в данный момент на системный кэш.
Когда процесс обращается к файлу по заданному адресу, диспетчер кэша ищет подходящий элемент в массиве индексов VACB для этого файла, чтобы определить, проецируются ли на кэш запрошенные данные. Если элемент массива отличен от 0 (и, следовательно, содержит указатель на VACB), нужная область файла находится в кэше. VACB в свою очередь указывает на адрес, по которому на системный кэш проецируется представление файла. A если элемент массива равен 0, диспетчер кэша должен найти в системном кэше свободный слот (а значит, свободный VACB) для проецирования необходимого представления.