LINUX.ORG.RU
ФорумAdmin

zfs + mongodb, посоветуйте тюнинг

 ,


0

4

Есть обычная вебня в докере. Форум с очень большим количеством картинок в монге. Основная база гигов 20, и картинок терабайты.

Я знаю, что под монгу советуют xfs + lvm, но хочется иметь дешевых снапшотов, и поэтому есть навязчивая идея поставить zfs. К сожалению, не получится под каждый контейнер прилепить свои настройки блоков, только подкрутить один раз для всех.

Собсна, вопрос: это будет работать с не очень большой просадкой по скорости, или вообще без шансов? Настройки думал стандартные:

  • отключить atime
  • xattrs хранить в инодах
  • кеш только для метаданных (без l2arc)
  • ? насчет компрессии не уверен, в монге и так уже есть
  • record size думал юзать дефолтный (кажется 128k)

zfs та что на Ubuntu 20.04lts. Не 2.х, но с какими-то бекпортами.

Это будет с вебней вменяемо работать? К сожалению, в интернетах толком статей нет (уже обыскался). Только про innodb, но там размер блока тюнят и разницу не сравнивают.

На serverfault, где у чувака «фсе плёха», он сам дятел, т.к. заюзал l2arc и ограничил ему память всего 2 гига.

★★★★★

Ответ на: комментарий от Black_Shadow

А смысл? В монге свой кеш у WiredTiger, а больше с диском кроме логов никто не общается. Есть только 2 диска под зеркало, slog некуда втыкать.

У тебя есть опыт использования на продакшенах? Меня recordsize больше волнует, резать его или нет. Я какбэ перерыл уже интернеты вдоль и поперек, мало статей очень.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

резать его или нет

Под мультимедию его обычно наоборот увеличивают, чтобы данные читались за раз либо целиком, либо куском побольше, но у тебя всё в базе... А для БД ставят в размер страницы БД.

GAMer ★★★★★ ()
Последнее исправление: GAMer (всего исправлений: 1)
Ответ на: комментарий от Vit

Ну я монгу не трогал ) , но судя по http://source.wiredtiger.com/mongodb-3.4/tune_page_size_and_comp.html страницы у неё таки есть.
И можно покрутить allocation_size и leaf_page_max «to better match the underlying storage block size».
А этот самый storage block size выбрать уже исходя из среднего размера своих картинок.

GAMer ★★★★★ ()

под монгу советуют xfs + lvm

Я бы посоветовал рассмотреть (сделать бенчмарки и посмотреть на них) xfs over zvol (zfs volume)

Несколько лет назад это работало быстрее, чем zfs (как fs).

Harliff ★★★★★ ()
Последнее исправление: Harliff (всего исправлений: 2)
Ответ на: комментарий от Minona

xfs over zvol

Несколько лет назад это работало быстрее, чем zfs

сдается мне что-то не так меряли

История следующая: был хост с Proxmox 4.x; в нём был ZFS pool с raidz2 из 6 HDD. Была создана FS c настройками по умолчанию (recordsize=128К, то есть), которая раздавалась через samba. Пользователи довольно скоро стали жаловаться на тормоза файлового сервера (было по несколько жалоб в день).

Тогда была создана VM с volume из указанного выше пула. Внутри VM диск был отформатирован как XFS и на него были перенесены данные; внутри VM была поднята samba и организован доступ пользователям к тем же файлам. Жалоб на тормоза за несколько лет эксплуатации не поступало.

Harliff ★★★★★ ()
Последнее исправление: Harliff (всего исправлений: 2)

Хм… погоняли тут zfs и xfs на импорте данных форума. Нагрузка конечно не рабочая в отношении read/write, но результаты забавные:

  • Импорт постов:
    • xfs: 16 min
    • zfs: 4.5 hours
  • Импорт картинок
    • ~ по 6 часов и там и там

Ну то есть на тоннах мелких записей zfs заметно сливает. Для рабочих нагрузок наверное не особо критично.

Теперь разбираемся с установкой btrfs, хочется понять как там.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

Импорт постов:

  • xfs: 16 min
  • zfs: 4.5 hours

Может, к разработчикам zfs обратиться? Настолько колоссальная разница говорит или о сильно неоптимальных параметрах настроек (по-умолчанию) или о недоработках в реализации. Я думаю, им такой кейс интересен будет и они поищут «bootlenek».

Harliff ★★★★★ ()
Последнее исправление: Harliff (всего исправлений: 2)
Ответ на: комментарий от Harliff

Ну настройки как описывалось, и размер блока с 128 до 16 килобайт подрезал. Картинки-то оно без тормозов всосало. Проблемы именно с тоннами мелких записей, хотя они везде где можно большими блоками лились.

Хер знает, короче. Нагрузка конечно сплошная запись, чего на продакшене никогда не будет, но все равно странновато. Я ожидал прососа в 2-3 раза - такое бы вполне устроило.

На неделе разберемся как btrfs конфигурять и будет понятнее.

Очень хоцца легких снапшотов и CRC.

Vit ★★★★★ ()
Ответ на: комментарий от anc

Да не, там все в докеровских контейнерах, разогрева нет. Да и фик с ним. Если btrfs будет лучше - поедем на ней. Если не пойдет - буду ковырять lvm thin provisioning. Вроде там снапшоты легкие, хоть и без crc.

Vit ★★★★★ ()

что под монгу советуют xfs + lvm

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

tz4678 ★★ ()
Ответ на: комментарий от Vit

Снапшоты thin provisioning вроде быстрее обычных, которые жутко тормозят.

Я не про снапшоты. На тонких томах io не очень. Та же шняга с обычными но имеющими снапшоты.

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

Уверен? Точно? LVM ни каким образом не может обеспечить десяток легких снапшотов без радикальной деградации io?

Вроде в доке и на SO писали, что тонкие тома «не такие ужасные как обычные», возможно я что-то не понял.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

Может и обеспечит, погоняйте бенчмарки.

В целом, LVM thin выглядит наколенной поделкой, по сравнению с zfs.

PS: лично я, там где нужна производительность, использую голый LVM (не thin).

Harliff ★★★★★ ()
Последнее исправление: Harliff (всего исправлений: 1)

В общем, на btrfs топики импортятся 30 минут вместо 16 на xfs. Стандартная предсказуемая просадка для cow. Вполне приемлимо. Без приключений, как с zfs, когда разбираешься с тоннами опций, делаешь все «правильно», и все равно получаешь на выходе потенциальную тыкву.

Из явных косяков - если диск долбанется, то не рекомендуют юзать автоматическое монтирование в degraded режиме. Только ручками. Поэтому рутовый раздел сделаю классическим md + xfs. А btrfs для докера, все свободное место.

Итого - для важных данных имеем crc + дешевые снапшоты, чего для счастья и было надо.

Vit ★★★★★ ()
Последнее исправление: Vit (всего исправлений: 1)
Ответ на: комментарий от Vit

XFS под «/» - не дело. Только вот вчера об это споткнулся. Загрузка после сбоя не прошла автоматом - просто виснет без логов.

Т.к. для восстановления XFS нужно: примонтировать в RO (для реплея лога), отмонтировать, пройтись xfs_repare, затем только монтировать «/» в RW. Обычно же при загрузке этого не происходит. К тому же проверка при загрузке будет «не происходить» каждый раз при монтировании ФС другой версией ядра, т.е. даже без сбоя.

Ну, а вот fsck.ext4, например, сам может сделать replay лога перед проверкой, и никаких дополнительных монтирований не нужно. Поэтому, имхо, самый толковый вариент под «/» только ext4.

К тому же для бэкапа LVM-снапшота XFS, нужна тоже куча доп.телодвижений с монтированиями, размонтированием и сменой uuid. И ещё 1 монтирование снэпшота в RW(!), чтобы просто сделать список «exclude» для xfsdump-а. В то же время dump ext4 гораздо проще и удобнее, к тому же он умеет сразу сам сжимать, да ещё и выбрать компрессор и уровень сжатия. И ext4 restore позволяет сделать интерактивное восстановление отдельных файлов и директорий.

А вот для данных XFS вроде получше, т.к. усиление записи меньше и есть полезные reflink-и.

anonymous ()

Что страннее всего, монга при импорте умудрялась натурально виснуть, с концами, на xfs и zfs. А на btrfs не виснет.

Создать тестовый кейз не представляется возможным, но эффект стабильный. Процесс просто затыкается, без ошибок в логе.

Память c ECC. Я бы и рад свалить все на железо, но на btrfs-то работает.

Vit ★★★★★ ()