Pentaho BI


Своевременные и качественные управленческие решения


Прогнозная аналитика и моделирование поведения пользователей

Pentaho BI

Главная / PostgreSQL: Linux VS Windows – часть 2


25.06.2018 г., перевод статьи JMG


PostgreSQL: Linux VS Windows! 

После проведения моего первого теста я получил интересный отзыв под постом на reddit, который подтолкнул меня сделать еще один эксперимент.

И я подчеркну это еще раз – это не тест для сравнения Linux и Windows!

Меня не волнует, какая операционная система лучше!

У меня есть клиент с большой инфраструктурой, построенной с использованием Windows (но не Linux) и большим опытом работы с Windows (но не Linux), и я хочу знать, должен ли я посоветовать ему использовать PostgreSQL для Linux.

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


Последовав совету, я не стал использовать свой прежний инструмент тестирования. Для второго теста «Windows vs Linux для хостинга PostgreSQL» я использовал PgBench.

Следуя этому совету, я проводил тест с данными, превышающими размер памяти и с большой продолжительностью. М4.xlarge на Amazon имеют 16 Гб данных, а при масштабе 2000, PgBench генерирует БД ±30 Гб.

PgBench, для тех, кто не в курсе (как я), делает тоже самое, что и написанное мной приложение для тестирования, но лучше! 

Он имеет большое количество опций и тщательно тестируется, в отличие от моего приложения, которое только было протестировано... только мной.

PGBench – это не совсем то, что я хотел, потому что я хотел провести тест с помощью .NET-приложения, которое использует npgsql (PgBench использует libpq), но, как говорится, «в Риме поступайте, как римляне».


Архитектура для тестов совпадает с предыдущей:

«Клиент»

Сервер Windows 2012 R2 на amazon, тип m4.xlarge, со всеми настройками по умолчанию. 

Клиентским «приложением» выступает PgBench.

«Сервер Windows Postgresql» (далее – WS)

Сервер Windows 2012 R2 на Amazon, тип m4.xlarge, со всеми настройками по умолчанию и 100 GB SSD. 

PostgreSQL 9.4.5 установлен с помощью мастера.

Я изменил listen_addresses на * и внес необходимые изменения в pg_hba.conf для подключения к работе.

«Сервер PostgreSQL для Linux» (далее – LS) 

Amazon Linux AMI, тип m4.xlarge, со всеми настройками по умолчанию и 100 GB SSD.

PostgreSQL 9.4.5 установлен с yum.

Я внес те же самые изменения в postgresql.conf и pg_hba.conf, которые я делал для Windows.


Сценарий

Масштаб 500
a.1 – init PgBench.
a.2 – запустить локально PgBench на 240 секунд.
a.3 – запустить локально PgBench на 240 секунд для 42 клиентов.
a.4 – запустить локально PgBench на 240 секунд для 42 клиентов с 21 потоком.
a.5 – установить max_connections на 300 и перезапустить PostgreSQL.
a.6 – запустить локально PgBench на 240 секунд для 42 клиентов с 21 потоком.
a.7 – запустить от «Клиента» на 240 секунд для 42 клиентов с 21 потоком.

Масштаб 1000
b.1 – init PgBench.
b.2 – перезапуск PostgreSQL.
b.3 – запустить от «Клиента» на 240 секунд для 42 клиентов с 21 потоком.
b.4 – запустить от «Клиента» на 1200 секунд для 42 клиентов с 21 потоком.

Масштаб 2000
c.1 – init PgBench.
c.2 – перезапустить PostgreSQL.
c.3 – запустить от «Клиента» на 2400 секунд для 250 клиентов с 125 потоками.

Результат

PgBench 500

Мой компьютер
50000000 из 50000000 записей (100%) успешно (прошло 118,58 с, осталось 0,00 с).

WS
50000000 из 50000000 записей (100%) успешно (прошло 59,88 с, осталось 0,00 с).

LS
50000000 из 50000000 записей (100%) успешно (прошло 48,87 с, осталось 0,00 с).

Ради развлечения я попробовал запустить PgBench на моем компьютере, чтобы сравнить его с машиной, за которую просят 0.5$ в час на Amazon, но я быстро бросил эту затею… 

Как и в тестах с моим приложением, создание на Linux происходит быстрее.

Действительно ли это так?

PgBench 1000

WS
100000000 из 100000000 записей (100%) успешно (прошло 115,18 с, осталось 0,00 с).

LS
100000000 из 100000000 записей (100%) успешно (прошло 120,97 с, осталось 0,00 с).


PgBench 2000

WS
200000000 из 200000000 записей (100%) успешно (прошло 261.00 с, осталось 0.00 с).

LS
200000000 из 200000000 записей (100%) успешно (прошло 264,69 с, осталось 0,00 с).

Обобщенные данные

Server 500 1000 2000
WS 59.88 сек. 115.18 сек. 261.00 сек.
LS 48.87 сек. 120.97 сек. 264.96 сек.


Linux немного (менее чем на 5%) медленнее Windows, при обработке больших данных!

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

Так что, может быть сработал autovacuum, может пул Linux VM Amazon используется больше, чем Windows, или какие-то другие причины.

Давайте посмотрим, получим ли мы тот же результат, если запустить PgBench вместо просто инициализации.

Для лучшей читабельности, я округлил некоторые результаты PgBench, в любом случае – все они доступны на моем github.


Duration (сек) TRANS WS TRANS LS TPS WS TPS LS diff tps
a.2 240 128472 109535 535 456 17,32
a.3 240 328471 320108 1301 1333 -2,40
a.4 240 382147 365494 1592 1522 4,60
a.6 240 421287 399478 1714 1663 3,07
a.7 240 468761 425839 1952 1774 10,03
b.3 240 291803 294441 1204 1226 -1,79
b.4 1200 751647 1077216 626 896 -30,13
c.3 2400 1296582 773482 540 321 68,22

a.6

a.6 – это a.5 после перезапуска и выставления max_connections на 300.

Теперь я совсем запутался, я как будто в тумане

Каким образом установка max_connections на 300 позволило повысить tps? 

Я думаю, это произошло потому, что я перезапустил процесс PostgreSQL. 

Обратите внимание, что я не использовал параметр -C, поэтому на одного клиента должно быть только одно соединение (т.е. максимум 42). 

Документ PgBench:
- С
Установить новое соединение для каждой операции, а не только один раз за сеанс.

b.4

Масштаб 1000 создаёт БД ±16gb, отчего я готов предположить, что большая ее часть может находиться в оперативной памяти во время всего процесса, и что управление памятью Linux осуществляет намного лучше, чем думают некоторые.

c.3

Вот тут моя челюсть просто отвалилась!

При высокой и длительной нагрузке Windows выдает на 68% больше TPS, чем Linux!

Это было так неожиданно, что я выждал целую неделю, прежде чем повторить тест.


Duration (сек TRANS WS TRANS LS TPS WS TPS LS diff tps
c.3.2 2400 1303677 844387 542 351 54,42

Linux прибавил около 10%, а результаты для Windows практически не изменились, составив 54%. Итак, суммарно в 2 тестах c.3 – почти 61% разницы в пользу Windows.

Заключение

В основном, Windows на 5% быстрее с масштабом 500, на 30% медленнее с масштабом 1000 и на 61% быстрее с масштабом 2000.

Я обсудил это со своими коллегами, и один из них сказал:
«Ну конечно! Вы же не разбираетесь в Linux, а так бы вы знали, что для получения лучшей производительности он требует хотя бы минимальной настройки».

На что я ответил:
«Нет. Это и была цель моих экспериментов.
Я не хочу, чтобы какой-то специалист по Linux возился в течение 6 недель, чтобы настроить сервер максимально производительно, и я не хочу, чтобы специалист по Windows возился в течение 6 недель по той же причине. Это не соревнования специалистов.
Кроме того, при использования облачных сервисов возникает много нюансов, которые не позволят произвести точные настройки».

В моем предыдущем посте я говорил, что Linux и Windows находятся примерно на одном уровне, если сравнивать их производительность работы с PostgreSQL. После этого второго теста я вынужден сказать:

Для меня это равноценные решения.

В продолжение шутки из моего первого поста, про PostgreSQL, быстрее работающем на ОС Linux, запущенной в виртуальной машине на Windows, чем просто на ОС Windows. Выходит, что сотрудник Dalibo все-таки ошибся.

PostgreSQL на Linux совсем не быстрее, чем PostgreSQL на Windows, вот такие пироги с котятами!

А вы как думаете?