Назад | Перейти на главную страницу

Postgresql 9.6 поверх BTRFS. Хорошая или плохая идея?

Я просто готовлю виртуальную машину (работающую на Proxmox) для запуска postgresql 9.6 поверх Ubuntu 16.04 LTS. Этот postgres будет использоваться для обработки баз данных Jira / FisheEye / Confluence для небольшой компании. Обычно мы работаем несколькими пользователями одновременно, поэтому нам не нужно настраивать его для экстремальной производительности / масштабируемости.

Дело в том, что мы используем BTRFS на серверах, чтобы помочь нам решить проблему добавления дополнительного места на виртуальную машину, когда это необходимо, плюс мы включаем сжатие lzo. Кроме того, мы используем btrok для обработки резервных копий подтомов BTRFS на другой компьютер.

Я сомневаюсь, что использование BTRFS для обработки файлов базы данных postgresql было бы хорошей идеей, поскольку мы были бы очень полезны в случае, если нам нужно расширить пространство виртуального жесткого диска, но я читал о плохой производительности postgresql по сравнению с BTRFS (особенно если поток данных не отключен.

У кого-нибудь есть опыт в этой ситуации?

Общий ответ: плохая идея. Вы можете прочитать об этом немного подробнее Вот. Короче говоря, механизм COW в BTRFS приведет к несогласованности производительности для нормальной рабочей нагрузки OLTP.

Лучший ответ: в некоторых случаях я бы его использовал. Почему и как:

  • Вы можете заметить реальную разницу в производительности только в том случае, если действительно нагружаете файловую систему и выполняете действительно тяжелую работу для FS в этой БД. Маловероятно для JIRA и Confluence при обычных рабочих нагрузках (при условии, что вы не работаете в компании с тысячами разработчиков и т. Д.), Особенно если вы правильно настроите и настроите их кеширование. Кроме того, учитывая, что вы хотите включить сжатие, не похоже, что производительность ввода-вывода является вашей главной заботой :).
  • Принимая во внимание предыдущий пункт, управляемость, хорошая интеграция с вашими текущими инструментами и средой и существующие знания об используемых вами технологиях определенно должны превзойти тот факт, что при гораздо более высоких рабочих нагрузках другие файловые системы обеспечивают лучшую производительность.
  • Я бы также подумал о том, чтобы правильно настроить все, чтобы компенсировать: запускать во флэш-памяти, выполнять правильное выравнивание данных (физические <-> контроллеры <-> разбиение <-> FS <-> DB), выполнять правильную FS (BTRFS требует большего обслуживания, чем ваш бросок -in-and-Forgot-about-it ext4), а также обслуживание и настройка БД.

Я надеюсь, что это помогает.

Заметка: Пользователь предположил, что COW можно отключить для BTRFS для определенных томов / папок, и я игнорирую этот факт. В самом деле, его можно отключить, но если вы это сделаете, зачем вам все еще использовать BTRFS? - Потому что вы все еще можете использовать COW для остальной файловой системы и всех других интересных функций (например, снимков и прочего) без снижения производительности для виртуального бокса и postgres? Конечно, для чистого сервера БД нет смысла использовать BTRFS и отключать COW. Но для машины / сервера общего назначения? Он позволяет использовать все классные функции (RAID1, ...) без снижения производительности. Так беспроигрышный вариант в моих глазах.

Пользователь предположил, что COW можно отключить для BTRFS для определенных томов / папок, и я игнорирую этот факт. В самом деле, его можно отключить, но если вы это сделаете, зачем вам все еще использовать BTRFS?

Даже когда COW отключен для определенных файлов / папок, у них все еще есть возможности создания снимков. После создания снимка следующей записью будет COW, а затем возврат к записи на месте. Довольно простое решение для резервного копирования работающих баз данных, если вы делаете это, когда ФС не занята. Конечно, вы по-прежнему теряете контрольную сумму для всех операций записи на месте.