DP
у bcache-а же можно снимать хит рейтинг как-нибудь?
Size: a a a
2020 June 21
DP
зачем я здесь спрашиваю, если могу прогуглить 🤷♂️
ВН
у bcache-а же можно снимать хит рейтинг как-нибудь?
ну да, в его статистике
/sys/block/bcache*/bcacheDP
блин, надо будет затестировать как-нибудь
ВН
блин, надо будет затестировать как-нибудь
мне понравилось
DP
о, и даже под телеграф есть готовый плагин, в отличии от lvm
PA
Ну просто делаешь bcache как обычно, а поверх него делаешь osd
мы сейчас как раз с этим играемся.
1. просто закешировать всю осд бкешем - схема не очень, как разросся rocksdb, начались тормоза со спилловером
2. пересоздали осдшки с внешним дб на нвме - стало бодрее
3. залили еще данных на цеффс - опять тормоза
4. сейчас сделали отдельный пул под метадату из мелких кусков нвме - ждем синхронизации, посмотрим как будет
1. просто закешировать всю осд бкешем - схема не очень, как разросся rocksdb, начались тормоза со спилловером
2. пересоздали осдшки с внешним дб на нвме - стало бодрее
3. залили еще данных на цеффс - опять тормоза
4. сейчас сделали отдельный пул под метадату из мелких кусков нвме - ждем синхронизации, посмотрим как будет
AK
Странная у вас трава. Надо было все в обратном порядке делать, вообще-то. Сначала правильные решения и потом к всё более извращенным
ВН
мы сейчас как раз с этим играемся.
1. просто закешировать всю осд бкешем - схема не очень, как разросся rocksdb, начались тормоза со спилловером
2. пересоздали осдшки с внешним дб на нвме - стало бодрее
3. залили еще данных на цеффс - опять тормоза
4. сейчас сделали отдельный пул под метадату из мелких кусков нвме - ждем синхронизации, посмотрим как будет
1. просто закешировать всю осд бкешем - схема не очень, как разросся rocksdb, начались тормоза со спилловером
2. пересоздали осдшки с внешним дб на нвме - стало бодрее
3. залили еще данных на цеффс - опять тормоза
4. сейчас сделали отдельный пул под метадату из мелких кусков нвме - ждем синхронизации, посмотрим как будет
А циферки какие-нибудь есть? Я просто исхожу в целом из того, что rocksdb достаточно эффективно в памяти должна кэшироваться и ей не так важна скорость чтения девайса, если памяти достаточно
PA
Странная у вас трава. Надо было все в обратном порядке делать, вообще-то. Сначала правильные решения и потом к всё более извращенным
вполне может быть, пробуем разные варианты по мере того, как узнаем о них. про вынос метадаты цеффс рассказали как раз тут пару дней назад
2020 June 22
PA
А циферки какие-нибудь есть? Я просто исхожу в целом из того, что rocksdb достаточно эффективно в памяти должна кэшироваться и ей не так важна скорость чтения девайса, если памяти достаточно
какие именно цифирки?
ВН
какие именно цифирки?
Ну хз... типа вот X гб данных, при таком то тесте было 5000 иопс/мб/с/попугаев, а стало 500 когда базы роскдб выросли до Y гб
ВН
Чо нить такое
PA
не, такое не записывали. остался скрин гобенча с момента когда было 175млн объектов / 9Т стораджа
PA
потом докинули еще данных, начали тормозить рандомные осдшки, ну я писал недавно. сейчас идет ребилд после изменения краш-правил, как будет дальше - посмотрим
ВН
не, такое не записывали. остался скрин гобенча с момента когда было 175млн объектов / 9Т стораджа
Ну тут-то все хорошо на этом скрине
PA
ну да, это было уже после выноса дб на нвме
ВН
2020-06-21 22:24:34.883 7f964d224700 0 auth: could not find secret_id=14180
2020-06-21 22:24:34.883 7f964d224700 0 cephx: verify_authorizer could not get service secret for service osd secret_id=14180
2020-06-21 22:24:34.883 7f964d224700 0 --1- v1:192.168.5.15:6806/3115 >> v1:192.168.5.20:0/564722504 conn(0x560714998000 0x56060001f800 :6806 s=ACCEPTING_WAIT_CONNECT_MSG_AUTH pgs=0 cs=0 l=1).handle_connect_message_2: got bad authorizer, auth_reply_len=0
2020-06-21 22:24:34.883 7f964d224700 0 cephx: verify_authorizer could not get service secret for service osd secret_id=14180
2020-06-21 22:24:34.883 7f964d224700 0 --1- v1:192.168.5.15:6806/3115 >> v1:192.168.5.20:0/564722504 conn(0x560714998000 0x56060001f800 :6806 s=ACCEPTING_WAIT_CONNECT_MSG_AUTH pgs=0 cs=0 l=1).handle_connect_message_2: got bad authorizer, auth_reply_len=0
отвечу сам себе: понос, по-видимому, был вызван случайно просочившейся смесью пакетов debian sid 14.2.9 и официальных с download.ceph.com 14.2.9. к счастью, только на одном новом хосте и такой был только монитор. поставил обратно убунтовые пакеты с download.ceph.com - пришло в себя
ВН
дебиановцы, как всегда, чего-то там накрафтили и пакетирование цефа отличается от родного
ВН
хотя пожалуй просто с 3-м питоном собрали вместо 2-го