Какой размер страницы выбрать для базы данных?

28.10.2021.

Актуализация древней статьи. На 2021 год размер страницы для БД нужно выбирать такой:

• Наиболее оптимальный размер страницы для баз до 10-15 гигабайт (примерно) - это 8192 байт. Умолчательные 4 килобайта можно использовать, но на совсем мелких базах, до 1 гиг. Даже для таких мелких баз увеличение размера страницы до 8к может повысить производительность.
• Для баз 15 гигабайт и выше рекомендуется размер страницы 16384 байт. Особенно для тех, которые хранят много документов в блобах.
• В Firebird 4 есть возможность указать размер страницы 32к. Однако, работу с таким размером страницы нужно проверять с осторожностью, т.к. из-за большого размера повышается конкуренция за страницы при модификации данных (вставка, обновление, удаление).

Размер страницы можно изменить при restore, опцией -page_size n. Делается это один раз, в регулярные скрипты restore вставлять этот параметр категорически нельзя (вы об этом забудете, и при очередном изменении размера страницы "вручную" ваш скрипт всё вернет назад). Используемый размер страницы сохраняется в бэкапе, поэтому по умолчанию рестор производится с тем размером страницы, который был в исходной базе.

Изложенное дальше можно прочитать разве что из интереса к истории, т.к. текст примерно до 2000 года.


Анна Харрисон, Harbor Software:
 

IB дает 4-х варианта выбора:

• 1024 – слишком маленький
• 2048 – не такой большой
• 4096 – то, что надо
• 8192 – никогда не видела, чтобы работало лучше, чем 4096.

Чарли Каро, InterBase Software Corp.:
 

Стоимость вычисления контрольных сумм пропорциональна размеру страницы базы данных. Контрольная сумма страницы вычисляется всегда при чтении или записи страницы в БД. For the large page sizes, this was our private op-code for telling microprocessors to flush their L1 and L2 level hardware caches.

В IB Database 5.0 для Windows NT вычисление контрольной суммы страницы выключено, поэтому вам не нужно заботиться об этом при выборе размера страницы БД.

Я не могу сказать, помогает ли установить размер страницы БД равным размеру страницы памяти операционной системы, но могу дать некоторые комментарии по поводу размера блока буфера кэша файловой системы. Поскольку большинство операционных систем используют механизм virtual memory mapping для буфера кэша, то как правило размер страницы виртуальной памяти равен размеру страницы буфера кэша.

Наш опыт, приобретенный при создании write-ahead log поверх файловой системы, показывает что важно обеспечить совпадение размера блоков ввода-вывода с размером блока буфера кэша файловой системы. Log-файлы как правило не вмещаются в буфер кэша и периодически записываются по checkpoint interval. Задача буферизации ввода-вывода – прочитать блок определенной длины с тем, чтобы оставить его резидентным. Если размер, запрашиваемый вводом-выводом такой-же как и у буфера ОС, то лишних чтений не происходит. Если же размер блока буфера ОС отличается от блока ввода-вывода, то это вызвает дополнительное чтение данных с диска файловой системой – не совсем желательный сценарий для производительности. Если для log используется последовательное чтение, то дополнительные операции чтения не влияют на производительность, т. к. все равно используется механизм опережающего чтения.

Для IB существует два случая, в которых такое поведение может повлиять в худшую сторону. Когда IB читает страницы БД, то страницы кэшируются два раза: 1) в кэш-буфере базы данных IB, и 2) в кэш-буфере операционной системы. Другие подсистемы сервера (файловый сервис, web-сервер) могут вытеснить страницы БД из кэша операционной системы. Если теперь IB модифицирует некую страницу, находящуюся в кэше, то при несовпадении размеров блока кэша ОС и страницы БД операционная система прочитает часть данных с диска, и запишет полный измененный блок на диск. Если размеры страниц равны, то будет аллокирован новый блок в кэш буфере, прочитан, и только после этого записан блок с изменениями на диск.

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

Все вышеизложенное относится к Unix. Я не делал тестов для Windows NTFS. В любом случае, большая часть NTFS пришла из DEC (VMS file system). Но VMS не имеет буфера кэша... (RMS не в счет).

Для NTFS (Windows NT) лучше всего отформатировать раздел с размером кластера 4К для размещения баз данных. Соответственно, у всех баз данных, помещаемых в таком разделе, лучше выбрать размер страницы 4К. Размер страниц 1К, 2К и 8К будет приводить к лишним чтениям с диска (1К, 2К) или лишней записи (8К).