PostgreSQL performance with different storage types on HPE ProLiant servers

Dmitry Vasilyev,Senior consulting engineer, Postgres Professional, Russia

13.04.2016

Производительность СУБД PostgreSQL с разными типами внутреннего хранилища на серверах HPE ProLiant

Дмитрий ВасильевВедущий инженер-консультант, Postgres Professional, Россия

13.04.2016

About Postgres Professional

• Postgres Professional is the Russian PostgreSQL company

• Founded in 2015 by Russian PostgreSQL contributors

• 50+ employees, among them three Major PostgreSQL Contributors and four PhD

• Postgres Professional provides industrial PostgreSQL services: vendor technical support, migration, custom extensions and core patches development, migration-related consulting, training and certification

• http://postgrespro.com

• Postgres Pro is included in the Unified Registry of Russian Computer Programs and Databases in March, 2016.

• Postgres Professional had successfully performed large PostgreSQL projects including database migration projects for well-known Russian and international companies

• Postgres Professional is an active member of international PostgreSQL community. Postgres Professional developers had committed 63 patches to the latest release of PostgreSQL 9.6

* PostgreSQL database is used in HPE DataProtector and HPE OneView

О компании Postgres Professional

• Postgres Professional – российский вендор PostgreSQL

• Компания основана в 2015 году ведущими российскими разработчиками PostgreSQL*

• Более 50 сотрудников, в их числе ведущие российские разработчики PostgreSQL (major contributor), признанные международным сообществом PostgreSQL и 4 кандидата наук.

• Postgres Professional оказывает услуги поддержки, миграции, разработки, консалтинга, обучения.

• Сайт http://postgrespro.ru/

• СУБД Postgres Pro в марте 2016 года вошла в реестр отечественного ПО

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

• Postgres Professional является активным участником международного сообщества PostgreSQL: в очередной релиз PostgreSQL 9.6 войдет более 60 патчей, разработанных сотрудниками Postgres Professional

•

*СУБД PostgreSQL используется в том числе и в составе HPE DataProtector и HPE OneView

Non-Volatile Memory Spectrum

Traditional Storage Emerging StorageHot Data

Cold Data

Tier 0

Tier 1

Tier 2

Tier 3

HP SAS and SATA HDDs

HP SAS and SATA SSDs

HP PCIe Workload AcceleratorsNVMe SSD

PCIe Storage100s µs latency

SAS/SATA NAND Flash10s ms latency

SAS/SATA HDDs100s ms latency

HP Tape

SAS Tapeseconds/mins latency

Tier 0

Tier 1

Tier 2

Tier 3HP SAS and SATA HDDs

HP SAS and SATA SSDs

HP PCIe Workload AcceleratorsNVMe SSD

PCIe Storage100s µs latency

SAS/SATA NAND Flash10s ms latency

SAS/SATA HDDs100s ms latency

NVDIMM*ns latency

Caching

Indexing

In-Memory

Analytics

OLTP

Databases

Mail (Exchange)

Customer Relationship Management

Data Warehouse

Archive

Backup

HP NVDIMMs

* Mass shipment for HPE servers is expected in mid 2016

Практика организации внутреннего хранилища на серверах

Вчера/Сегодня«Горячие» данные

«Холодные» данные

Tier 0

Tier 1

Tier 2

Tier 3

HPE SAS и SATA HDD

HPE SAS и SATA SSD

HPE PCIe AcceleratorsHPE NVMe SSD

Накопители PCIeЗадержка - сотни мкс

SSD SAS/SATA Задержка – десятки мс

HDD SAS/SATAЗадержка - сотни мс

HPE Tape

Лента SASЗадержка – секунды или

минуты

КэшИндекс

АналитикаOLTP

Базы данных

ПочтаCRMERP

АрхивРезервная копия

Завтра

Tier 0

Tier 1

Tier 2

Tier 3HPE SAS и SATA

HDD

HPE SAS и SATA SSD

HPE PCIe Workload Accelerators

HPE NVMe SSD

NVDIMM*Задержка -

наносекунды

HPE Persistent Memory

Накопители PCIeЗадержка - сотни мкс

SSD SAS/SATA Задержка – десятки мс

HDD SAS/SATAЗадержка - сотни мс

* начало массовых отгрузок для серверов HPE в середине 2016

for all tests - max_connections = 300, shared buffers = 128MB, except for the test with a full load database into memory, where it was max_connections = 300, shared_buffers = 200GB, huge_pages = on

Benchmarking PostgresPro on HPE ProLiant Gen9 serverHigh performance on 2-processor systemsApplication: PostgresPro 9.5.2.1*

Benchmark/test: pgbench -S, that is randomly read full database**

Operation system: RHEL 7.2 with standard kernel and with updated kernel that support NVDIMM***

Hardware platform: HPE ProLiant DL380 Gen9 - 2*E5-2697v4 (2.3GHz/18-core/45MB/145W) + 256GB (8*32GB DDR4 RDIMM 2133) + 2*8GB NVDIMM + 2*250GB/7.2K SATA (for OS) + 4*400GB NVMe SSD + 2*200GB SSD SATA + 4*146GB/15K SAS + P440ar/2GB

* The distribution here http://postgrespro.com/products/downloadIn the database supplied patch indicating operating system don't cache data after read** Https://github.com/postgrespro/postgrespro/blob/PGPRO9_5/src/bin/pgbench/pgbench.c#L358 SELECT abalance FROM pgbench_accounts WHERE aid = RANDOM?;*** There is an active testing for quality and productive inclusion in the main release of the operating system, click here for details http://linux.hpe.com/nvdimm

The maximum possible result, when the entire database loaded into RAM

Option A: Traditional / Classic when stored on the HDD

Option C: the most advanced storage option when the tables were located on the NVMe, and the indexes located on NVDIMM

Option B: Traditional / Classic when stored on the SSD

для всех тестов – max_connections=300,shared_buffers=128MB, за исключением теста с полной загрузкой базы в память, где было max_connections=300, shared_buffers=200GB, huge_pages=on

Тестирование Postgres Pro на сервере HPE ProLiant Gen9Рекордная производительность на 2-х процессорных системах

Приложение: СУБД Postgres Pro 9.5.2.1*

Тип нагрузки: штатный тест pgbench -S, который выполняет случайное чтение по всему объему базы данных**

Операционная система: RHEL 7.2 со штатным ядром и ядром с поддержкой NVDIMM***

Аппаратная платформа: HPE ProLiant DL380 Gen9 - 2*E5-2697v4 (2.3GHz/18-core/45MB/145W) + 256GB (8*32GB DDR4 RDIMM 2133) + 2*8GB NVDIMM + 2*250GB/7.2K SATA (for OS) + 4*400GB NVMe SSD + 2*200GB SSD SATA + 4*146GB/15K SAS + P440ar/2GB

*Дистрибутив расположен по адресу http://postgrespro.ru/products/postgrespro/download/latestНа СУБД поставлен патч, указывающий операционной системе не помещать прочитанные данные в файловый кэш** https://github.com/postgrespro/postgrespro/blob/PGPRO9_5/src/bin/pgbench/pgbench.c#L358 SELECT abalance FROM pgbench_accounts WHERE aid = RANDOM;*** Идет активное тестирования, для получения продуктивного качества и включения в основной релиз ОС, подробности тут http://linux.hpe.com/nvdimm

Максимально возможный результат, когда вся база, целиком загружалась в оперативную память

Вариант А: традиционный/классический при хранении на HDD

Вариант С: самый передовой вариант хранения, когда файлы с таблицами располагались на NVMe, а индексы располагались на NVDIMM

Вариант Б: традиционный/классический при хранении на SSD

Thanks

Спасибо!

RHEL 7.2 tuning configurations

1. tuned-adm profile throughput-performance

2. mpathconf --enable --find_multipaths y --with_multipathd y; systemctl start multipathd; systemctl enable multipathd

3. sysctl: vm.dirty_background_bytes = 32Mb, vm.dirty_bytes = 64Mb*

Tested RHEL 7.2 kernels:

3.10 - 3.10.0-327.13.1.el7.x86_64

4.2 - 4.2.0-380.13.hpoj.x86_64

11*Influence of this parameter is uncertain

Ext4 file system

– PostreSQL uses filesystem layer to store data, it does not support raw block devices

– “nobarrier,sync” mount option were NOT used as it is not recommended for production environment

– All tested file systems were mounted with auto option (i.e. just mount)

12

PostgreSQL patch that bypass file system cacheThis patch is available for all Postgres Pro subscribers

diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c

index 28e90ce..820f400 100644

--- a/src/backend/storage/file/fd.c

+++ b/src/backend/storage/file/fd.c

@@ -1414,6 +1414,7 @@ FileRead(File file, char *buffer, int amount)

retry:

returnCode = read(VfdCache[file].fd, buffer, amount);

+ posix_fadvise(VfdCache[file].fd, VfdCache[file].seekPos, amount, POSIX_FADV_DONTNEED);

if (returnCode >= 0)

VfdCache[file].seekPos += returnCode;

13

pgbench benchmark for PostgreSQL databaseStandard benchmark that is widely used and adopted in the community

– pgbench is a simple program for benchmarking PostgreSQL. It runs the same sequence of SQL commands over and over again, possibly in multiple concurrent database sessions, and then calculates the average transaction rate (transactions per second). By default, pgbench tests a scenario that is loosely based on TPC-B, involving five SELECT, UPDATE, and INSERT commands per transaction. However, it is easy to test other cases by writing your own transaction script files. http://www.postgresql.org/docs/devel/static/pgbench.html

– https://github.com/postgrespro/postgrespro/blob/PGPRO9_5/src/bin/pgbench/pgbench.c#L358 SELECT abalance FROM pgbench_accounts WHERE aid = RANDOM;"

– Test results are not very database size sensible, the difference in performance for 20GB-200GB is around 5% (with small shared_buffers and disabled page cache)

– 200GB for all tests, except the test on NVMe+ NVDIMM, where it was 100GB

14

406 723 tps on 4*400GB NVMe SSD + 2*8GB NVDIMM

tps that the test want to measure

CPU utilization

Amount of IOPs

1 060 819 tps from cache

Transactions per second achieved

CPU utilization

zero IOPs here represents the fact of database location in memory

HPE ProLiant DL380 Gen9 with NVDIMM and RHEL 7.2