Is PostgreSQL suited to one OS? Is it better on Linux than Windows?
I have been running PostgreSQL on Windows Server 2003 without a hitch and its fast, so to answer my own question it seems fine. However I am about to launch a new project and am considering using a Linux box instead as stability and performance are crucial. Since PostgreSQL seems to be developed on Linux distributions mostly, maybe it would be better to stick with Linux?
4 Answers 4
PostgreSQL will definitely run faster on Linux than on Windows (and I say this as one of the guys who wrote the windows port of it..) It is designed for a Unix style architecture, and implements this same architecture on Windows, which means it does a number of things that Windows isn’t designed to do well. It works fine, but it doesn’t perform as well.
For example, PostgreSQL uses a process-per-connection model, not threading. Windows is designed to do threading. If your application does lots of connect and disconnects, it will definitely run significantly slower on Windows, for example.
There is also some assumptions around the filesystem which don’t exactly favor NTFS.
The one thing you really need to think about — if you are on Windows, most antivirus products will bug out when used with PostgreSQL, because they are not used to this type of workload (such as 1000 different processes reading and writing to the same file through different handles). That means that the strong recommendation is to always uninstall any antivirus if possible (just disabling it or excluding the PostgreSQL processes/files is often not enough). And this is not just for performance reasons, but also stability under load.
Статьи / PostgreSQL: Linux VS Windows – часть 2!
После проведения моего первого теста я получил интересный отзыв под постом на 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 потоками.
Результат
Мой компьютер
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 происходит быстрее.
Действительно ли это так?
WS
100000000 из 100000000 записей (100%) успешно (прошло 115,18 с, осталось 0,00 с).
LS
100000000 из 100000000 записей (100%) успешно (прошло 120,97 с, осталось 0,00 с).
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.5 после перезапуска и выставления max_connections на 300.
Теперь я совсем запутался, я как будто в тумане.
Каким образом установка max_connections на 300 позволило повысить tps?
Я думаю, это произошло потому, что я перезапустил процесс PostgreSQL.
Обратите внимание, что я не использовал параметр -C, поэтому на одного клиента должно быть только одно соединение (т.е. максимум 42).
Документ PgBench:
— С
Установить новое соединение для каждой операции, а не только один раз за сеанс.
Масштаб 1000 создаёт БД ±16gb, отчего я готов предположить, что большая ее часть может находиться в оперативной памяти во время всего процесса, и что управление памятью Linux осуществляет намного лучше, чем думают некоторые.
Вот тут моя челюсть просто отвалилась!
При высокой и длительной нагрузке 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. После этого второго теста я вынужден сказать:
- Если у вас уже есть готовая инфраструктура основанная на Linux – используйте PostgreSQL на Linux!
- Если у вас есть инфраструктура на Windows – используйте PostgreSQL на Windows!
- Если вы используете и Windows и Linux… Тогда я не знаю… Думаю, вам стоит нанять специалиста, чтобы он помог определиться, что будет лучше лично в вашем случае.
В продолжение шутки из моего первого поста, про PostgreSQL, быстрее работающем на ОС Linux, запущенной в виртуальной машине на Windows, чем просто на ОС Windows. Выходит, что сотрудник Dalibo все-таки ошибся.
PostgreSQL на Linux совсем не быстрее, чем PostgreSQL на Windows, вот такие пироги с котятами!