ну раз 100% CPU то я думаю, с помощью GDB можно посмотреть где он залупился

он не в дедлоке

а я и не говорил продедлок

просто по трэйсбэку за несколько прерываний видно, что он что-то однотипное делает

(иногда, если повезёт)

яб попробовал

ну или тупо запрофайлерить — там и видно будет что же именно жрёт

есть тут Ванги ?

Интересная вакансия "OpenStack Systems Engineer" — https://hh.ru/vacancy/18671487?from=share_android

Я все видел

Нет скрина, нет доказательств

https://bugzilla.redhat.com/show_bug.cgi?id=1377174

ЕБАНАЯ КРАСНАЯ ШЛЯПА. НАСРАТЬ В НЕЁ

не могут блять сделать чтобы одно говношляпное поделие работало с их же другим.

вот на этот баг я напоролся

обновился блять

ПИДОРЫ ГНОЙНЫЕ

воу воу, полехчи

Узбагойся

мсье ещё не бугуртил с systemd в 4.9 ядре

идёшь впереди стейбла любого дистра, много нового думаешь о инопланетянинах которые его пишут

Ну так впереди стейбла. Как овощ в среде высшего разума

ну тип да

пишут кривым хуем растущим внутрь

у нас вообще есть тут евангелист красных шляпок в соседнем чяти

иди может его понасилуй, если хочешь офк)

в каком

да в любом

кличка старый хрыч

https://aboveaverage.com/wp-content/uploads/2015/11/trump-shit-with-red-hat-2.jpg

@erzent

у нас вообще есть тут евангелист красных шляпок в соседнем чяти

Он так себе, малолетка, матерых тут нет, они в irc сидят

а где кстати у красношляпки каналы свои?

неужто на фриноде?

Почти везде

я по цефу видел какие-то другие, но не помню какие были

"чтобы задеплоить каламари, научитесь в солт"

найс интрукция:))

Да, причем инструкция не учитывает, что солт и так уже используется и как я туда каламари то прикручу епт

а где кстати у красношляпки каналы свои?

даже в телеграмме есть 2 канала

красная шапка рулит

официальных?

я прям там прихожу и мне в сла фиксят сломанный сателлит в трёх местах?

оф каналы ток на фриноде и теподдержка в слаке, а так разрабы сидят

разрабы чего сидят?

в слаке хуяке

разрабы чего сидят?

и ядра и гнома и systemd

а ты вниматенльный

и ядра и гнома и systemd

шапка ядры делает, вот так номер

что ещё нафантазируешь?:)

шапка ядры делает, вот так номер

вообщет 25% коммитов в ядро шапка делает

и как это отвечает на то, что всё ядро оно типа как-бы не делает

оно его пакует, и шипит иногда бэкпортит чето, иногда закрывает дырочки

поставь 7 centos, слабо себе представляю, что за рейд контроллер который не работает там, а ток в 6

если ток это не древность совсем

https://elrepo.org/bugs/view.php?id=495

вот просто блять вжух, и хуй положен

????

поставь 7 centos, слабо себе представляю, что за рейд контроллер который не работает там, а ток в 6

DL380 g9

Поставь центос 7 и удивись

что ваще ниче не работает?

Ну точнее анаконду запусти

я на хпшке боролся включать на кентосе хардварный вачдог, точнее чтобы он не ресетил машину после 5 минут работ, лол

ну ты просто не заплатил. подумаешь баг....

ну я по всей лестнице разрешения конфликта прошёл, только не смирился и принял, а сменил буйную

https://koji.fedoraproject.org/koji/packageinfo?packageID=10264

всё есть для федора

Федора уже ынтырпрайз для бомжей

А не центось

а это для копрофилов

и копрофагов

?

Пойду говна наебну:-(

вести с полей моего реалити-шоу, продолжаю издеваться над своим кластером. новые симптомы: 1) высокий cpu usage на osd, как мне кажется, не связан с репликацией. такой же высокий cpu usage наблюдается на osd, на которых нет pg, которые не active+clean, и сейчас osd, на которых недореплицированная pg не имеют такой аномально высокой нагрузки 2) я покрутил crush tunables в optimal и получил 76% misplaced данных. подождал сутки, почти все дореплицировалось, осталась одна PG, в которой 10к (всего в кластере 69М) объектов остались в misplaced. 3) очень, очень медленно эти 10к объектов рассасываются. собственно, свежие вопросы: 1) есть ли у вас, господа, долгий (десятки часов) хвост ребаланса? основная часть ребаланса у меня прошла на хорошей скорости (1-2 Гб/с), а оставшиеся несколько гигабайт данных переливаются десятки часов. 2) есть предположение, что такое поведение - это следствие какой-то кривизны в CRUSH. уважаемые мэтры, если вы видите здесь что-то неадекватное - скажите мне, пожалуйста. мне не нравится например строчка "device 36 device36", но ее удаление и перекомпиляция/загрузка крашмапы не удаляют упоминание. Ранее был osd 36, который по процедуре стандартно выкинули. crushmap: https://gist.github.com/spuzirev/362a2867e2f4db1f302d43e2d296308e ceph osd tree: https://gist.github.com/spuzirev/e8bbd1d4f7056876f76e3016ec3d6d3e ceph -s: https://gist.github.com/spuzirev/8559f4704ad696d3c300d9006ae004ff

И да, я наконец-то нашёл в чём дело. в тормозах кластера у нас есть 2 проблемы — одна — оффлоадинг на сетёвке добавляет тормозов (уже отключил), и второе — таки TLC SSD ЖОВАННОЕ ОНО

в него упёрлось. завтра заменю SSD — кластер будет работать быстрее.

# hdparm -i /dev/sda /dev/sda: Model=OCZ-TRION150, FwRev=SAFZ12.3, SerialNo=26MB31F9K1AU

вести с полей моего реалити-шоу, продолжаю издеваться над своим кластером. новые симптомы: 1) высокий cpu usage на osd, как мне кажется, не связан с репликацией. такой же высокий cpu usage наблюдается на osd, на которых нет pg, которые не active+clean, и сейчас osd, на которых недореплицированная pg не имеют такой аномально высокой нагрузки 2) я покрутил crush tunables в optimal и получил 76% misplaced данных. подождал сутки, почти все дореплицировалось, осталась одна PG, в которой 10к (всего в кластере 69М) объектов остались в misplaced. 3) очень, очень медленно эти 10к объектов рассасываются. собственно, свежие вопросы: 1) есть ли у вас, господа, долгий (десятки часов) хвост ребаланса? основная часть ребаланса у меня прошла на хорошей скорости (1-2 Гб/с), а оставшиеся несколько гигабайт данных переливаются десятки часов. 2) есть предположение, что такое поведение - это следствие какой-то кривизны в CRUSH. уважаемые мэтры, если вы видите здесь что-то неадекватное - скажите мне, пожалуйста. мне не нравится например строчка "device 36 device36", но ее удаление и перекомпиляция/загрузка крашмапы не удаляют упоминание. Ранее был osd 36, который по процедуре стандартно выкинули. crushmap: https://gist.github.com/spuzirev/362a2867e2f4db1f302d43e2d296308e ceph osd tree: https://gist.github.com/spuzirev/e8bbd1d4f7056876f76e3016ec3d6d3e ceph -s: https://gist.github.com/spuzirev/8559f4704ad696d3c300d9006ae004ff

что я заметил:

host ceph07

там нет OSD с именем device36

это раз. тоесть у тебя есть осд который сейчас ни в каком ни в хосте

root default

Я потом раскурился, это норм после удаления осдшки

item ceph07 weight 16.366

item ceph06 weight 18.185

тоесть вес там поменьше (ну, это норма)

Я вернул 36, все веса вровень, device36 стал нормальным. Проблема на месте.

высокий cpu usage на osd