Размер страницы PostgreSQL для SSD

Перевод статьи PostgreSQL page size for SSD, автор - Fabien COELHO

В предыдущем посте я описал время, необходимое базе данных PostgreSQL для разогрева с жесткого диска при загрузке только на чтение для базы данных, помещающейся в памяти.

В этом посте я хочу рассмотреть производительность записи на SSD, сосредоточившись на влиянии размера страницы PostgreSQL (blockize), а также на проверке актуальности текущего значения по умолчанию 8 кБ.

Пояснение: эта заметка посвящена простой OLTP-нагрузке на чтение и запись (в основном запись) небольших кортежей, сгенерированной с помощью pgbench на базе, которая помещается в памяти. Выводы действительно применимы к этому случаю.

Другие SSD-тесты PostgreSQL

Я заинтересовался, прочитав пост Ханса-Юргена Шенига, который тестировал очень большие блоки размером 1 МБ, а также стандартные размеры страниц. Что меня поразило, так это значительное влияние меньшего размера страницы на производительность OLTP (на 6% лучше для 4 кБ, на 10% лучше для 2 кБ, при 8 кБ в качестве эталона), что говорит о том, что 8 кБ по умолчанию не обязательно является лучшим выбором, особенно при использовании SSD. Однако тест проводится на относительно небольшой базе данных (масштабный коэффициент pgbench 10 дает около 150 МБ), в течение короткого времени (обычно 1 минута) и с низкой производительностью (менее 150 tps), учитывая, что использовался SSD.

Я также нашел старую, но отличную статью Томаша Вондры, который играл с опциями файловой системы, а также с размером страницы PostgreSQL и блока WAL. Результаты показывают +40% прирост производительности для страниц размером 4 кБ по сравнению со страницами размером 8 кБ при нагрузке чтение-запись на SSD. Масштабирование в 300 pgbench является значительным, зарегистрированные прогоны кажутся 5-минутными, а производительность +1000 tps соответствует аппаратному обеспечению SSD. Недостатком является то, что размеры страниц и блоков WAL сдвинуты вместе, и, похоже, сообщается только о результатах одной попытки, хотя мой прошлый опыт работы с pgbench заставляет меня опасаться воспроизводимости и стабильности производительности.

Настройка теста

Я выбрал pgbench simple updates with prepared transactions (-N -M prepared), чтобы сфокусироваться на производительности записи без вмешательства соперников, масштаб 100, чтобы база данных была достаточно большой, но могла храниться в памяти, 4 клиента (-c 4), поскольку мой ноутбук имеет 2 ядра HT. Я запускаю несколько 1000-секундных тестов, чтобы получить, надеюсь, значимую статистику. При производительности SSD 1000-секундные тесты в основном перезаписывают большинство строк в таблице счетов.

Я использовал конфигурацию по умолчанию почти для всего (размер блока ext4 4 кБ, параметры монтирования, PostgreSQL 9.4b2): Меня интересует относительная производительность по отношению к изменяющемуся размеру страницы, а не абсолютная наилучшая производительность, и так было проще. В частности, использование журналируемой файловой системы приводит к значительному снижению производительности. В качестве SSD используется Lite-On IT LMT-256M6M mSATA 256GB на ноутбуке Dell XPS 13.

Результаты

Вот результаты производительности для 10 запусков, для размеров страниц 2, 4 и 8 кБ. Прирост составил 10,4% для страниц размером 4 кБ и еще 1,9% для страниц размером 2 кБ.

bs avg & stdev min median max
 2 999.6 ± 21.7 955.7 1005.2 1025.1
 4 982.5 ± 15.6 945.7 983.8 1001.2
 8 890.2 ± 18.6 857.6 886.0 922.3

Детальные ежесекундные измерения tps с параметром --progress=1 показывают разумную стабильность производительности во время работы, с периодическими, но не слишком глубокими подъемами и спадами, подобно тому, что демонстрирует Томаш Вондра. Я также провел 200-секундные тесты, которые показали аналогичные результаты, хотя с более низкой минимальной производительностью, а также средней, возможно, скрытая изменчивость, которая сглаживается более длительным прогоном.

Первое улучшение является последовательным для всех показателей (среднее, минимум, медиана, максимум) и находится далеко за пределами стандартного отклонения, поэтому, хотя количество прогонов ограничено, я уверен, что оно значительное. Второе улучшение также является последовательным, но уверенность ниже. Более того, поскольку базовые блоки ext4 имеют размер 4 кБ, рациональность использования страниц размером 2 кБ неясна.

Анализ

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

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

В этом есть компромисс, и это не удивительно. Однако производительность случайных операций ввода-вывода не всегда одинакова в зависимости от базового оборудования: производительность случайного чтения/записи на жестких дисках составляет несколько процентов от последовательного чтения/записи, в то время как на твердотельных накопителях она может достигать более 50% от последовательной записи в зависимости от глубины очереди, например, см. обзоры Tom's Hardware.

Для жестких дисков случайные чтения и записи, которые происходят при обращении к страницам и их обновлении, имеют очень высокую стоимость: накладные расходы на чтение или запись доминируют над временем обращения к диску. В этом контексте чтение или запись 8 кБ или 4 кБ стоит одинаково и обходится дорого, поэтому давайте сделаем больше: кэш будет заполняться быстрее, что может помочь улучшить коэффициент попадания и, следовательно, производительность. Я думаю, что именно в этом кроется логика такого выбора.

Для SSD, поскольку стоимость случайного чтения и записи гораздо ниже по сравнению с HDD, стимул для больших страниц на этот счет меньше.

Вывод

При использовании SSD с меньшим размером страницы в 4 кБ для OLTP-нагрузки с чтением и записью, как показывает pgbench, наблюдается значительное положительное влияние на производительность (с учетом ограничений этого конкретного бенчмарка, см. примечание ниже). Однако прирост производительности не такой большой, как у Томаша Вондры.

Это говорит о том, что возможность изменять этот параметр и, возможно, размер блока WAL проще, чем перекомпиляция PostgreSQL, может быть хорошим шагом.

Следующий вопрос - что происходит при игре с размером страницы PostgreSQL на жестких дисках. Это может быть темой другого поста.

Примечание: Джош Беркус отметил, что это не доказывает, что меньший размер страницы всегда выгоден, особенно учитывая, что pgbench использует довольно маленькие 100-байтовые кортежи, и что сама база небольшая. Я могу только согласиться! Другие бенчмарки могут привести к другим выводам о наилучшем размере страницы. Моя точка зрения заключается скорее в том, что размер страницы должно быть проще подстроить, поскольку он оказывает последовательное и значительное влияние на производительность. Я провел больше тестов с большими строками, хотя все еще с маленькой базой, которые показывают некоторое преимущество при меньших страницах.