M
его не сразу включили
Size: a a a
2021 March 18
ВН
Mkhl
его не сразу включили
кстати это же тот же кейс на который наступил я. короче EC+сжатие = говно
ВН
не используй EC+сжатие
M
в чем именно проявлялось?
ВН
Mkhl
в чем именно проявлялось?
2 момента
1) сильно разбалансируется место на осд даже при идеальной балансировке числа PG
2) по факту 2 реплики + сжатие занимает МЕНЬШЕ места, чем EC 2+1 + сжатие (!!!)
1) сильно разбалансируется место на осд даже при идеальной балансировке числа PG
2) по факту 2 реплики + сжатие занимает МЕНЬШЕ места, чем EC 2+1 + сжатие (!!!)
M
какая версия ceph была?
ВН
Mkhl
какая версия ceph была?
15
M
у нас 14
ВН
Mkhl
у нас 14
Один хрен
ВН
Mkhl
какая версия ceph была?
Оба момента вызваны одной и той же причиной - объект сначала режется на части, а ПОТОМ части жмутся. Но части чётности жмутся ГОРАЗДО хуже, чем части данных!
ВН
Балансер-то балансирует место на OSD исходя из чего?
ВН
Исходя из того, что если на всех OSD окажется примерно одинаковое число PG, то и место занятое будет примерно одинаковое
ВН
А из-за вот этого вот неравномерного сжатия это ни фига не так
ВН
На тех OSD, на которые попадает больше чанков ЧЁТНОСТИ - места занимается сильно больше
ВН
Я посчитал прям насколько
M
при достаточно большом кол-ве PG, должно быть более менее равномерно
ВН
Mkhl
при достаточно большом кол-ве PG, должно быть более менее равномерно
Возможно, это я не проверял. Хотел увеличить. Но когда я понял, что по факту это НЕ ЭКОНОМИТ МЕСТО
ВН
Просто выпилил EC
n🐈
Оба момента вызваны одной и той же причиной - объект сначала режется на части, а ПОТОМ части жмутся. Но части чётности жмутся ГОРАЗДО хуже, чем части данных!
прикольно