Пора провести финальные тесты и подвести итоги цикла статей. Сегодня мы рассмотрим влияние размера shared_buffers на производительность БД. Первые части можно почитать здесь и здесь.

В ходе развития сервиса оптимизации затрат на сотовую связь Dr. Tariff (iOS, Android) для совместного пилота с одним из партнеров нам потребовалась большая и производительная реляционная база данных.

Зависимость производительности БД от параметра shared_buffers

Параметр PostgreSQL shared_buffers задает максимальный объем оперативной памяти для кэширования на уровне базы данных. Количество записей – 10 миллиардов, количество активных подключений – 64, нагрузка на чтение. В этом тесте после изменения файла конфигурации происходил перезапуск сервера БД, поэтому перед измерением данных происходил тестовый запуск на несколько минут, чтобы кэш успел заполниться.



Производительность чтения практически не зависит от размеров shared_buffers. Размер БД в 40 раз выше, чем количество оперативной памяти в компьютере. При таком соотношении и использовании всего объема данных практически каждое чтение требует обращения к диску.
В реальных ситуациях не следует пренебрегать этим параметром, так как Postgres будет кешировать наиболее часто используемые данные и таблицы меньшего размера.

Зависимость производительности БД от параметра fsync

В PostgreSQL есть параметр fsync, который отвечает за перенос данных из оперативной памяти на диск по завершению транзакции. По умолчанию он включен, и обеспечивает сохранность данных в случае сбоя. Сбой может быть вызван отключением питания, зависанием системы, сбоем в дисковой подсистеме… Если произошел сбой и fsync=on, то при очередном запуске БД данные будут востановлены. Если же сбой произошел, но при этом fsync=off, то скорее всего данные придется восстанавливать из последнего дампа. Отключение данного параметра позволяет существенно повысить скорость update и insert операций.



Производительность после отключения fsync выросла в 2-3 раза. Это очень хороший показатель.

Сравнение скорости SSD и HDD дисков

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



Как видим скорость работы БД на HDD диске замедлилась в сотню раз в сравнении с одиночным SSD при таком характере нагрузки. Подобная нагрузка требовательна к iops дисков. Iops для SSD и HDD как раз отличаются на два порядка. Для баз данных традиционно используется рейд массив из быстрых HDD дисков. Быстрые HDD диски имеют iops в 1.5-2 раза выше, чем HDD, который участвовал в тестировании. Еще в несколько раз можно увеличить скорость за счет рейд массива.

Резюме

Несмотря на все преимущества у SSD есть недостатки:

• более высокая цена
• ограниченный ресурс на запись

Высокая цена оправдывается высокой производительностью. Современные SSD диски обладают достаточным ресурсом записи, даже для таких применений как база данных. Есть хорошая статья по тестированию ресурса SSD дисков.

Из данного тестирования и предыдущего опыта работы можем сделать следующие выводы:

1. PostgreSQL хорошо работает с большими таблицами с количеством строк до 10 миллиардов и с количеством клиентов до 1 тысячи
2. При размерах БД намного больше объема оперативной памяти и простых запросах производительность ограничивается дисковой подсистемой, а shared_buffers практически не влияет на производителность. Параметр fsync позволяет в разы увеличить скорость записи в БД.
3. SSD диски имеют намного большую производительность применительно к базам данных, чем HDD диски и занимают свою нишу.
4. SSD диски плохо масштабируются в RAID-0 массиве для случайного чтения. Если задача позволяет, то предпочтительнее использовать несколько баз данных на отдельных дисках, чем одну большую базу данных на RAID массиве.

А наиболее выгодный тариф подскажет приложение Dr. Tariff на Android и на iOS.


Подписывайтесь на наши новости и делитесь информацией с друзьями в Вконтакте и Facebook.