На протяжении развития сервиса оптимизации затрат на сотовую сообщение Dr. Tariff (iOS, Android) для совместного пилота с одним из партнеров нам потребовалась громадная и производительная реляционная база данных.Производительности HDD диска было очевидно не хватает. Размер базы должен был составить пара сотен гигабайт, исходя из этого размещение ее в оперативной памяти было бы через чур дорого. SSD диск наилучшим образом подходит для данной задачи.

Но одного SSD диска имело возможность не хватить, исходя из этого было решено собрать RAID-0 массив из двух дисков. Пользуясь случаем мы решили совершить тестирование производительности PostgreSQL на одном и двух SSD дисках.
Смотрите кроме этого: Тестируем PostgreSQL на SSD RAID-0 массиве с таблицей в 10 миллиардов записей. (Часть 3, последняя)

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

Tariff (iOS, Android) для совместного пилота с одним из партнеров нам потребовалась громадная и производительная реляционная база данных.Зависимость производительности БД от параметра shared_buffersПараметр PostgreSQL shared_buffers задает большой количество оперативной памяти для кэширования на уровне базы данных.

Главные цели тестирования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 Mbport = 5400max_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.

Случайная статья:

• Сделано в китае #34: мнение китайцев об iphone 7, дроны-курьеры и многое другое
• Смогут ли серверы на arm заставить intel понервничать?

Людей на Земле не 7 миллиардов !? А китайцев не более 400 миллионов

Похожие статьи:

• Сравнение скоростных характеристик дисковых массивов фирм dothill и netapp

  В этом посте мы сравним дисковые массивы DotHill 3730 и NetApp 5412. тестирование и Сравнение проводилось с целью выяснить целесообразность смены…

• Fujitsu совершенствует защиту и управление качеством сервиса дисковых массивов

  В последних числах Июля компания Fujitsu представила новый функционал собственных дисковых массивов ETERNUS DX S3. Эти усовершенствования СХД реализуют…

• Тестируем bb-mobile techno w8.9 3g: стеклянный 4х-ядерный планшет на windows 8.1

  До недавнего времени планшетные компьютеры на Windows производили только пара больших компаний с мировым именем – HP, Acer, Toshiba, ASUS и без того…