many thanks!

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

+ смотреть used / avail

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

вот таким образом например? rbd create --size 1024 pool_name/image_name

ну например да

только размер побольше, наверно

но это не засрёт цеф, ибо это thin provisioning

а как тогда правильнее?

создать, например, файл на N гигабайт и пхать его в цеф чем-то типа rbd import ... ?

ну ёмоё

ну например с помощью fio засрать

fio --ioengine=rbd --direct=1 --name=test --bs=64m --iodepth=32 --readwrite=write --clientname=admin --pool=pool_name --rbdname=image_name

воу, спасибо. Я не пользовался такой штукой

fio --ioengine=rbd --direct=1 --name=test --bs=64m --iodepth=32 --readwrite=write --clientname=admin --pool=pool_name --rbdname=image_name

я смотрю ты делаешь успехи

я смотрю ты делаешь успехи

да ну перестань :)

Коллеги, вы не сталкивались с залипшим backfill'ом? картина маслом: кластер jewel, 8 нод, 80 osd, XFS, CentOS, backfilling зависает на последних нескольких десятках тысяч объектов. из 5000 PG 5 не хотят бекфиллиться, все должны залиться на определенную osd. кластер почти не нагружен. диск хороший, менял трижды. ceph-osd на этом диске потребляет 270% CPU, при этом ничего не делает с диском, в iostat пустота. если выбросить эту OSD и дождаться рекавери, то появится другая OSD, которая не сможет принять в себя несколько последних PG, при этом это будут другие PG, не те, которые страдают на текущей OSD.

А логах что?

А логах что?

ничего фактически

ну то есть в дебаг-режиме там мясо, конечно, но понятнее (во всяком случае мне) не становится. могу куда-нибудь залить эту многогигабайтную портянку.

Много то зачем, начало когда cpu уходит ввысь

на старте, бро.

O_o

ну то есть, мм, смотри. пустой диск вставляешь, он начинает бекфиллиться. поток 120 Мб/с, как положено. при этом CPU потребляется хорошо (те же 250-280%) когда бекфилл почти завершен - потребление CPU остается, но процесс встает. в strace мясо, но нет глубокой разницы по статистике по сравнению с живым osd.

Сложна:-(

какие-то кастомные хитрые crushmap правила есть?

какие-то кастомные хитрые crushmap правила есть?

нет, краш сходится

или просто плоский кластер?

или просто плоский кластер?

плоский, да, один рулсет с выбором хоста, хосты в одной иерархии.

причем, по-видимому бекфилл каким-то образом там чуть-чуть идет. 10-20 объектов в час таки уходят из degraded/misplaced

А из-за чего вообще такая проблема может быть? Идеи хоть есть?

Начал гуглить, но что-то похожего ничего нет, может не так гуглю.

я уже обгуглился. у меня первично было подозрение, что в какой-то PG оказалось огромное количество маленьких объектов. но не подтвердилось.

я уже обгуглился. у меня первично было подозрение, что в какой-то PG оказалось огромное количество маленьких объектов. но не подтвердилось.

напиши в #ceph, народ из redhat поможет

напиши в #ceph, народ из redhat поможет

Ты задолбал

Если есть ответ на вопрос, то напиши его в чат, если нет, то не надо флудить

Посыл в другой чат не ответ на вопрос.

Ты задолбал

??

Я пробовал так делать, указывал журнал при создании через деплой, только проявлялась проблема с которой ты мне помог тогда ? Хотя у меня не последний jewel уже, может поправили

ceph osd prepare потом ceph osd activate и ок)

я уже обгуглился. у меня первично было подозрение, что в какой-то PG оказалось огромное количество маленьких объектов. но не подтвердилось.

А у тебя это не пул размером один случаем ?

нет, 3.

я дебил что ли, ожидать репликацию в пуле с размером 1

я дебил что ли, ожидать репликацию в пуле с размером 1

там просто проблема была, что если пул размером один то там перенос пг на другой осд —реально спецкейс с похожими спецэффектами.

с размером 2 - тоже есть интересности.

опаопа

какие ?

(с размером один — они задокументированы и даже сказано почему)

Примерно те же, по тем же причинам

мм, при выпадении одной ноды из восьми с размером 2 на полупустом кластере мы имели health_err больше часа.

мм, при выпадении одной ноды из восьми с размером 2 на полупустом кластере мы имели health_err больше часа.

а что именно там err ?

честно говоря, давно было, я не помню, что там было конкретно написано. насколько я понял, кластер не хотел позволять писать в PG, которые были в backfilling, несмотря на min_size 1

я с тех пор избегаю size 2

а я сегодня вот что сделал: у меня было osd_crush_chooseleaf_type = 0

Ну так она реплика упала и вот у тебя min_size 1

а я сегодня вот что сделал: у меня было osd_crush_chooseleaf_type = 0

ну так вот я круш мап сдекомпилил, поправил на host и типа отел заинсталлить, но!

тут нас ждал сюпрайз мазафака

в виде сообщения... ммм. щщас попробую найти его в истории поиска гугла

ну то есть, мм, смотри. пустой диск вставляешь, он начинает бекфиллиться. поток 120 Мб/с, как положено. при этом CPU потребляется хорошо (те же 250-280%) когда бекфилл почти завершен - потребление CPU остается, но процесс встает. в strace мясо, но нет глубокой разницы по статистике по сравнению с живым osd.

А с весами что?

1.0000 везде

в виде сообщения... ммм. щщас попробую найти его в истории поиска гугла

Error EINVAL: Failed crush map test: *** Error in `crush tool': munmap_chunk(): invalid pointer 0x(тут цифры)"

1.0000 везде

Weight or reweight?

Их там два веса

80 одинаковых OSD 60 1.81850 osd.60 up 1.00000 1.00000

Error EINVAL: Failed crush map test: *** Error in `crush tool': munmap_chunk(): invalid pointer 0x(тут цифры)"

но я, знаете, не пальцем деланный. узнал что именно не так и пофиксил crush map!

впрочем, кажется я выкинул три OSD'шки последовательно и кластер наконец приходит в состояние health_ok

и всё перепроперчилось так как мне надо !

впрочем, кажется я выкинул три OSD'шки последовательно и кластер наконец приходит в состояние health_ok

Не вижу логики

что, впрочем, не добавляет мне понимания.

Ага

что, впрочем, не добавляет мне понимания.

ceph pg XXXX query чё-нть говорит?

интересного ничего. анфаундов не было. список объектов был. объекты были доступны.

"blocked": "peering is blocked due to down osds",

нет

все PG были active

а прямо сейчас проблема проявляется ?

к сожалению, уже нет, это все-таки прод. я планирую дождаться схождения кластера и потом вернуть эту подозрительную osd с маленьким весом.

к сожалению, уже нет, это все-таки прод. я планирую дождаться схождения кластера и потом вернуть эту подозрительную osd с маленьким весом.

Ну, тоже вариант

ЗАЕБЦА

но это не блюсторный осд

зачем и как?