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

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

В предыдущем посте я описал время, требуемое базе данных PostgreSQL, которая помещается в памяти, для чтения c HDD.

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

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

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

Я заинтересовался, прочитав пост Hans-Jürgen Schönig который испытал очень большой блок 1 МБ, а также стандартные форматы. Что меня поразило то , что есть значительное влияние меньшего размера страницы на производительность OLTP (6% лучше в течение 4 кбайт, 10% лучше в течение 2 кБ, 8 кБ как ссылки), что свидетельствует о том , что 8 кБ по умолчанию не обязательно лучший выбор, особенно при использовании SSD. Однако тест на относительно небольшой базы данных ( pgbench масштабный коэффициент 10 дает около 150 МБ), короткий промежуток времени (обычно 1 минута), а также с низкой производительностью (менее 150 ТПС), учитывая, что был использован SSD.

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

Испытательная установка

Я выбираю pgbench простые обновления с подготовленных транзакций ( -N -M prepared ) , чтобы сосредоточиться на производительности записи без помех конкурирующей, масштаб 100 так , что база данных является достаточно большой , но может быть сохранено в памяти, 4 клиентов ( -с 4 ) , потому что мой ноутбук имеет 2 HT ядер. Я бегу несколько секунд 1000 тестов с тем, чтобы вывести с надеждой значимой статистики. С производительностью SSD 1000 секунд тесты в основном перезаписать большинство строк в account  таблицы.

Я использовал конфигурацию по умолчанию для почти все (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

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

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

Анализ

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

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

Существует компромисс, не удивительно. Тем не менее, производительность подтекст случайных ИО не обязательно совпадают в зависимости от используемого оборудования: случайного чтения / записи на жестких дисках будет составлять около нескольких процентов от последовательного чтения / записи, в ​​то время как на SSD - накопителей это может быть до более чем 50% последовательного рисунка записи в зависимости от глубины очереди, смотри, например, обзоров аппаратного Тома.

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

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

Вывод

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

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

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

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