« Rev
@ceph_ru   158
Fwd »


l1njan
https://habrahabr.ru/company/at_consulting/blog/324374/
l1njan
куча картинок, инфонагрузки ноль
✠ FLASh ✠
еееп
✠ FLASh ✠
по гластеру ну ниче не информативно
Михаил
А что вы хотите видеть в статье по цеф?
Maxim
профурсеток
Михаил
бенчмарки
Чего с чем?
Sergei
Чего с чем?
железок и собранного кластера.
Sergei
и изменения попугаев от крутилок
Joe
А что вы хотите видеть в статье по цеф?
Про тонкую настройку и важные параметры, рекомендации по ним. Как лучше организовывать кластер, какие подводные камни. Кому нужны бенчмарки? :) Все равно у каждого на своем железе они будут разные.
kiosaku
не ставьте нагруженный кластер на сата-диски. :) журнал на ссд помогает, конечно, но до 3-5к иопс
✠ FLASh ✠
А что вы хотите видеть в статье по цеф?
бенчмарки "дефолтного" сефа и "тюненного", почему бы и нет, на одном и том же железе. Комент от Joe Black ваще в точку прям))
Dimonyga
Во! вопрос возник, как быть с TSO LRO GRO ? что цепху больше нравиться ?
kiosaku
и чего-то маловато графиков
kiosaku
ceph_exporter больше же метрик отдаёт
Михаил
ceph_exporter больше же метрик отдаёт
ну не всё же тащить
Mike
Вроде commit_latency важнее, чем apply?
kiosaku
swap включён???
Михаил
Вроде commit_latency важнее, чем apply?
эм, ну я нашёл, что apply важнее
kiosaku
рука-лицо
Михаил
swap включён???
а что не так?
Михаил
рекомендации отключать свап не видел
kiosaku
зачем свап на нагруженных системах?
kiosaku
если не хватает памяти, то её надо добавить
kiosaku
а не затупливать систему на общении с диском
Dimonyga
По свапу не соглашусь.
kiosaku
?
Dimonyga
в нормальном режиме цепф жрет примерно столько, сколько рекомендуют, но у меня, пару раз, была ситуация что при ребалансе он отжирал до 50 гигов на процесс OSD
Dimonyga
Держать столько памяти в системе смысла не вижу, ей там не место
Dimonyga
я рассчитываю примерно 2 гига на двухтерабайтник + большой свап на отдельном диске есть всегда.
kiosaku
и вместо работы с быстрой памятью система работала с диском, который медленнее на порядки
Dimonyga
Всё верно, но это нештатный случай. А держать 50 гигабайт СВОБОДНОЙ памяти не серваке - лучшее решение ? мне бы ваши бюджеты.
kiosaku
увы, бюджеты тоже не бездонные
kiosaku
но ждать, пока ребаланс закончит свопиться - дороже
Mike
эм, ну я нашёл, что apply важнее
commit важнее. Commit - сброс изменений на диск, apply - применение изменений в RAM для FS.
Mike
"This is a report about flushing data out to the backing-store disk, and fs_commit_latency is generally going to include a syncfs syscall, so 150-600 ms is not unreasonable. The fs_apply_latency (for applying updates to the in-memory filesystem) and the numbers on the journal are the ones to look at. -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com"
Mike
http://lists.ceph.com/pipermail/ceph-users-ceph.com/2014-January/016648.html
Mike
Скорее оба важны, т.к. показывают латенси OSD c разных сторон: commit - XFS/HDD проблемы, apply - OSD/NUMA/FS
Михаил
Скорее оба важны, т.к. показывают латенси OSD c разных сторон: commit - XFS/HDD проблемы, apply - OSD/NUMA/FS
погоди, если у тебя всратый диск будет то и apply будет большим
Михаил
т.к. фс медленно ответит
Mike
apply оно в RAM. Если у тебя диск тупит, но успевает сбросить изменения на диск за промежуток между синхронизацией журнала - то apply ничего не покажет.
Mike
даже если и не успевает, тоже может не показать (надо смотреть в код).
Mike
А вот проблемы с NUMA - покажет apply, например.
Михаил
А вот проблемы с NUMA - покажет apply, например.
а что ты подразумеваешь под проблемами с NUMA?
Mike
а что ты подразумеваешь под проблемами с NUMA?
OSD сидит на одном CPU, а его диск доступен с второго CPU.
Dimonyga
А вот проблемы с NUMA - покажет apply, например.
Что-то моя математика не сходится. Проблемы с нума измеряются парой сотен герц, и в Apply врятли будут видны. Исключая запущенные случаи.
citius
>prometheus + grafana
citius
о, а дайте шаблонов? а то у меня стек такой же, чего велик пилить? :)
Artem
Всем привет! Собрали на одном сервере два рейда 5.0. Запустили два докера с ceph osd на каждый из рейдов. Насколько дерьмово такое решение? =) (Кроме того что серверу каюк и osd также)
Михаил
или экспортер под цеф?
citius
ага
Михаил
а у нас там только 3 дашборда)
citius
экспортер я не искал еще
citius
он у вас тоже кастом?
Михаил
не, ванильный
Михаил
прям докер образ взял
citius
понял. ну тогда ковырну пока сам ) думал дешбордов красивых с умными графиками есть
citius
морока их ваять
Михаил
не, у меня только iops ы да perf +apply latency
Dimonyga
Всем привет! Собрали на одном сервере два рейда 5.0. Запустили два докера с ceph osd на каждый из рейдов. Насколько дерьмово такое решение? =) (Кроме того что серверу каюк и osd также)
Даже если убрать докер - городить цепх поверх райда - нужно только в исключительных случаях, которые встречаются крайне редко. У меня есть такая инсталяция, но там это реально необходимо, так как mission critical данные малого объема и простой или хоть насколько то значительное замедление - очень дорого обходится. Делайте без этого. А в крайнем случае делейте 10-ку хотя бы.
Dimonyga
Докер то интересно чем помешал, просто изолированный процесс. Вопрос в iops, всяко выгоднее получить + 300 iops с рейда в 5.0, чем по 150 с sata?
300 иопсов ценой чего ? кол-ва дисков. вам цепх, на сырых винтах даст столько же или даже больше. По поводу докера - зарержки виртуализации сети очень сильно влияют на производительность. Уж лучше тогда chroot
kiosaku
сата под виртулизацию - только если у вас нет интенсивной работы с диском на виртуалках/контейнерах
kiosaku
иначе плакать будете
citius
тащем-та рейд 5 это тормоза на запись
citius
так что цеф, думаю, в любом случае будет не медленнее
kiosaku
если с диска, в-основном, чтение, то и 5-ый рейд сойдёт
Андрей
А почему все говорят о скорости, забывая про задачу?!
Artem
сата под виртулизацию - только если у вас нет интенсивной работы с диском на виртуалках/контейнерах
Тут не совсем понятно, опять камни в сторону докера или что имеется в виду, что SAS нужны?=)
kiosaku
сас
« Rev
@ceph_ru   158
Fwd »