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 требует большего обслуживания, чем ваш ext4 типа «вставил и забыл об этом»), а также обслуживание и настройка БД.
Надеюсь, это поможет.
Примечание : пользователь предложил отключить COW для BTRFS для определенных томов / папок, и я игнорирую этот факт. В самом деле, его можно отключить, но если вы это сделаете, зачем вам все еще использовать BTRFS? - Потому что вы все еще можете использовать COW для остальной файловой системы и всех других интересных функций (например, снимков и прочего) без снижения производительности для виртуального бокса и postgres? Конечно, для чистого сервера БД нет смысла использовать BTRFS и отключать COW. Но для машины / сервера общего назначения? Он позволяет использовать все классные функции (RAID1, ...) без потери производительности. В моих глазах беспроигрышный вариант.
Пользователь предложил отключить COW для BTRFS для определенных томов / папок. и я игнорирую этот факт. В самом деле, его можно отключить, но если вы это сделаете, зачем вам все еще использовать BTRFS?
Даже когда COW отключен для определенных файлов / папок, у них все еще есть возможности создания моментальных снимков. После создания снимка следующей записью будет COW, а затем возврат к записи на месте. Довольно простое решение для резервного копирования работающих баз данных, если вы делаете это, когда ФС не занята. Конечно, вы по-прежнему теряете контрольную сумму для всех операций записи на месте.