Честное планирование дискового ввода-вывода с учетом разделяемых ресурсов файлового кэша (1187435), страница 4
Текст из файла (страница 4)
Проблема учета разделяемых данных в файловом кэшеПерейдем к рассмотрению второго, не менее важного, фактора проявлениянечестности в распределении ресурса файлового кэша между процессами. Рассмотримследующую ситуацию.Пусть группа процессов {(разделяемого) файлафайла} читают один из одного и того же общего, а также каждый процессчитает из своего собственного. Пусть заданные веса (приоритеты) в дисковом планировщике для всехпроцессовравны.
Тогда для честного распределения пропускной способности на уровнедиска получаем, что битрейты (скорость передачи данных) для всех процессовтакжеравны между собой.Пусть процесс(либо это могут быть несколько процессов из группы)систематически раньше читает разделяемый файл, т.е. считывает фрагменты этогофайла с диска в кэш чаще.
Тогда остальные процессы будут читать эти данныепреимущественно из кэша, и с точки зрения дискового планировщика ресурс диска причтении этих данных не используют. В результате процессуресурса на чтение своего собственного файласоответствующих файловбудет выделено меньше, чем другим процессам.Получаем, что общий битрейт на уровне файлового кэша у процессау каждого из остальныхна чтениеменьше, чем, даже при наличии честного распределения пропускнойспособности на уровне диска.
Таким образом, наличие разделяемых данных в файловомкэше может приводить к нечестному распределению пропускной способности дисковойподсистемы на уровне приложений.4.3. Примеры проявления в реальных системахПриведем некоторые примеры реальных вычислительных систем, для которыхнаиболее заметно проявление изложенных ранее проблем. Все они отличаются16значительнымколичествомданныхнадиске,разделяемыхмежду различнымипотребителями ресурсов дисковой подсистемы.Основнымпримеромявляютсясистемыконтейнернойвиртуализации(виртуализации уровня ОС). Запущенные на одной физической машине контейнерыиспользуют значительное количество общих данных на диске. В частности, почти всесистемные файлы – исполняемые файлы ядра ОС, драйверов, системные библиотеки и т.п.– являются общими на все контейнеры в системе.Другим примером являются системы с большим количеством виртуальных машин(или контейнеров), созданных из одного (базового) образа.
Виртуальные машины приэтом являются т.н. связанными клонами (linked clones), т.е. одинаковые для них данныехранятся на диске в единственном экземпляре. Одним из распространенных примеровтаких систем является VDI (Virtual Desktop Infrastructure) – инфраструктура виртуальныхрабочих столов. На серверах виртуализации в VDI запускается большое количествоодинаковых виртуальных машин или контейнеров, клонируемых из базового образа,содержащего необходимый набор установленных приложений.4.4. Обзор аналогичной проблемы учета разделяемой памятиРассмотриманалогичнуюпроблему,возникающуювзадачахуправленияпотреблением физической памяти процессами в операционных системах.
Суть задачисостоит в контроле размеров рабочих наборов процессов и групп процессов иподдержании этих размеров в пределах заданных диапазонов. При этом важной задачейявляется определение принадлежности страниц физической памяти процессам в системе.При этом в современных системах значительная доля памяти является разделяемой междудвумя и более процессами. В случае, если страница памяти является разделяемой, вопросучета ее принадлежности при вычислении размеров рабочих наборов процессовстановится нетривиальным.Задача управления размерами рабочих наборов решается, в частности, контроллеромпамяти (memory controller) в подсистеме группового управления ресурсами cgroups в ядреОС Linux, на основе которой строятся системы виртуализации уровня ОС (контейнернаявиртуализация) для этой операционной системы. В текущей реализации cgroups страницапамяти считается принадлежащей тому процессу (и соответствующей группе процессов),который первый начал ее использовать (первым вызвал page fault, в результате которогобыла выделена физическая страница).
В целом данный подход работает достаточнохорошо, но при его использовании могут возникать систематические нарушения учета17принадлежности страницы, приводящие к нарушению честности распределения ресурсафизической памяти в системе.В частности, в случае, когда процесс, первым начавший использовать страницупамяти, завершается, эта страница продолжает быть принадлежащей группе, членомкоторой являлся данный процесс. При этом она может продолжать использоватьсяпроцессами из других групп, что контроллером памяти никак не учитывается. Другимпримером является передача данных средствами IPC (inter-process communications) междупроцессами из разных групп по модели producer-consumer. Процесс-producer всегдаобращается к разделяемым страницам памяти раньше, чем процесс-consumer, такимобразом, именно producer будет считаться владельцем разделяемых страниц, хотяиспользуются они в равной мере обоими процессами.Для решения данной проблемы необходимо каким-либо образом записыватьразделяемую страницу «на счет» всех процессов, которые ее используют.
Одно изпредлагаемых решений предполагает соответствующее расширение системного вызоваmadvise(), позволяющего процессу сообщить подсистеме управления памятью в ядре ОСдополнительную информацию об использовании им диапазонов памяти, в частности,разделяемой с другими процессами.Длярешенияпроблемыучетаразделяемыхданныхвфайловомкэше,рассматриваемой в данной работе, также необходимо получать информацию обиспользовании этих данных отдельными процессами.
Однако в данном случае получениеэтой информации от самих процессов не является необходимым, т.к. обращения кфайловому кэшу в любом случае обрабатываются ядром ОС, в отличие от обращений кфизической памяти.185. Создание алгоритма планирования для учетаиспользования файлового кэшаДанный раздел посвящен основной задаче, решаемой в данной работе – построениюалгоритмапланированиядоступакдиску,позволяющегообеспечитьчестноераспределение пропускной способности дисковой подсистемы на уровне приложений, т.е.над файловым кэшем. Приводится математическая модель дисковой подсистемы ипостановка основной задачи в рамках этой модели.
Далее мы опишем предлагаемый методрешения задачи и приведем обоснование свойств полученного решения.Предложенное решение состоит во внесении в существующий базовый алгоритмпланирования необходимых модификаций для учета использования файлового кэшаотдельными процессами в системе. При этом описанные в предыдущем разделе 2 факторанечестности рассматриваются отдельно, и для каждого из них строится соответствующаямодификация алгоритма.
Приводится обоснование выбора BFQ в качестве базовогоалгоритма для модификации, а также анализ других возможностей построения дисковогопланировщика для учета файлового кэша.5.1. Постановка задачиПриведем формальные определения понятий, используемых при описании проблемычестного распределения пропускной способности диска, в частности, формализуем самопонятие честности. Далее мы приведем математическую постановку задачи в терминахописанной модели дисковой подсистемы.5.1.1. Математическая модель дисковой подсистемыДля начала дадим формальные определения основных понятий, используемых приописании постановки задачи.Запрос ввода-вывода на уровне приложений (над файловым кэшем):(где)– процесс-инициатор запроса,– размер запроса (в байтах),() – расположение запроса, совокупность файла и смещения в нем,– время прихода запроса,– время его исполнения,19(1)) – класс, к которому относится запрос, в частности, является(ли он синхронным или асинхронным, кэшированным или некэшированным.Аналогично определяется запросы на уровне файловой системы (между файловымкэшем и файловой системой) и на уровне диска:()с тем отличием, что расположение()(2)есть смещение от начала диска.
Отдельныепараметры запросов будем обозначать как, например,, либо ().Поток приходящих от каждого из приложений запросов представляет собойнекоторый случайный процесс. Для моделирования этого потока может быть использованпуассоновский поток переменной интенсивности.При прохождении через файловый кэш для запросаколичество «подзапросов» {порождается некоторое}. Число подзапросовможет быть равным 0 вслучае полного попадания запроса в кэш. Долей попадания в кэш (hit ratio) назовемследующую величину, равную 1 в случае полного попадания в кэш и равную 0 в случаеполного промаха или некэшированного запроса:()(∑ (Аналогично, при прохождении запросапорождается совокупность подзапросов {размер подзапросов ∑()) ⁄ ()(3)через файловую систему для него} , где) может быть как равным (, причем суммарный), так и меньше его (в случаесжатых и разреженных файлов) или больше (в случае дополнительных обращений кметаданным файловой системы).В отличие от оригинальной статьи с описанием алгоритма BFQ, мы не будемпредполагать, что диск исполняет запросы один за другим, по одному за раз.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
