Что такое диспетчер кэша
Обеспечение высокой производительности диспетчера кэша и памяти
По умолчанию Windows кэширует данные файлов, которые считываются с дисков и записываются на диски. Это означает, что при операциях чтения данные файлов считываются из области в системной памяти, известной как системный файловый кэш, а не с физического диска. Соответственно, при операциях записи данные файлов записываются в системный файловый кэш, а не на диск. Такой тип кэша называется кэшем обратной записи. Управление кэшированием осуществляется для каждого файлового объекта. Кэшированием управляет диспетчер кэша, который работает непрерывно, пока выполняется Windows.
Данные файлов в системном файловом кэше записываются на диск с интервалами, определяемыми операционной системой. Записанные на диск страницы остаются либо в рабочем наборе системного кэша (если задан параметр FILE_FLAG_RANDOM_ACCESS и не был закрыт дескриптор файла), либо в списке ожидания, где они хранятся в доступной памяти.
Политика отсрочки записи данных в файл и хранения в кэше, пока кэш очищается, называется отложенной записью. Она активируется диспетчером кэша через определенный интервал. Время записи на диск блока данных частично зависит от длительности его хранения в кэше, а также от времени, прошедшего с момента последнего обращения к этим данным при выполнении операции чтения. Это гарантирует, что данные файлов, которые часто считываются, останутся доступными в системном файловом кэше максимально долго.
Этот процесс кэширования данных файлов показан на следующем рисунке.
Как показано на предыдущем рисунке сплошными стрелками, область размером в 256 КБ данных считывается в слот кэша размером в 256 КБ в системном адресном пространстве, когда диспетчер кэша впервые запрашивает ее во время операции чтения файла. Затем процесс пользовательского режима копирует данные из этого слота в свое собственное адресное пространство. Завершив обращение к данным, процесс записывает измененные данные в тот же слот в системном кэше. На рисунке это обозначено пунктирной стрелкой между адресным пространством процесса и системным кэшем. Когда диспетчер кэша определяет, что определенное время данные уже требуются, он записывает измененные данные в файл на диске, как показано пунктирной стрелкой между системным кэшем и диском.
Что такое диспетчер кэша
Внутреннее устройство Microsoft Windows (главы 8-11)
Защита конфиденциальных данных от несанкционированного доступа очень важна в любой среде, где множество пользователей обращается к одним и тем же физическим или сетевым ресурсам. У операционной системы, как и у отдельных пользователей, должна быть возможность защиты файлов, памяти и конфигурационных параметров от нежелательного просмотра и внесения изменений. Безопасность операционной системы обеспечивается такими очевидными механизмами, как учетные записи, пароли и защита файлов. Ho она требует и менее очевидных механизмов — защиты операционной системы от повреждения, запрета непривилегированным пользователям определенных действий (например, перезагрузки компьютера), предотвращения неблагоприятного воздействия программ одних пользователей на программы других пользователей или на операционную систему.
B этой главе мы поясним, как жесткие требования к защите повлияли на внутреннее устройство и реализацию Microsoft Windows.
Четкие стандарты безопасности программного обеспечения, в том числе операционных систем, помогают правительству, корпорациям и индивидуальным пользователям защищать хранящиеся в компьютерных системах данные, составляющие личную и коммерческую тайну. Текущий стандарт на рейтинги безопасности, применяемый в США и многих других странах, — Common Criteria (CC). Однако, чтобы понять средства защиты, существующие в Windows, нужно знать историю системы рейтингов безопасности, повлиявшей на архитектуру системы защиты Windows, — Trusted Computer System Evaluation Criteria (TCSEC).
Национальный центр компьютерной безопасности (National Computer Security Center, NCSC, www.radium.ncsc.mil/tpep) был создан в 1981 году в Агентстве национальной безопасности (NSA) Министерства обороны США. Одна из задач NCSC заключалась в определении рейтингов безопасности (см. таблицу 8–1), отражающих степень защищенности коммерческих операционных систем, сетевых компонентов и приложений. Эти рейтинги, детальное описание которых вы найдете по ссылке www.radium.ncsc.mil/tpepflibrary/rainbow/5200.28-STD.html, были определены в 1983 году и часто называются «Оранжевой книгой» («Orange Book»).
Стандарт TCSEC состоит из рейтингов «уровней доверия» («levels of trust» ratings), где более высокие уровни строятся на более низких за счет последовательного ужесточения требований к безопасности и проверке. Ни одна операционная система не соответствует уровню Al (Verified Design). Хотя некоторым операционным системам присвоен один из уровней В, уровень C2 считается достаточным и является высшим для операционных систем общего назначения.
B июле 1995 года Windows NT 3.5 CWorkstation и Server) с Service Pack 3 первой из всех версий Windows NT получила подтверждение об уровне безопасности C2. B марте 1999 года организация ITSEC (Information Technology Security) правительства Великобритании присвоила Windows NT 4 с Service Pack 3 уровень E3, эквивалентный американскому уровню C2. Windows NT 4 с Service Pack 6a получила уровень C2 для сетевой и автономной конфигураций.
Какие требования предъявляются к уровню безопасности C2? Основные требования (они остались прежними) перечислены ниже.
• Механизм безопасной регистрации, требующий уникальной идентификации пользователей. Доступ к компьютеру предоставляется лишь после аутентификации.
• Управление избирательным доступом, позволяющее владельцу ресурса определять круг лиц, имеющих доступ к ресурсу, а также их права на операции с этим ресурсом. Владелец предоставляет пользователям и их группам различные права доступа.
• Аудит безопасности, обеспечивающий возможность регистрации событий, связанных с защитой, а также любых попыток создания, удаления и обращения к системным ресурсам. При входе регистрируются идентификационные данные всех пользователей, что позволяет легко выявить любого, кто попытался выполнить несанкционированную операцию.
• Защита при повторном использовании объектов, которая предотвращает просмотр одним из пользователей данных, удаленных из памяти другим, а также доступ к памяти, освобожденной предыдущим пользователем. Например, в некоторых операционных системах можно создать новый файл определенной длины, а затем просмотреть те данные, которые остались на диске и попали в область, отведенную под новый файл. Среди этих данных может оказаться конфиденциальная информация, хранившаяся в недавно удаленном файле другого пользователя. Так что защита при повторном использовании объектов устраняет потенциальную дыру в системе безопасности, заново инициализируя перед выделением новому пользователю все объекты, включая файлы и память. Windows также отвечает двум требованиям защиты уровня В.
• Функциональность пути доверительных отношений (trusted path functionality), которая предотвращает перехват имен и паролей пользователей программами — троянскими конями. Эта функциональность реализована в Windows в виде входной сигнальной комбинации клавиш Ctrl+Alt+Del и не может быть перехвачена непривилегированными приложениями. Такая комбинация клавиш, известная как SAS (secure attention sequence), вызывает диалоговое окно входа в систему, обходя вызов его фальшивого эквивалента из троянского коня.
• Управление доверительными отношениями (trusted facility management), которое требует поддержки набора ролей (различных типов учетных записей) для разных уровней работы в системе. Например, функции администрирования доступны только по одной группе учетных записей — Administrators (Администраторы).
Windows соответствует всем перечисленным требованиям.
B январе 1996 года США, Великобритания, Германия, Франция, Канада и Нидерланды опубликовали совместно разработанную спецификацию оценки безопасности Common Criteria for Information Technology Security Evaluation (CCITSE). Эта спецификация, чаще называемая Common Criteria (CC) (csrc.nist.gov/cc), является международным стандартом оценки степени защищенности продуктов.
CC гибче уровней доверия TCSEC и по структуре ближе ITSEC, чем TCSEC CC включает две концепции:
• профиля защиты (Protection Profile, PP) — требования к безопасности разбиваются на группы, которые легко определять и сравнивать;
• объекта защиты (Security Target, ST) — предоставляет набор требований к защите, которые могут быть подготовлены с помощью PR Windows 2000 оценивалась на соответствие требованиям Controlled Access PP, эквивалентным TCSEC C2, и на соответствие дополнительным требованиям Common Criteria в октябре 2002 года. K значимым требованиям, не включенным в Controlled Access PP, но предъявляемым по условиям Windows 2000 Security Target, относятся:
• функции управления избирательным доступом (Discretionary Access Control Functions), основанные на применении криптографии. Они peaлизуются файловой системой Encrypting File System и Data Protection API в Windows 2000;
• политика управления избирательным доступом (Discretionary Access Control Policy) для дополнительных пользовательских объектов данных (User Data Objects), например объекты Desktop и WindowStation (реализуются подсистемой поддержки окон Windows 2000), а также объекты Active Directory (реализуются службой каталогов в Windows 2000);
Содержание:
В одной из наших прошлых статей мы коснулись такого аспекта работы RAM как аппаратно зарезервированная память, объём которой можно посмотреть в Диспетчере задач, переключившись на вкладку «Производительность» и выбрав слева блок «Память». Так вот, помимо этой самой зарезервированной памяти там имеются и другие данные о работе ОЗУ, которые могут вызвать у пользователя вопросы. Например, что такое кэшированная память в Диспетчере задач, почему она иногда занимает так много места, можно и нужно ли предпринимать какие-либо меры с целью её уменьшения?
↑ Кэшированная оперативная память
Такие разные кэши
Перед тем как приступать к разбору обозначенного вопроса, следует сказать о том, что кэши бывают разные. Есть всем известный браузерный кэш — каталог файловой системы, в котором веб-обозреватели хранят временные данные; не менее известным типом кэша является располагающийся на физическом жёстком диске файл подкачки, в который система сбрасывает непомещающиеся в оперативную память данные; существуют и так называемые промежуточные кэши, например, служащая буфером между ОЗУ и центральным процессором кэш-память, реализованная в виде высокоскоростной микросхемы SRAM. Рассмотрим принцип её работы чуть более подробно.
Что такое кэш процессора, и как он работает
Когда ЦП обращается к оперативной памяти, чтобы считать или записать в неё данные, он сначала идентифицирует ячейку, с которой собирается работать. Для этого он формирует и отправляет в память запрос, RAM же его обрабатывает и открывает доступ процессору к хранящимся в соответствующей ячейке данным. Эта процедура занимает некоторое время, а поскольку процессор гораздо шустрее оперативной памяти, он вынужден ждать ответа от ОЗУ. Чтобы ускорить получение процессором данных из оперативной памяти, была придумана так называемая быстрая оперативная память, или иначе кэш-память.
Таким образом, кэшированная память сокращает время отклика и повышает общую производительность компьютера. Соответственно, чем больше у вас на компьютере такой памяти, тем быстрее он должен работать. Тут, наверное, у многих из наших читателей возникнет такой вопрос: если быстрая память так хороша, почему ею не заменяют обычную оперативную память? Ответ прост — всё дело в цене, кэш-память намного дороже обычной памяти, поэтому она используется в ограниченных объёмах.
↑ Что такое кэшированная память в Диспетчере задач
Однако мы увлеклись, вернёмся к нашему вопросу, вернее к той кэшированной памяти, которую может обнаружить у себя в Диспетчере задач каждый пользователь.
Кстати, сведения об этой памяти указаны также в оснастке «Монитор ресурсов», в котором она обозначена секцией синего цвета «Ожидание». По сути, кэшированная память представляет собой часть свободной оперативной памяти, выделенной под неиспользуемые данные наиболее приоритетных процессов.
В то же время кэшированная память не привязана жёстко к данным процессам, поэтому её страницы могут быть использованы для записи других, менее приоритетных процессов. Убедиться в этом вы можете сами, открыв пару десятков вкладок в браузере. Вы увидите, что объем доступной кэшированной памяти сразу станет меньше, а всё потому, что зарезервированные страницы были переданы браузеру для записи в них данных вкладок. Из этого следует, что беспокоиться вам нужно не о увеличении размера кэшированной памяти, а скорее наоборот — об уменьшении доступного объёма кэша при отсутствии свободной памяти, выделенной в Мониторе ресурсов голубым цветом.
Нужно ли очищать кэшированную память
Особой нужды в очистке кэшированной памяти нет, более того, постоянная принудительная её очистка может привести к неравномерной нагрузке процессора, более частому обращению к файлу подкачки и общему снижению производительности. Исключения составляют те случаи, когда вы точно установили связь между увеличением объёма кэшированной памяти с падением производительности, что иногда бывает в играх. Тогда на собственный страх и риск вы можете включить очистку кэша оперативной памяти.
Очистка кэшированной памяти в RAMMap и EmptyStandbyList
Самый простой способ обнулить кэш оперативную память — это воспользоваться бесплатной тулзой RAMMap, разработанной одним из сотрудников Microsoft Марком Руссиновичем. Утилита не требует установки, чтобы очистить в ней память, выберите в главном меню Empty → Empty Standby List. Объем кэшированной памяти тут же уменьшится в несколько раз, но уже через несколько минут система опять её зарезервирует.
Также вы можете воспользоваться такой утилитой как EmptyStandbyList, работающей по тому же принципу что и функция Empty Standby List в утилите RAMMap. В отличие от RAMMap, тулза EmptyStandbyList не имеет графического интерфейса, чтобы очистить с её помощью кэшированную память, достаточно просто запустить исполняемый файл. Естественно, через некоторое время кэш снова будет заполнен, если вы хотите это предотвратить, в Планировщике заданий вам нужно создать задачу, которая станет запускать исполняемый файл EmptyStandbyList.exe каждые 2, 3, 5, 10 или сколько вам нужно минут.
Откройте Планировщик командой taskschd.msc, справа нажмите «Создать» задачу
и выставьте настройки как показано на скриншоте. Обратите внимание, что в качестве пользователя мы указываем Систему, тогда как по умолчанию задание будет выполняться от имени учётной записи администратора. В условиях запуска (триггеры) указываем интервал между запусками задачи, на вкладке «Действия» указываем путь к исполняемому файлу утилиты. Сохраняем задание и проверяем его работу.
Использовать этот трюк или нет, решать вам. Если вы наблюдаете чрезмерное заполнение RAM-кэша, сопровождающееся снижением производительности в играх или при работе с «тяжёлыми» приложениями, пробуйте, в остальных случаях особого смысла в очистке кэша памяти мы не видим.
Блог Makeomatic: разработка сайтов и мобильных приложений
Как работает реляционная база данных
В прошлой серии мы подробно поговорили про статистику, оптимизатор запросов, алгоритмы объединения, теперь разберёмся с диспетчером данных.
Диспетчер данных
На этапе выполнения запроса диспетчеру запросов необходимы данные таблиц и индексов, за ними он обращается к диспетчеру данных. Здесь есть два сложных момента:
Диспетчер кэша
Для повышения производительности во всех современных БД есть диспетчер кэша.
Предвыборка данных
Для этого существует предвыборка данных. Диспетчер запросов знает (благодаря статистике), какие данные есть на диске, и какие данные ему понадобятся (поскольку ему известен план выполнения запроса). Работает это примерно так: во время обработки первого набора данных, диспетчер запросов просит диспетчер кэша предварительно загрузить второй набор данных в буфер; во время обработки второго набора данных, диспетчер кэша получает команду предварительно загрузить третий набор данных и удалить из кэша первый. И так далее. Вместе с данными диспетчер кеша сохраняет в буферный пул дополнительную информацию (фиксатор – latch), чтобы своевременно очищать кэш, если данные более не нужны.
В некоторых БД диспетчер запросов не имеет возможности знать заранее, какие данные ему понадобятся — в этом случае осуществляется предвыборка предполагаемых необходимых данных (например, если диспетчеру запросов понадобились данные 1, 3, 5, скорее всего, он в скором времени запросит и данные 7, 9, 11). Иногда также используется последовательная предвыборка (когда диспетчер кеша просто подгружает в буфер данные, следующие сразу за запрошенными).
Для измерения эффективности предвыборки данных в современных БД есть коэффициент попадания в кэш. Он отражает, насколько часто запрашиваемые данные были получены из буферного пула, без обращения к диску. К слову, низкий коэффициент ещё не означает, что предвыборка данных работает плохо — подробнее об этом можно прочитать в документации Oracle.
Разумеется, объём буферной памяти не безграничен, и чтобы загружать новые данные, нужно очищать кэш от старых, это достаточно ресурсозатратная операция. Если у вас есть часто выполняемый запрос, не имеет смысла каждый раз загружать его в кеш, а потом удалять.Для таких случаев современные БД используют стратегию замены буфера.
Стратегии замены буфера
Для простоты будем считать, что данные в буфере не фиксированы (то есть их можно удалить). В нашем примере буфер может хранить 3 набора данных. Алгоритм действует следующим образом:
Этот алгоритм работает хорошо, но у него есть некоторые ограничения. Например, в случае полного сканирования большой таблицы. Если размер таблицы / индекса больше размера буфера, данный алгоритм удалит все предыдущие значения в кеше, хотя данные полного сканирования скорее всего будут использованы лишь один раз.
Чтобы такого не случалось, некоторые БД добавили специальные правила. Пример из документации Oracle: «В случае очень больших таблиц база данных, как правило, считывает наборы данных напрямую, без загрузки в кеш. Если таблица средних размеров, может использоваться как прямое считывание, так и загрузка из кеша. Если БД решает использовать чтение из кеша, данные помещаются в конец списка LRU, чтобы избежать очистки кеша».
Существует улучшенная версия алгоритма — LRU-K, используемая, например, в SQL Server (K=2). В случае LRU (где K=1) учитывается только, когда данные использовались в последний раз. Улучшенная версия анализирует, какие данные использовались последние K раз. Часто используемые данные обладают большим весом. При загрузке в кеш нового набора данных, старые часто используемые данные не удаляются (поскольку количество раз их использования больше). Но в случае, если данные не используются часто, алгоритм не хранит их в кеше. Таким образом, со временем вес данных снижается, если они реже используются.
Расчет веса данных требует некоторых системных ресурсов, поэтому SQL Server использует только K = 2 — наиболее оптимальный вариант с точки зрения ресурсозатрат.
Более подробную информацию про LRU-K алгоритм вы найдёте в этой работе.
Другие алгоритмы
Есть и другие алгоритмы замены буфера: 2Q и CLOCK (похожи на LRU-K); MRU (Most Recently Used) — использует ту же логику, что и LRU, но другие правила; LRFU (Least Recently and Frequently Used), и так далее. В некоторых базах данных можно самостоятельно выбирать алгоритм.
Буфер записи
Мы говорили только про буферы чтения, которые подгружают данные перед их использованием. Но в базе данных есть и буферы записи, которые позволяют группировать данные и передавать их наборами, что сокращает количество обращений к диску.
Следует помнить, что в буфере хранятся страницы (минимальная единица данных), а не ряды (то, как мы визуально представляем данные). Если страница в буферном пуле была изменена, но не записана на диск, она считается «грязной». Существуют различные алгоритмы для вычисления лучшего времени для записи «грязных» страниц на диск, все они вписываются в транзакционную модель, о которой и поговорим далее.
Диспетчер транзакций
Основное правило транзакционной модели: одна транзакция — один запрос.
Давайте сначала разберёмся, что же такое ACID-транзакции.
ACID-транзакция предусматривает четыре условия:
Вернёмся к характеристикам ACID-транзакций:
Многие современные базы данных не используют изолированность по умолчанию, поскольку она очень ресурсозатратна. В SQL 4 уровня изолированности:
Например, транзакция A совершает
SELECT COUNT (1) from TABLE_X
после чего транзакция B добавляет новые данные в TABLE_X; если транзакция A снова выполнит count(1), результат будет уже другим.
Многие базы данных добавляют свои собственные уровни изоляции (например, снэпшоты, используемые в PostgreSQL, Oracle и SQL Server). И, разумеется, в большинстве БД реализованы не все уровни изоляции (чтение нефиксированных данных встречается не часто).
Уровень изоляции, установленный по умолчанию, можно изменить при первом соединении (буквально одной строчкой кода).
Управление многозадачностью
Для решения этой проблемы при каждом запуске или отмене транзакции нужно:
Другими словами, это проблема нахождения оптимальных графиков выполнения транзакций. Базы данных не могут тратить слишком много времени на нахождение самого оптимального графика для каждой новой транзакции, поэтому они выбирают менее эффективные подходы и тратят время на разрешение конфликтующих транзакций.
Диспетчер блокировок
Чтобы справиться с проблемами многозадачности, многие БД используют блокировки и/или управление версиями данных. Рассмотрим виды блокировок.
Полная блокировка
В целом, идея блокировки такова: если транзакции необходимы какие-либо данные, она их блокирует; если другой транзакции понадобятся эти же данные, ей придётся ждать, пока первая транзакция разблокирует доступ к ним.
Однако, крайне неразумно использовать полную блокировку для транзакции, которой необходимо только считать данные, поскольку другим транзакциям, которым также необходимо только считать данные, придётся ждать.
В таких случаях лучше использовать блокировку с обеспечением совместного доступа, которая работает так:
Вернёмся к диспетчеру блокировок.
Диспетчер блокировок
Диспетчер блокировок- это процесс, накладывающий и снимающий блокировки. Данные о блокировках хранятся в хеш-таблице (где ключ — заблокированные данные). Диспетчер знает, какие именно транзакции блокируют данные и какие транзакции ожидают разблокировки данных.
Взаимная блокировка
Однако, случаются ситуации, когда транзакциям придётся ждать разблокировки данных бесконечно:
На данной схеме транзакция A полностью блокировала данные 1 и ожидает разблокировки данных 2. При этом, транзакция B полностью блокировала данные 2 и ожидает разблокировки данных 1.
В такой ситуации диспетчер блокировок решает, какую блокировку отменить для разрешения конфликта. И это непростое решение. Стоит ли отменить транзакцию, изменившую наименьшее количество данных? Или же отменить самую последнюю транзакцию, поскольку клиенты других транзакций ожидали дольше? Стоит ли отменить наиболее короткую транзакцию? В случае отмены, на какое количество других транзакций это повлияет?
Но до принятие решения диспетчер блокировок должен убедиться, что взаимная блокировка действительно произошла. Если это так, это отразится в хеш-таблице блокировок в виде цикличного процесса. Однако, проверять всю таблицу на наличие таких циклов слишком ресурсозатратно. Поэтому часто просто используют таймауты: если разблокировка не происходит в течение заданного таймаута, значит, произошла взаимная блокировка.
Прежде, чем блокировать данные, диспетчер блокировок может проверить, не приведёт ли это к взаимоблокировке. Но, увы, такое вычисление тоже очень ресурсозатратно, поэтому часто используют набор простых правил.
Двухфазная блокировка
Наиболее просто обеспечить полную изолированность блокировок, если применять блокировку в начале транзакции и снимать по факту её завершения. Таким образом, транзакции приходится ждать снятия всех предыдущих блокировок до начала выполнения и снимать собственную блокировку после окончания выполнения. Звучит отлично, но между всеми этими ожиданиями потеряется куча времени.
Таким образом, блокировки, которые уже не нужны, снимаются, сокращая время ожидания других транзакций. Также благодаря протоколу исключаются ситуации, когда транзакция получает данные, в которые были внесены изменения до начала транзакции (соответственно, они не соответствуют запрашиваемым данным).
Протокол двухфазной блокировки работает отлично, кроме случаев, когда транзакция, изменившая данные и снявшая блокировку, отменяется. Может получиться, что другая транзакция в этот момент считывает изменённые данные, а изменения отменяются. Во избежание подобных ситуаций все полные блокировки должны сниматься только по окончании транзакции.
Конечно, в реальных базах данных используются и более глубокие блокировки (блокировки рядов, страниц, разделов, таблиц, табличных пространств).
Также для решения проблем многозадачности БД использую управление версиями данных, суть которого в следующем:
Управление версиями данных улучшает производительность БД, поскольку читающие транзакции не блокируют записывающие транзакции, и наоборот. Плюс мы экономим ресурсы, которые бы использовал медленный диспетчер блокировок.
Блокировка и управление версиями данных — это два разных подхода (пессимистичный и оптимистичный). У обоих свои плюсы и минусы (в зависимости от количества чтений/записей).
Рекомендую к прочтению презентацию от PostgreSQL про мультиверсионное управление многозадачностью.
Некоторые БД (DB2 до версии 9.7, SQL Server за исключением снепшотов) используют только блокировки. Другие (PostgreSQL, MySQL, Oracle) используют как блокировки, так и управление версиями данных. А вот базы данных, использующие только управление версиями данных, мне не известны.
Стоит отметить, что управление версиями данных иногда может внести хаос в индексы: в уникальных индексах могут появиться дубликаты, записей в индексах может оказаться больше, чем в таблице и т.д.
Правка (08/20/2015 ) в комментариях поделились информацией, что Firebird и Interbase применяют исключительно управление версиями данных.
В части про уровни изолированности мы выяснили, с повышением уровня увеличивается и количество блокировок, а значит и время ожидания транзакций снятия этих блокировок. Именно поэтому большинство БД не используют по умолчанию сериализованные транзакции (наивысший уровень изолированности).
Как обычно, советую изучить тему подробнее в официальных доках MySQL, PostgreSQL или Oracle.
Диспетчер логов
Итак, мы знаем, что для увеличения производительности, БД загружает данные в буферный пул. Но если сервер падает во время транзакции, данные, которые находились в памяти во время падения, будут утеряны, а это нарушает принцип надёжности транзакций.
Можно всё записывать сразу на диск, но если в процессе сервер выйдет из строя, у вас на диске в итоге будет лишь часть обновлённых данных, а это в корне нарушает принцип неразрывности транзакций.
В подобных случаях любые изменения, внесённые прерванной транзакцией, должны быть отменены.
Сделать это можно двумя способами:
Протокол предварительного логирования
Большинство БД (Oracle, SQL Server, DB2, PostgreSQL, MySQL, SQLite) используют протокол предварительного логирования (WAL – Write-Ahead Logging), работа которого основана на трёх правилах:
По идее, диспетчер логов должен располагаться между диспетчером кеша и диспетчером доступа к данным (который записывает данные на диск) и записывать каждую операцию изменения/удаления/создания/отката в лог транзакций до того, как эти изменения попадут на диск. Верно?
А вот и нет. После всего, что мы с вами узнали, несложно догадаться, что и тут, как всегда в случаях с базами данных, ключевая и решающая деталь — общая производительность. Если диспетчер логов будет тормозить, это негативно скажется на работе всей БД.
ARIES
В 1992 году инженеры IBM «создали» расширенную версию WAL под названием ARIES, которая в той или иной степени реализована во всех современных БД. Я написал «создали» в кавычках, потому что согласно этому курсу MIT, инженеры IBM сделали ничто иное как собрали воедино все лучшие практики восстановления транзакций. Но в данном случае это мелочи. Я прочёл большую часть научно-исследовательской работы по ARIES – на самом деле увлекательно! Далее я сделаю краткий обзор технологии, а за подробностями прошу обращаться к первоисточнику.
Итак, основные задачи, решаемые ARIES (Algorithms for Recovery and Isolation Exploiting Semantics):
а) обеспечить высокую производительность при записи в лог транзакций,
б) обеспечить быстрое и надёжное восстановление.
По каким причинам транзакция может быть отменена?
В некоторых случаях (например, сбой в сети) БД может восстановить транзакцию. Чтобы понять, как это происходит, разберёмся, какая информация хранится в логе.
В результате любой операции в логе создаётся запись, которая состоит из следующих компонентов:
Насколько мне известно, PostgreSQL – единственная БД, не использующая UNDO, это связано с управлением версиями данных. Вместо этого там реализован сборщик мусора, удаляющий старые версии данных.
Небольшой наглядный пример лога запроса UPDATE FROM PERSON SET AGE = 18; Предположим, данный запрос выполняется в транзакции 18.
Буфер логов
Для оптимизации работы логов существует буфер логов.
Упрощённо процесс записи в лог происходит следующим образом:
Если транзакция фиксируется, это значит, что все вышеперечисленные пункты выполнены для всех операций внутри транзакции. В конечном счёте, запись в лог транзакций — достаточно быстрая операция, поскольку это всего лишь запись лога в произвольное место в логе транзакций. В сравнении с этим запись на диск — более сложная и долгая операция, подразумевающая запись данных на диск таким образом, чтобы в дальнейшем их было легко считать.
Стратегии восстановления
В целях повышения производительности последний (6ой) пункт в некоторых БД может выполняться после фиксации транзакции, поскольку в случае падений системы транзакцию всё же можно восстановить с помощью информации REDO в логе. Такая стратегия называется произвольной (NO FORCE POLICY).
Однако, для снижения нагрузки во время восстановления БД может применить и силовую стратегию (FORCE POLICY) — когда запись изменений на диск диспетчером кеша производится только и исключительно до фиксации транзакции.
Кратко различия в стратегиях:
Процесс восстановления
Итак, у нас есть все засипи в логах, давайте посмотрим, как их используют.
Предположим, стажёр уронил нашу базу данных (правило №1: в любой непонятной ситуации виноват стажёр!). Перезапускаем БД, начинается процесс восстановления.
В ARIES этот процесс выглядит так: