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

зависит от количества осд

если у тебя софт внутри виртуалки генерит один поток, хоть ты 100500 ОСД поставить, скорость будет единтичной

и упрется в скорость записи primary OSD+реплики

ну не совсем

потому что писнул 4 метра в ПАМЯТЬ первого осд. НЕДОЖДАЛСЯ СИНКА. пошел писать второй блок и тд

я из-за этого и говорю, что ceph и thread=1 и depth=1 это писец зло

а потом в конце когда будет мегасинк (если будет вобще) но должен. то будет ожидаться параллельно

А какие цифры получаются в реале на однопоточной нагрузке?

что есть реал ?

а потом в конце когда будет мегасинк (если будет вобще) но должен. то будет ожидаться параллельно

память не резиновая )

память не резиновая )

на осд считай резиновая

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

А какие цифры получаются в реале на однопоточной нагрузке?

thread=1 depth=1 30-40 МБ, при 30-40 IOPS'ов, тоесть блоком 1 Мб и это с тремя репликами

с 2 репликами будет ~50

попробуй с одной репликой -- охереешь

я так понял это связано тупо с задержкой по сети

между осд которая

Это совсем без ssd? Сеть какая?

рандомно, порядка 150 IOPS'ов, как раз упирается в HDD

это с журналами на SSD

А чтение?

а журналы какого размера ?

да все тоже самое

10-20 Гб картина одинаковая

соственно это и послужило написанию blustore

да все тоже самое

Речь про чтение/запись?

Так чтение не должно деградировать от числа реплик

теже БД, на Ceph ну ни как нормально не работают из-за такой особенности

Так чтение не должно деградировать от числа реплик

Открою тайну :)), чтения в Ceph происохдит медленнее чем запись

имеется ввиду последовательно

Речь про чтение/запись?

и про чтение и про запись имело ввиду

Открою тайну :)), чтения в Ceph происохдит медленнее чем запись

да, но чтение суперхот данных в виртуалках и так кешируется неплохо

ты меня еще про кэш спрашивал...тут ваще на лекцию хватит )

я так понял это связано тупо с задержкой по сети

Ну так вроде есть rdma и dpdk

фап-фап-фап. ага. а что на практике ?

да, но чтение суперхот данных в виртуалках и так кешируется неплохо

ну как правило тесты все через drop cache гоняются..

Ну так вроде есть rdma и dpdk

нисколько не прод еще

фап-фап-фап. ага. а что на практике ?

лекции с практики :))

ну как правило тесты все через drop cache гоняются..

тесты говенные. меряют ворст случай. а не реалистичный. ты же не проце не выключаешь кеш когда бенчмарки делаешь ?

тесты говенные. меряют ворст случай. а не реалистичный. ты же не проце не выключаешь кеш когда бенчмарки делаешь ?

Открываем любую доку по замеру производительности и видим там drop cache memory

это им не поможет если тест долгий

это и дает реалистичные тесты без учета кэшей

ну тогда да. прост кеши каг-бы пиздец помогают

ну тогда да. прост кеши каг-бы пиздец помогают

ну БД не помогут например

тащемта если синки вызываются тогда когда хотел аффтар (на каждый врайт?) то хоть с кешем хоть без него.

ну БД не помогут например

на чтение ? еще как помогут

Пж зовёт синк только на запись в лог

ну щас ага

а потом то он всеравно в основное место где таблицы синкает. только редко

на чтение ? еще как помогут

Если БД находится в HugePage к сожалению неа

Если БД находится в HugePage к сожалению неа

вот тут поподробнее

вот тут поподробнее

тупо нет места для file cache :))). Да я на примере Oracle просто говорю

там еще и ASM, так что все мимо Posix IO

тупо нет места для file cache :))). Да я на примере Oracle просто говорю

ну тогда к ораклу. один хрен я уверен если они и используют о директ -- то у них свой кеш на чтение стопудово есть в оперативе

ну не пейджкеш тоесть. а свой собственный.

вот не похер

для цефа

если рассматривать чтение, то более менее продакшеновский софт читает отличной от depth=1, как правило 32, в связи с этим проблемы чтения не так сильно чувствительны.

пожалуй да

а вот с записью реально проблемы, т.к. основная масса СУБД (даже к некоторым NOSQL относится) пишут свои логи thread=1 и depth=1

и кэш тут не помогает, так как почти на каждый записанный блок СУБД делает fsync

поцггрес + асинк_коммит=Труе

но тут кагбы ничо не сделаешь...

поцггрес + асинк_коммит=Труе

несовсем, он их просто более большими блоками начинает писать и все равно делает fsync )

но тут кагбы ничо не сделаешь...

мы решаем это mdadm Raid0 из 4 дисков

и как это рещает проблему?

один поток превращается в 4 (если 4 диска)

страйп же

дак проблема в мегабайтах в секунду или в иопсах ?

и в том и другом

edo1 для тебя )

@edorus1

абсолютно неверно

под лейблом ноне нарисован кеш=ансейф

кеш ноне вобще в цефе не реализуем. ибо это означает кароче о_директ и пропуск пейджкеша. какой нафиг пейджкеш в рбд

так, а с cache=writeback живая миграция в qemu считается unsafe?

если нужна сохранность данных и живая миграция - юзать write through?

ну да не понятно нарисовал, но суть будет такая же, т.к. да, none в librbd не реализован, вот и команда fsync завернется на KVM

из-за этого при некоторых особенностях cache none быстрее, чем cache writeback