Почему DMBS не могут полагаться на пул буферов ОС?

Question

В статье Stonebraker ( Поддержка операционной системы для управления базами данных ) объясняется, что «накладные расходы на выборку блока из диспетчера буферного пула обычно включают в себя системные вызовы и перемещение из ядра в ядро."Забудьте о стратегии замены буфера и т. Д. Единственный вопрос, который я задаю, это процитированный.

Насколько я понимаю, когда СУБД хочет прочитать блок x, она выдает общую инструкцию чтения.Не должно быть никаких отличий от других приложений, запрашивающих чтение.

Я не ищу общие ответы (я получил их и прочитал статьи).Я ищу подробный ответ описанной проблемы.См. Вызывает ли системный вызов чтение файла из приложения Java?

Answer 1

Чтение другого вопроса и дальнейшая работа:

Когда СУБД должна перенести страницу с диска, будет включать как минимум один системный вызов.В его момент большинство СУБД помещают страницу в свой собственный буфер.(Они также попадают в буфер ОС, но это неважно).

Итак, у нас есть один системный вызов.Однако мы можем избежать дальнейших системных вызовов.Это возможно, потому что СУБД кэширует страницы в своем собственном пространстве памяти.Первое, что СУБД сделает, когда решит, что ей нужна страница, это проверит и посмотрит, есть ли она в кеше.Если он это делает, он извлекает его оттуда, даже не вызывая системный вызов.

СУБД может свободно удалять страницы из своего кэша любым удобным для нее способом для нужд ввода-вывода.Срок действия кэша ОС истек в более общем смысле, поскольку у ОС есть и другие поводы для беспокойства.Одним из примеров этого является то, что СУБД обычно использует большое количество памяти для кэширования страниц, поскольку она знает, что дисковый ввод-вывод является одной из самых дорогих вещей, которые она может сделать.ОС не будет этого делать, поскольку должна сбалансировать стоимость дискового ввода-вывода с наличием памяти для использования другими приложениями.

Answer 2

Операционная система дискового ввода-вывода должна быть обобщена для работы в различных ситуациях.Иногда СУБД может получить значительную производительность, используя менее общий код, оптимизированный под свои нужды.

СУБД выполняет свое собственное кэширование, поэтому не хочет работать через кэширование O / S.Он «владеет» патчем диска, поэтому ему не нужно беспокоиться о совместном использовании с другими процессами.

Обновление Ссылка на статью является справочной.

* 1008Во-первых, газете уже почти тридцать лет, и она касается устаревшего оборудования.Несмотря на это, это делает чтение довольно интересным.

Во-первых, следует понимать, что дисковый ввод-вывод является многоуровневым процессом.Это было в 1981 году и тем более сейчас.В самой низкой точке драйвер устройства будет выдавать физические инструкции чтения / записи для оборудования.Выше этого может быть код ядра o / s, затем код пользовательского пространства o / s, затем приложение.Между функцией fread () программы C и движущимися головками дисков существует как минимум три или четыре уровня, и их может быть значительно больше.СУБД может стремиться улучшить производительность, может пытаться обойти некоторые уровни и напрямую взаимодействовать с ядром или даже ниже.

Я вспоминаю несколько лет назад установку Oracle на Sun box.У него была возможность выделить диск как «сырой» раздел, где Oracle будет форматировать диск по-своему, а затем напрямую говорить с драйвером устройства.Операционная система вообще не имела доступа к диску.

Answer 3

Я знаю, что это старая версия, но она осталась без ответа.

По существу:

1. ОС использует отдельные адресные пространства для каждого процесса.
2. Для извлечения информации из любого другого адресного пространства требуется системный вызов или ошибка страницы.** (см. ниже)
3. СУБД - это процесс с собственным адресным пространством.
4. Пул буферов операционной системы, который описывает Stonebraker, находится в адресном пространстве ядра.

Итак ... чтобы получить данные из адресного пространства ядра в адресное пространство СУБД, системный вызов или ошибка страницы неизбежны.

Вы правы, что доступ к данным из диспетчера пула буферов ОС стоит не дороже обычного вызова read ().(На самом деле, сделано с обычным вызовом чтения.) Однако Стоунбрейкер не говорит об этом.Он специально обсуждает потребности СУБД в кешировании: после данные были прочитаны с диска и присутствуют в ОЗУ.

По сути, он говорит, что кеш буферного пула ОС слишком медленныйдля использования СУБД, поскольку она хранится в другом адресном пространстве.Он предлагает использовать локальный кеш в том же процессе (и, следовательно, то же адресное пространство), что может дать вам значительное ускорение для приложений, таких как СУБД, которые сильно бьют по кешу, потому что это устранит эти издержки системного вызова.

Вот точный абзац, где он обсуждает использование локального кэша в том же процессе:

Однако многие СУБД, включая INGRES [20] и System R [4], предпочитают ставитьУправляемый пул буферов СУБД в пространстве пользователя для уменьшения накладных расходов.Следовательно, каждая из этих систем столкнулась с проблемой создания собственного диспетчера буферного пула для повышения производительности.

Он также упоминает многоядерные проблемы в приведенной выше выдержке.Подобные эффекты применимы и здесь, потому что если вы можете иметь только один кеш на ядро, вы сможете избежать замедления из-за сбросов кеша ЦП, когда несколько ЦП читают и записывают одни и те же данные.

** Кстати, я полагаю, что статья Стоунбрейкера 1981 года на самом деле предварительная.Он упоминает это как будущую работу.«Тенденция к предоставлению файловой системы как части общей виртуальной памяти (например, Pilot [16]) может обеспечить решение этой проблемы».

Answer 4

Реальная проблема заключается в том, что кеш файлового буфера не находится в файловой системе, используемой СУБД; он находится в ядре и используется всеми файловыми системами, находящимися в системе.Любая память, считанная из ядра, должна быть скопирована в пространство пользователя: это движение ядра к ядру, о котором вы читаете.

Помимо этого, некоторые другие причины, по которым вы не можете полагаться на системный буферный пул:

1. Часто СУБД действительно хорошо представляют свои будущие шаблоны доступа и не могут передавать эти шаблоны ядру.Это может привести к снижению производительности.
2. Буферный кэш традиционно хранится в диапазоне памяти ядра фиксированного размера, поэтому он не может увеличиваться или уменьшаться.Это также означает, что кэш-память намного меньше основной памяти, поэтому, используя буферный кеш, СУБД не сможет использовать системные ресурсы.

Answer 5

Это в основном проблема с производительностью.DBMS имеет очень специфические и необычные требования к вводу / выводу.

В ОС может быть любое количество процессов, выполняющих ввод / вывод и заполняющих свои буферы сортированными кэшированными данными, которые это создает.

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

И затем возникает проблема, заключающаяся в том, что общий «блок» может на самом деле составить значительно большую нагрузку ввода-вывода (это зависит от разбиения и тому подобное), чем в идеале хотел бы переносить dbms;его собственный кэш может быть настроен для лучшей работы с разметкой данных на диске и, таким образом, способен минимизировать операции ввода-вывода.

Еще одним вопросом является проблема индексов и аналогичных средств для ускорения запросов, чтоконечно, работает лучше, если кеш на самом деле знает что это вообще означает.