29.06.2019 11:16
puyol_dev2 34 13000 Источник
image Привет, Хабр! Представляю вашему вниманию перевод оригинальной статьи «PostgreSQL benchmark on FreeBSD, CentOS, Ubuntu Debian and openSUSE» автора Martin Kovacik. В ней рассматриваются тесты СУБД PostgreSQL 10.1 в приближенных к реальным условиям средах на различных unix-системах

Перевод


В этом посте я собираюсь показать результаты тестов недавно выпущенного PostgreSQL 10.1. Я проверил БД на этих ОС (все 64-битные):

  • Ubuntu 16.04, ядро 4.10.0-38-generic
  • openSUSE 42.3, ядро 4.4.87-25-default
  • CentOS 7.4, ядро 3.10.0-693.2.2.el7.x86_64
  • Debian 9.2, ядро 4.9.0-4-amd64
  • FreeBSD 11.1

Методология тестирования


Целью теста было измерение производительности PostgreSQL в условиях, аналогичных(типичных) производственному развертыванию:

  • клиенты подключаются через пул соединений, чтобы гарантировать, что нет постоянного переподключения к БД (я не использовал пул соединений, вместо этого я не использовал флаг -C pgbench)
  • клиенты подключаются по сети, не через сокет unix
  • директория с данными PostgreSQL находится на зеркале RAID 1

Для каждой из протестированных ОС была создана контрольная база данных ~74 ГБ:

pgbench -i -s 5000 pgbench

Тестовая инфраструктура состояла из двух выделенных серверов, соединенных с сетью 1 Гбит/с:

  • EX41-SSD: Intel i7-6700, 4 ядра, 8 потоков, 32 ГБ оперативной памяти DDR4, использовался для генерации SQL-запросов с использованием pgbench
  • PX121-SSD: Intel Xeon E5-1650 v3, 6 ядер, 12 потоков, 256 ГБ ОЗУ DDR4 ECC, 2 x 480 ГБ SATA 6 Гбит/с, дата-центр серии SSD, использовался в качестве сервера PostgreSQL

Меня интересовали эти тестовые комбинации:

  • 32 ГБ только чтение: тест только чтения (только выборки без изменений данных), набор данных не помещается в кэш PostgreSQL
  • 200 ГБ только чтение: тест только чтения, набор данных помещается в кэш PostgreSQL
  • 32 ГБ TCP-B: чтение-запись, набор данных не помещается в кэш PostgreSQL
  • TCP-B 200 ГБ: чтение, запись, набор данных помещается в кэш PostgreSQL

настройка pgbench


Программа pgbench версии 10.1, запущенная на отдельном компьютере FreeBSD 11.1, использовалась для генерации нагрузки. Тестовый скрипт состоял из трех частей: vacuum + прогрев, тест только чтение и тест чтения и записи. Перед каждым тестом чтения-записи таблицы pgbench очищались (использовался флаг -v). Во время теста я постепенно увеличивал количество клиентов, обращающихся к базе данных.

#!/bin/sh

THREADS=8
DURATION=1800
PGIP=192.168.1.120

# warmup
pgbench -h ${PGIP} -U pgbench -j ${THREADS} -c 10 -T ${DURATION} -S -v pgbench

for clients in 1 10 20 30 40 50 60 70 80 90 100 110 120
do
  echo "RO ${clients}"
  pgbench -h ${PGIP} -U pgbench -j ${THREADS} -c ${clients} -T ${DURATION} -S pgbench > pgbench_ro_${clients}.log
done

for clients in 1 10 20 30 40 50 60 70 80 90 100 110 120
do
  echo "RW ${clients}"
  pgbench -h ${PGIP} -U pgbench -j ${THREADS} -c ${clients} -T ${DURATION} -v pgbench > pgbench_rw_${clients}.log
done

Настройки сервера PostgreSQL


Для дистрибутивов Linux PostgreSQL был установлен в файловой системе ext4 в настройке RAID1 (программный RAID с использованием mdraid) на двух SSD с отключенным atime. В случае FreeBSD файловая система OpenZFS использовалась на двух SSD при настройке RAID1. Набор данных ZFS с данными PostgreSQL был создан со следующими параметрами:

zfs get recordsize,logbias,primarycache,atime,compression zroot/var/db/postgres
NAME                   PROPERTY      VALUE         SOURCE
zroot/var/db/postgres  recordsize    8K            local
zroot/var/db/postgres  logbias       throughput    local
zroot/var/db/postgres  primarycache  all           default
zroot/var/db/postgres  atime         off           inherited from zroot
zroot/var/db/postgres  compression   lz4           local

Конфигурация сервера PostgreSQL была одинаковой на всех ОС, кроме путей к файлам (каждая ОС использует свою структуру каталогов). Содержимое файла postgresql.conf (основные настройки) для экземпляра 32 Гб:

autovacuum = off
default_statistics_target = 100
maintenance_work_mem = 1GB
checkpoint_completion_target = 0.9
effective_cache_size = 24GB
work_mem = 104MB
wal_buffers = 16MB
shared_buffers = 8GB
max_connections = 300

Содержимое файла postgresql.conf для экземпляра 200 ГБ:

autovacuum = off
default_statistics_target = 100
maintenance_work_mem = 2GB
checkpoint_completion_target = 0.9
effective_cache_size = 144GB
work_mem = 640MB
wal_buffers = 16MB
shared_buffers = 48GB
max_connections = 300

Сравнительное тестирование


Я тестировал PostgreSQL на пяти разных операционных системах в двух режимах — только чтение и TCP-B (чтение-запись) с двумя различными профилями памяти. Тест каждой ОС занял около 30 часов (не считая времени, необходимого для настройки ОС). Результаты каждого запуска pgbench были сохранены для последующей оценки.

Результаты — Только чтение










Результаты — TCP-B










Итоги


Тест показал, что разница между различными дистрибутивами GNU/Linux не очень значительна. Лучшей операционной системой в тесте только для чтения была openSUSE 42.3, в то время как FreeBSD работала примерно на 40% медленнее. К сожалению, я не выяснил, что вызвало такую посредственную производительность FreeBSD.

Более реалистичная картина производительности PostgreSQL была получена в тесте чтения-записи (TCP-B). Среди дистрибутивов GNU/Linux Centos 7.4 был самым быстрым, а Debian 9.2 — самым медленным. Я был приятно удивлен FreeBSD 11.1, которая работала более чем в два раза быстрее, чем лучший Linux, несмотря на то, что FreeBSD использовала ZFS, которая является файловой системой copy-on-write. Я предположил, что такая разница была вызвана издержками на программный RAID в Linux, поэтому я сделал еще три теста TCP-B для 100 одновременно работающих клиентов, на этот раз без программного RAID:

  • FreeBSD 11.1 + UFS: 5623,86 TPS
  • FreeBSD 11.1 + ZFS: 8331,85 TPS
  • CentOS 7.4 + ext4: 8987.65 TPS

Результаты показывают неэффективность Linux SW RAID (или эффективность ZFS RAID). Производительность CentOS 7.4 без SW RAID лишь немного выше, чем у FreeBSD 11.1 с ZFS RAID (для TCP-B и 100 одновременных клиентов).

Комментарии (34)


  1. RNZ
    29.06.2019 16:32
    #20339982

    Сферическое сравнение. На ZFS в FreeBSD fsync при записи вернёт факт записи из ARC. В linux на ext4 fsync будет дожидаться сброса на накопитель.


    1. gluko
      02.07.2019 10:11
      #20347818

      Не верное. ARC — это вид кэша, к записи он отношение не имеет. Sync в ZFS вернет факт записи в ZIL, то есть на диск. Где вас таких делают?


      1. RNZ
        02.07.2019 13:27
        #20348872
        +1

        ARC имеет прямое отношение к записи, вся запись через него идёт. ZIL, собирает в лог все записи и досылает их на диск, прилетит fsync, он выставит для набора записей метку подтвердив транзакцию, вернув ответ в ARC, а уже ARC вернёт ответ fsync. И ZIL может вообще не использоваться для записи, асинхронно всё может лететь на накопитель сразу из ARC, ZIL же только метаданные фиксирует по умолчанию. А вообще надо у ТС спросить, что у него там в zfs get sync.


        Не там где вас, очевидно же.


        1. gluko
          02.07.2019 13:56
          #20348990

          ZIL не может не использоваться — это базовая часть ZFS.
          В случае sync — операция будет зафиксирована на диске, а уже потом вернется ответ (поведение по умолчанию sync=on). Так же доступны опции sync=off — когда sync фактически игнорируется и записи кладутся на диск группами транзакций и sync=always — когда каждая транзакция кладется на диск, без всяких sync.
          ZIL со включенным sync дает преимущества асинхронной записи.
          ZIL не фиксирует только метаданные
          ZIL не служит для ускорения, наоборот он замедляет работу системы, он служит для надежности.
          Ознакомьтесь для начала с этим: www.ixsystems.com/blog/o-slog-not-slog-best-configure-zfs-intent-log
          И перестаньте читать рунет — он заполонен бредом относительно ZIL и sync в ZFS. Не верным переводом.


          1. RNZ
            02.07.2019 17:47
            #20350316
            +1

            Зачем репостить, то что и так есть в документации?
            И ZIL (по умолчанию, при sync=on) всегда синхронизирует только операции с метаданными, остальное по мере того, как ОС или ПО подёргает fsync и/или на основании настроек своего драйвера. И даже без ZIL ZFS поддерживает согласованное состояние данных -https://blogs.oracle.com/roch/nfs-and-zfs,-a-fine-combination:


            "We note that, even without a ZIL, ZFS will always maintain a coherent local view of the on-disk state"

            И ZIL не базовая часть ZFS, а вспомогательная для обеспечения надёжности записи и восстановления после сбоев, без ZIL ZFS может использоваться.
            Перестаньте поучать.


            1. gluko
              02.07.2019 20:03
              #20350796

              Вы правы, я ошибся. Нашел хороший материал, который это подтвердил 1
              Хороший материал 2

              Однако возможно в вашем описании так же имеются не точности. Например, довольно важный факт, вынесенный из статьи: данные из ZIL никогда не читаются. (не перемещаются из ZIL в пул)
              При штатной работе сервера (без аварий) записи попадают в пул из ОЗУ группами транзакций, независимо от того были ли они синхронными или асинхронными.
              Т.е ZIL не собирает транзакции, не кэширует, и читается только во время аварии. В ZIL дублируются синхронные операции, и там остаются на случай аварии.

              Меня сбили с толку (а вдруг не сбили, вдруг так и есть?) статьи в которых говорится, что в ZIL пишется ALL DATA:
              (Пример 1)
              By default, the short-term ZIL storage exists on the same hard disks as the long-term pool storage at the expense of all data being written to disk twice: once to the short-term ZIL and again across the long-term pool Источник
              (Пример 2)
              The ZFS Intent Log is a logging mechanism where all the of data to be written is stored, then later flushed as a transactional write. Источник
              (Пример 3)
              Иллюстрирует что при выключенном SYNC — ZIL просто переходит в RAM область.
              «So, if that's the case, then what exactly is going on? Well, there actually resides a ZIL in RAM when you enable „sync=disabled“ on your dataset» Источник

              Спасибо за терпение, и обсуждение, я проголосую за ваши комментарии!


        1. gluko
          02.07.2019 14:05
          #20349044

          docs.oracle.com/cd/E19253-01/819-5461/gfgaa/index.html


        1. gluko
          02.07.2019 14:05
          #20349050

          www.oug.org/files/presentations/zfszilsynchronicity.pdf


  1. DSolodukhin
    29.06.2019 17:04
    #20340090

    Для полноты картины надо было и linux на zfs ставить.


  1. Zoomerman
    29.06.2019 17:30
    #20340188

    Хорошее сравнение. Не руководство к действию, но для разнообразия пойдет.
    На дефолтных настройках действительно дебиан будет самым медленным, центос середнячком, а фрибсда самой быстрой.
    Если известны все нужные пакеты, их версии и есть аналоги в портах фрибсды — лучше брать её. Если нет в портах, но есть в центосе — тогда его. А если неизвестно что в итоге нужно получить и нет уверенности в версиях — тогда дебиан. Разогнать его под определенную задачу легче, чем центос и фрибсду.
    Мне редко встречаются проекты с утвержденным набором ПО и версий. Обычно задача стоит найти оптимальную комбинацию по отношению цена/качество. Поэтому стандартно ставим дебиан, а затем докручиваем настройки до предела.


  1. tankistua
    29.06.2019 19:27
    #20340472

    Какой вывод из статьи — зфс лучше чем mdadm :)


    Надо было тестировать фрю на ufs и линукс на ext4 или xfs


    1. FSA
      29.06.2019 21:43
      #20340778
      +1

      Да. Довольно странное решение ставить Linux на родную систему, а FreeBSD на ZFS для сравнения.


      1. AdVv
        30.06.2019 10:55
        #20341460

        zfs на FreeBSD вполне себе родная, инсталлятор позволяет сразу на нее систему ставить.


  1. AntonSazonov
    29.06.2019 20:16
    #20340568
    +1

    Какое-то странноватое тестирование…
    Почему 4 из 5 ОС — Linux дистрибутивы? Почему нет Windows и Solaris, к примеру?
    Почему не указаны архитектуры openSUSE и Ubuntu?
    Предположу, что большое влияние на быстродействие может оказывать glibc. По сути — это сравнение именно её производительности. Ну и версии ядер конечно же тоже могут играть роль.


    1. puyol_dev2 Автор
      29.06.2019 20:38
      #20340630

      Почему не указаны архитектуры openSUSE и Ubuntu?


      Написано, что все ОС 64-битные

      По поводу производительности — скорее всего здесь ключевая роль у файловых систем и работа ядра ОС с этими фс


      1. AntonSazonov
        29.06.2019 21:05
        #20340694

        Ещё два раза прочёл статью наискосок. Не заметил что где-то написано что все ОС 64-битные. Можете процитировать?
        Кстати, позвольте придраться, я спрашивал про архитектуру, а не про разрядность процессора.


        1. Rim13
          29.06.2019 21:17
          #20340722
          +1

          «В этом посте я собираюсь показать результаты тестов недавно выпущенного PostgreSQL 10.1. Я проверил БД на этих ОС (все 64-битные)»


          1. AntonSazonov
            29.06.2019 21:27
            #20340750

            Извините. Почему-то не заметил.
            Но тестирование всё-равно считаю странным. Остальные претензии в том сообщении на которое вы ответили.


            1. puyol_dev2 Автор
              29.06.2019 21:50
              #20340798
              -1

              Windows стоит денег и Postgres хуже работает с ней, чем с unix системами из-за архитектурных особенностей

              По поводу  Solaris тут вообще все очень просто

              www.postgresql.org/download/solaris

              Packages for Solaris 10 and 11 are available for Sparc and i386 platforms.

              Although produced by Oracle (previously Sun), these packages are not officially supported by them.

              То есть поддерживаются только спарки или устаревшая 386 платформа, и то у них нет официальной поддержки Oracle


              1. AntonSazonov
                29.06.2019 22:29
                #20340878

                Взгляните на эти две ссылки:
                www.postgresql.org/ftp/binary/v12beta2/solaris/solaris11/i386
                www.postgresql.org/ftp/source/v12beta2
                i386 — это базовая архитектура.
                Так же посмотрите в исходники, а именно в файл INSTALL. Вы найдёте там ни одно упоминание о ОС Solaris, последняя версия которой датирована 2018-м годом. Версия PostgreSQL датирована 2019-м.
                Ваша же цитата относится к «бинарникам». Т.е. к brebuild binaries.


                1. puyol_dev2 Автор
                  30.06.2019 10:16
                  #20341396
                  -2

                  Ну собственно сами и ответили на свой вопрос почему в обзоре нет Solaris. i368 — это устаревшая 32 битная архитектура


  1. kolu4iy
    29.06.2019 20:29
    #20340592
    +2

    С дефолтными настройками ОС вообще это сравнение лишено смысла. Допустим, мы внутри периметра корпоративной сети, доступ к серверу ограничен. Нужен нам selinux? Нужны нам патчи от spectre и прочие pti? Как настроена файловая система — например, отношение размера блока к размеру аппаратного блока? Короче это тест дефолтных настроек дистрибутивов, не более.


    1. kolu4iy
      29.06.2019 20:32
      #20340608
      +1

      … а еще в центос 7 есть профили производительности. По-умолчанию — balanced, который реально никто использовать не будет. Ну, этот как пример… А ещё все вообще СУБД не любят гипертридинга и турбобуста, особенно на больших выборках, которые хорошо распараллеливаются. С этими настройками — одинаково всё? Если нет, то многое зависит от планировщика, который тоже можно переключить. Как и io scheduler...


      1. kalininmr
        30.06.2019 17:33
        #20342176
        +1

        с турбобустом как-то странно везде.
        даже при компиляции после нескольких секунд частота проседает ниже штатной.
        а если отрубить турбобуст — суммарно получается быстрее.


    1. puyol_dev2 Автор
      30.06.2019 12:49
      #20341684

      Это не лишено смысла вот почему. Довольно много компаний занимаются внедрением продуктов и их доработкой под требования заказчика. Как правило они хорошо знакомы с продуктом, но могут быть незнакомыми с поддерживаемыми этим продуктом системами. Например заказчик поставил задачу внедрить продукт на свободном ПО. У компании есть опыт работы на связке Windows+MSSQL. Нужно установить на связке Unix+Postgre. И стоит выбор на какой же ОС ставить. Вот тут приходят на помощь такие тесты, которые могут подсказать какая ОС по умолчанию на какой ФС будет работать максимально быстро, чтобы потом уже дальше по возможности настраивать


  1. BasilioCat
    30.06.2019 12:45
    #20341680

    Отдельно хочется отметить включенную компрессию ZFS. lz4 конечно быстр, но зачем его использовать для БД? Для больших текстовых полей у самого PostgreSQL есть TOAST с нормальным сжатием.
    Насколько я помню старые бенчмарки PostgreSQL, FreeBSD c UFS показывают примерно равные результаты с Linux c EXT3, от которых чуть отстает Linux c XFS. LVM дает просадку по производительности примерно равную ZFS. За приятные фичи приходится платить.


    1. gluko
      02.07.2019 10:55
      #20348028

      1) lz4 «бесплатный», более того по многочисленным тестам lz4 ускоряет чтение\запись за счет того, что в тот же raw объем помещается больше «логического объема» данных.
      2) сжатие внутри бд и внутри файловой системы — это разные вещи разные уровни. Чтобы это понять, нужно представлять как работает любая COW файловая система. Файлы в ней не представляют собой «кусок диска» который был изначально захвачен базой (при последовательном доступе к диску). Copy-on-Write пишет в свободные блоки (в другое место на диске) при ЛЮБОМ изменении части исходных файлов (блоков).


      1. BasilioCat
        02.07.2019 12:21
        #20348462

        1 lz4 бесплатный и ускоряет в некотором усреднённо-офисном случае, как правило тестируют файловый сервер с несжатыми данными. Явно на h264 он не даст никакого прироста. А тут БД, оптимизирующая последовательную запись и размер блока к давно неактуальным вращающимся дискам. И recordsize=8k там ровно для этого. Сжатие данных будет порождать блоки меньшего размера, чего БД никак не ожидает. И как она ведет себя с lz4 и без lz4 — тема для отдельного бенчмарка, который покажет, что да, таки с lz4 быстрее. Или медленнее.
        2) cow и внутриблочное сжатие не имеют ничего общего. COW прекрасная вещь для снапшотов и клонов (что очень удобно для организации нескольких записываемых(!) дев-копий продакшен базы). Но если у вас нет снапшотов, то и COW нет. Вернее, исходный блок будет помечен в метаданных свободным сразу после записи нового, если счетчик его использования в снапшотах = 0. И таки да, эта особенность записи скорее всего и дает падение производительности баз данных на ZFS

        TOAST работает только на колонках c storage EXTENDED, используется когда вы знаете, что там будут лежать сжимаемые данные. Например текстовые документы размером больше 2кб. Это куда более предсказуемая и управляемая конструкция, чем дедупликация и сжатие на уровне хранилища.


  1. capitannemo
    30.06.2019 13:06
    #20341704

    Не очень понятно, что автор хотел добиться таким сравнением.
    Он надеялся что постгри не живет с каким то конкретно дистрибутивом в ладах?
    По сути он оттестировал быстродействие обмена с дисками в разных дистрибутивах Linux, еще и с дефолтными установками.
    Времени судя по описанию у него было немало свободного.
    В идеале нужно приложить график fio который будет аналогичным, его можно минут за 15 получить не заморачиваясь особо.


    1. BasilioCat
      30.06.2019 13:20
      #20341718

      Профиль нагрузки fio на дисковую подсистему не совсем такой, как у базы данных. Да и шедуллер проца и кэши фс тоже играют роль в TPSах. Но в целом тут все уперлось в файловые системы. Предполагаю, что оригинальная статья задумывалось как быстрый ответ на вопрос «Какую ОС поставить на сервер в Хетцнере».


      1. sigo73
        02.07.2019 14:11
        #20349078

        Proxmox и использовать ZFS RAID1 для SSD (как у автора). Ибо автор почему-то не пошёл дальше и не стал проверять производительность своих тестов под ZoL. Увидел бы я эту статью раньше — не стал бы городить свои, а так выжал на практически сравнимом железе (памяти только 64Гб) у этого же Хетцнера около 300 тыс. на операциях чтения pg_bench и около 40тыс. на TPC-B.


  1. lexore
    30.06.2019 14:39
    #20341848

    Последний раз я такие тесты видел (и сам делал) в конце нулевых. Ностальгии пост :)
    А теперь по делу.


    Интересно, дождался ли автор, пока linux soft raid проинициализирует весь рейд?
    Минус soft raid в linux — он его инициализирует после создания, т.е. проходится по всем дискам. Естественно, это занимает быстродействие диска. В sysctl есть ручки для управления максимальной скоростью проверки. По умолчанию это 200 МБ/с, т.е. на старте диски несколько нагружены. И лучше дождаться окончания. Если что, это можно проверить в файле /proc/mdstat.


    ZFS — это система, которая очень агрессивно кеширует в память. Отсюда и хорошие показатели скорости записи. Фактически, автор писал в оперативку и такой "ой, как все летает" :) Сами создатели ZFS подтверждают, что запись кешируется и сразу говорят "если хотите ZFS, просто ставьте ИБП". Надеюсь, у автора стоит ИБП :)


    Ещё нужно признать, что у ZFS действительно шикарная система кеширования горячих данных. ARC и L2 ARC (adaptive read cache) — шикарные штуки. По хорошему, с ZFS нужно было сравнивать не просто linux, а linux с настроенной системой кеширования flashcache/bcache/dm-cache. А иначе это как сравнивать машины с N2O ускорением и без.


    И из не технического.
    Не думаю, что в 2019 кто-то будет менять ОС на FreeBSD ради таких показателей. Потому что, нужно посмотреть на ситуацию шире.


    Если у вас действительно такая нагрузка на сервере на запись (может 1С на крупном предприятии), то у вас хватит денег сделать кластер и масштабироваться горизонтально. И посадить спецов и консультантов закрутить настройки тюнинга.
    А если нагрузка есть, а денег нет (стартап, например), надо что-то менять в бекенде :) Ибо нагрузка может вырасти ещё, а железо уже не потянет. В 2-3 раза больше пользователей и все ляжет.


    Потом, другая ОС в инфраструктуре — это расходы на управление.
    Уже давно настала мода на автоматическое управление конфигурацией сервера силами ansible/salt/chef/puppet.
    И когда все написано под linux, впихнуть туда FreeBSD — тот ещё гемор.
    А если не впихивать — гемор ещё больший (ручками заводить юзеров, раскатывать пакеты, править конфиги, бекапить их).


    Потом, по хорошему, основная нагрузка на базу должна быть именно на чтение. А тут у Linux все хорошо :)


    1. BasilioCat
      30.06.2019 17:18
      #20342146
      +1

      ZFS пишет в ZIL (zfs intent log) и рапортует об успешной записи по факту физической записи в журнал. Потому авторы ZFS говорили ставить отдельный быстрый SSD для ZIL для производительной работы, и EСС память для предотвращения сбоев. А вот устойчивость к сбоям питания там не хуже, чем у других журналируемых файловых систем (подразумевается журналирование метаданных)
      Кстати говоря, double write buffer в InnoDB рекомендуют отключать как раз по причине того, что этот функционал дублируется в ZFS


  1. ALexhha
    01.07.2019 10:14
    #20343814

    Странное сравнение, использовать специфическую фс — ZFS, которая имеет 100500 параметров для тюнинга. Кстати, а почему не включали max_parallel_workers, которые являются фишкой 10й ветки и дают хороший прирост в производительности