Тестируем PostgreSQL на SSD RAID-0 массиве с таблицей в 10 миллиардов записей. (Часть 1)

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

Производительности HDD диска было явно недостаточно. Размер базы должен был составить несколько сотен гигабайт, поэтому размещение ее в оперативной памяти было бы слишком дорого. SSD диск наилучшим образом подходит для этой задачи. Но одного SSD диска могло не хватить, поэтому было решено собрать RAID-0 массив из двух дисков. Пользуясь случаем мы решили провести тестирование производительности PostgreSQL на одном и двух SSD дисках.

Основные цели тестирования

1. Сравнить производительность PostgreSQL на SSD RAID-0 массиве с производительностью на одиночном SSD.
2. Изучить производительность базовых операций (SELECT и UPDATE) в зависимости от размера таблицы, количества подключений, настроек сервера и других параметров.

Тестирование проводилось в несколько итераций. По каждой части решено было написать подробную статью с отчетами:

1. Тестирование одного SSD диска
2. Тестирование RAID-0 массива из 2-х SSD дисков
3. Влияние настроек сервера на производительность БД
4. Сравнение SSD с HDD

Железная часть

Все тестирование производилось в следующей конфигурации:

• Intel i7 4770.
• 16 Gb RAM.
• Intel SSD для системного диска.
• Intel SSD 480 Gb 530 серии для диска в с базой данных. Model – SSDSC2BW480A401
• Toshiba HDD 3000 Gb. Model – DT01ACA300
• Файловая система всех разделов – Ext4. Диски подключены по интерфейсу SATA 3.

Софт

На тестовом компьютере установлена операционная система Linux Mint 17.2. Версия PostgreSQL — «PostgreSQL 9.4.4 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit»

После форматирования на SSD диске доступно 440Гб. На графике ниже представлена производительность одного SSD диска.



Производительность чтения и записи около 500 Мб/сек, узким местом является SATA интерфейс.

Настройки Postgres стандартные за исключением следующих параметров:
shared_buffers = 2048 Mb
port = 5400
max_connections = 1000

Тестирование

В качестве источника нагрузки было 3 варианта:

• стандартный pg_bench
• Python клиент с Psycopg2
• Python клиент с SQLAlchemy

Первые тесты pgBench показали хорошую производительность, но они работали на вновь сгенерированных таблицах. Нам хотелось, чтобы тест был максимально приближенным к реальным условиям. Конечно, можно написать собственный сценарий тестирования, но было отдано предпочтение Python клиенту.

Первым кандидатом в качестве клиента был SQLAlchemy. В нем есть возможность вызова сырых SQL команд через метод execute. Первые же тесты на маленькой выборке показали, что SQLAlchemy потребляет много (десятки процентов) CPU.

При тестировании Psycopg2 клиента потребление процессора было в районе 15%, что вполне приемлемо для тестирования, так как узким местом в большинстве случаев была дисковая подсистема. Все дальнейшие тесты были произведены с использованием Python клиента c Psycopg2. На каждое подключение к БД создавался отдельный Python процесс.

Схема тестовой таблицы:

CREATE TABLE numbers
(
"number" bigserial NOT NULL,
operator smallint,
region smallint,
CONSTRAINT numbers_pkey PRIMARY KEY (number)
)

Для тестирования чтения использовалась команда:

'SELECT * FROM numbers WHERE number=%d'

Номер выбирался случайный.

Для тестирования записи использовалась команда:

'UPDATE numbers set region=%d, operator=%d WHERE number=%d'

Все параметры случайные из допустимых диапазонов. UPDATE читает и пишет данные на диск при этом не изменяя размера БД, поэтому было решено использовать его для комплексной нагрузки на запись. INSERT и DELETE при тестировании не использовались. Каждый отдельный тест выполнялся несколько минут. Отдельные тесты запускались по несколько раз, и полученная производительность совпадала с точностью около 1%.

Для создания RAID-0 массива использовался mdadm. RAID создавался с использованием всего диска, а не поверх разделов.

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

Тестирование производилось на одном SSD диске сразу после заполнения БД. Размер таблицы – 1 миллиард записей. На диске 42Гб было занято под таблицу и 21Гб на индекс. Узким местом является дисковая подсистема. Рассмотрим, как меняется производительность БД в зависимости от количества активных подключений.

Производительность SELECT

Сначала производительность растет равномерно в зависимости от количества подключений. Начиная примерно с 16 подключений общая производительность стабилизируется, упираясь в диск.

Производительность UPDATE

При обновлении записей картина аналогичная. С 16 пользователей производительность стабилизируется. Узкое место – диск.

PostgreSQL использует MVCC для обеспечения ACID. Этим в частности объясняется, что при изменении значения одного столбца во всей таблице размер этой таблицы изменяется примерно в 2 раза.

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



Как видим производительность чтения упала на 15-20%. Также база незначительно увеличилась в размерах. Для увеличения производительности и освобождения занятого места требуется выполнение команды VACUUM. Данный вопрос выходит за рамки статьи, более подробно о нем можно почитать в документации.

После проведения всех тестов и остановки PostgreSQL мы решили повторить тест на скорость чтения с диска.



Как видим, производительность записи на диск упала. Данный график стабильно воспроизводился при различных размерах считываемых данных. Объяснений этому у нас нет. Будем рады, если кто-то объяснит причины падения скорости.

Резюме

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

В следующей статье будет тестирование производительности базы данных на SSD RAID-0 массиве и размер таблицы будет увеличен до 10-ти миллиардов записей.

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

Другие статьи о возможностях Dr. Tariff и аналитике сотовых услуг из нашего блога

Dr. Tariff посчитал у какого сотового оператора больше 4G интернета (часть 2)
Dr. Tariff посчитал у какого сотового оператора больше 4G интернета (часть 1)
Осторожно! Скрытые доходы операторов — следите за опциями «Вам звонили!», «Кто звонил+», «Будь в курсе+» (теперь платные)
История о том, как мобильный оператор списал деньги с разработчика Dr. Tariff (захватите попкорн)
Dr. Tariff 2.0: новые возможности для абонентов Билайн, МегаФон и МТС
Решили сменить оператора? Не забудьте подобрать выгодный тариф с помощью Dr. Tariff
Dr. Tariff (3 месяца спустя) — подобрать тариф можно в 80 регионах России на Android и iOS
Dr. Tariff (тарифы и баланс): Как я стал помогать людям экономить на мобильных затратах

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