ВН
ceph-volume-systemd, что ли
Size: a a a
2020 July 03
ВН
man ceph-volume-systemd короче
ВН
не udev, udev как раз раньше был, с ceph-disk-ом
A
config diff
config show-with-defaults
вот я про эту команду имел в виду (щас покопался нашёл)
вот я про эту команду имел в виду (щас покопался нашёл)
A
но diff удобнее оказался
VO
значит про параметры.
blocks.db используется под wal и rocksdb.
распределение и аллокация места там динамическая и между ними и на каждый из.
т.е. walов там может быть несколько и размер каждого вала может меняться, со временем, от нагрузки.
ссылка про rcoksdb тут пробегала, из неё нам нужно знать сейчас что L1 будет размера
max_bytes_for_level_base, каждый следующий уровень -- в 10 раз больше, и что уровень должен целиком помещаться на db.
из того что там е написанно -- когда идет manual компакшен, то на db одновременно занимают место предыдущие скомпкшенные уровни, текущий уровень который мы сжимаем, и его новое представление. т.е. когда начинается последняя стадия, то на db будут присутсвовать:
WALы
уже скопакченные уровни без последнего
нескопакченный последний уровень
скопкаченный последний уровень.
и очень желательно что бы это все влезло в db!
blocks.db используется под wal и rocksdb.
распределение и аллокация места там динамическая и между ними и на каждый из.
т.е. walов там может быть несколько и размер каждого вала может меняться, со временем, от нагрузки.
ссылка про rcoksdb тут пробегала, из неё нам нужно знать сейчас что L1 будет размера
max_bytes_for_level_base, каждый следующий уровень -- в 10 раз больше, и что уровень должен целиком помещаться на db.
из того что там е написанно -- когда идет manual компакшен, то на db одновременно занимают место предыдущие скомпкшенные уровни, текущий уровень который мы сжимаем, и его новое представление. т.е. когда начинается последняя стадия, то на db будут присутсвовать:
WALы
уже скопакченные уровни без последнего
нескопакченный последний уровень
скопкаченный последний уровень.
и очень желательно что бы это все влезло в db!
VO
как рараститсь может нескомпакченный уровень я не знаю как оценить, поэтому ограничимся условием что два компакшена подряд должны гаранитрованно уместиться в db.
VO
отсюда получаем методику:
из размера db вычитаем четыре размера WAL (суммарно гиг, если все в дефолте).
остаток делим на числа из ряда 21, 211, 2111, 21111 (дальше я думаю никто не будет настолько богат), пока не получим число меньше гига
из размера db вычитаем четыре размера WAL (суммарно гиг, если все в дефолте).
остаток делим на числа из ряда 21, 211, 2111, 21111 (дальше я думаю никто не будет настолько богат), пока не получим число меньше гига
VO
получившуюся цифрирь округляем вниз до кратного 64кб (просто так)
VO
это и будет наше посчитанное max_bytes_for_level_base
VO
ну и пишем его в локальный хостовый ceph.conf
VO
[osd]
bluestore_rocksdb_options = "compression=kNoCompression,max_write_buffer_number=4,min_write_buffer_number_to_merge=1,recycle_log_file_num=4,write_buffer_size=268435456,writable_file_max_buffer_size=0,compaction_readahead_size=2097152,max_background_compactions=2,max_bytes_for_level_base=<BYTES>"
PA
отсюда получаем методику:
из размера db вычитаем четыре размера WAL (суммарно гиг, если все в дефолте).
остаток делим на числа из ряда 21, 211, 2111, 21111 (дальше я думаю никто не будет настолько богат), пока не получим число меньше гига
из размера db вычитаем четыре размера WAL (суммарно гиг, если все в дефолте).
остаток делим на числа из ряда 21, 211, 2111, 21111 (дальше я думаю никто не будет настолько богат), пока не получим число меньше гига
я тут потерялся, откуда цифры 21*?
VO
в результате db будет использоваться максимально эффективно. но в любом случае размер раздела ssd должен раза в два превышать рабочий размер роксдб. иначе от слиповеров компакшеном избавиться не выйдет
VO
я тут потерялся, откуда цифры 21*?
арифметика уровня 4 класса.
VO
у тебя уровни в 10 раз больше предыдущего
VO
т.е. с одним уровнем у тебя x*1
VO
с двумя -- x*1 + x*10 = x*11
VO
но последний уровень, самый толстый -- в двух экземплярах будет во время компакшена