13:48 < nhm_> WildyLion: ok, ok.. ;) one of the ones to teawk right nowis bluestore_cache_size 13:48 < nhm_> WildyLion: If you lower it, you might want to increase the cache_meta_ratio to help compensate 13:49 < nhm_> WildyLion: also, in rocksdb, decreasing the write_buffer_size, and maybe the write_buffer_number will probably lower rocksdb memory usage, but will likely hurt performance on fast disks.

как минимум

10:51 < WildyLion> guys, can anybody enlighten me what are the reasonable values for bluestore_cache_size and rocksdb_cache_size for a 2TB spinning disk OSD? nhm ? 10:52 < WildyLion> we were still seeing our OSD spike in mem consumption after a backfill 10:52 < WildyLion> but now i've set mon_rocksdb_options = write_buffer_size=33554432,compression=kNoCompression 10:52 < WildyLion> so we'll see

хм, почему кстати mon_rocksdb_options

я завтра посмотрю, по идее это только к мониторам и относится

и это касалось другой проблемы

https://work.techtonium.com/bitbucket/users/aaron/repos/ceph/commits/bcf20a1ca12ac0a7d4bd51e0beeda2877b4e0125

вот с ..._cache_meta_ratio я не экспериментировал, завтра можно погонять

Большой дефолт

Про кеш сайз

а, ну гиг да, вероятно что вместе с RocksDB и всем остальным - OSDшки прочно вылезали за 2ГБ RSS

db->set_cache_size(cct->_conf->bluestore_cache_size * cache_kv_ratio)

Нашел в сырцах

Блин. А оно 0.2

А я думал мож 4. Типа от того и беда

))

https://github.com/ceph/ceph/pull/15799

Кто то этого тут сильно хотел. И вот.

а кстати зачем, если в qemu и так есть тротлинг?

хотя да, для не-qemu полезно

но опять же... эм, есть же cgroup, blkio

и это даже в тикете написано

Да. Оба кейса.

Но есть случаи когда мотороллер не твой

А кластер твой

По поводу pagecache'а - ну если не предполагать что блустор лучше кеширует (в чем я сомневаюсь) то можно предположить что очень был нужен o_direct

а, стоп

там еще что-то связанное с атомарностью записи в BS

но по-моему это не в ту степь, это по поводу "почему архитектура именно такая"

Погодите, а пейджкеш не к vfs ли относится?

Блустор с блочным устройством работает,та не с ФС

Или я гон

да, с блочным. Блин, я туплю конкретно - у нас же нет механизма работы pagecache'а с блочным устройством

а почему блюстор не юзает FS - см. про то, что O_ATOMIC не включили в ядро, btrfs оказалась слишком ненадежной, ну соответственно они решили написать простейший fs-alike и назвали его bluefs

емнип так

Емнип, да

Про разговор о потребленной памяти на осд: без указания кэша в 512мб осд и за 4гб вылазил, а с этой настройкой - до 2гб не дотчгивает

Какой там дефолт?

что удивительно, дефолт bluestore_cache_size = 1024^3

т.е. гиг

Марк выше показывал кусок хидера, где это прописано

Может ты ещё что-то накручивал?

нет, остальное имело отношение уже к мониторам. Давай наверное до завтра, а завтра доказаетльно проверим, что влияет. Потому что я тоже не понимаю, как может быть 4GB RSS, если это не баг

виктор, юрий, насчёт блочных устройств и пейджкэша: root@host:~# dd if=/dev/sda of=/dev/null bs=1024000 count=1000 1000+0 records in 1000+0 records out 1024000000 bytes (1.0 GB) copied, 9.54779 s, 107 MB/s повторим-с root@host:~# dd if=/dev/sda of=/dev/null bs=1024000 count=1000 1000+0 records in 1000+0 records out 1024000000 bytes (1.0 GB) copied, 0.219861 s, 4.7 GB/s чем объясните? ;)) с блочным устройством можно работать как с обычным файлом и с pagecache'ом там всё ок. Нюанс только в том, что если вы вдруг захотите сделать fsync на какой-то блок данных (а если вы хотите гарантированной записи то вы захотите, я надеюсь ;) ) то fsync будет сделан на весь файловый дескриптор == "файл блочного устройства" == блочное устройство целиком. Ну и это некомильфо, конечно. Отсюда наверняка и растёт желание использовать O_DIRECT ценой ухода от pagecache'а

виктор, юрий, насчёт блочных устройств и пейджкэша: root@host:~# dd if=/dev/sda of=/dev/null bs=1024000 count=1000 1000+0 records in 1000+0 records out 1024000000 bytes (1.0 GB) copied, 9.54779 s, 107 MB/s повторим-с root@host:~# dd if=/dev/sda of=/dev/null bs=1024000 count=1000 1000+0 records in 1000+0 records out 1024000000 bytes (1.0 GB) copied, 0.219861 s, 4.7 GB/s чем объясните? ;)) с блочным устройством можно работать как с обычным файлом и с pagecache'ом там всё ок. Нюанс только в том, что если вы вдруг захотите сделать fsync на какой-то блок данных (а если вы хотите гарантированной записи то вы захотите, я надеюсь ;) ) то fsync будет сделан на весь файловый дескриптор == "файл блочного устройства" == блочное устройство целиком. Ну и это некомильфо, конечно. Отсюда наверняка и растёт желание использовать O_DIRECT ценой ухода от pagecache'а

Fsync_file_range же

http://man7.org/linux/man-pages/man2/sync_file_range.2.html

https://www.quora.com/What-is-the-difference-between-Buffers-and-Cached-columns-in-proc-meminfo-output

Это нащот почему dd закешилось

Buffers is raw disk blocks not represented in the page cache

https://www.usenix.org/legacy/event/usenix2000/freenix/full_papers/silvers/silvers_html/

sync_file_range() appeared on Linux in kernel 2.6.17.

Осень 2007

А еще O_direct этр не эквивалент фсинкной операции. Надо еще кеш самого диска профлушить

Buffers is raw disk blocks not represented in the page cache

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

Привет! Ребята, у меня готовится пачка серверов которые будут цепляться к кластеру. Взялся тестировать диски и не пойму почему такие странные результаты. Для начала: Серверы: Supermicro 5018D8-AR12L RAID контроллер там есть (LSI 2116), но он часть системы на чипе и никакого кэширования или управления виртуальными томами не делает. Все диски видны в системе как есть. Диски: Hitachi Ultrastar 7k6000 по 4Тб (HGST HUS726040ALE614) Использую fio чтобы посмотреть как они вообще себя будут вести если журналы размещать на них же: fio —filename=/dev/sda —direct=1 —sync=1 —rw=randwrite —bs=4k —numjobs=1 —iodepth=1 —runtime=60 —time_based —group_reporting —name=4krandw hdparm -W 0 /dev/sda 4krandw: (groupid=0, jobs=1): err= 0: pid=6368: Thu Jun 22 07:36:44 2017 write: io=63548KB, bw=1059.9KB/s, iops=264, runt= 60003msec clat (usec): min=473, max=101906, avg=3768.57, stdev=11923.02 hdparm -W 1 /dev/sda 4krandw: (groupid=0, jobs=1): err= 0: pid=6396: Thu Jun 22 07:39:14 2017 write: io=23264KB, bw=397005B/s, iops=96, runt= 60005msec clat (msec): min=1, max=48, avg=10.30, stdev= 4.12 Выходит что с выключенным дисковым кэшем результаты выглядят лучше: Commit latency в среднем ниже (хотя что-то очень сильно гуляет) и, соответственно, iops гораздо выше. Видимо, я чего-то недопонимаю? Возможно, так контроллер диска работает с кэшем? Буду благодарен если поможете объяснить.

-W 1 включает же. и Видно что с включенным clat ниже. что не так ?

Ну как, меня смущает что с выключенным кэшем средний clat ниже и иопсов больше выходит.

-W 0 avg=3768.57 -W 1 avg=10.30

в первом случае в микросекундах.

>clat (usec)

а лол

да, сорян

Мне кажется, такой тест не очень практичен для тестирования дисков для цефа. Если рассматривать filestore по крайней мере, то осд флушит КАЖДЫЙ запрос только в журнале. А в журнале там запись последовательная, да и вобще, журнал на ссд обычно. А при записи на XFS он синк делает время от времени — в результате чего под синк попадает несколько предшествующих врайтов одновременно, что даёт винту сделать это более оптимально, т.е. быстрее.

поэтому --sync надо убрать

и ещё энджин (под центосом!) в fio сильно влияет на результат

Мне кажется, такой тест не очень практичен для тестирования дисков для цефа. Если рассматривать filestore по крайней мере, то осд флушит КАЖДЫЙ запрос только в журнале. А в журнале там запись последовательная, да и вобще, журнал на ссд обычно. А при записи на XFS он синк делает время от времени — в результате чего под синк попадает несколько предшествующих врайтов одновременно, что даёт винту сделать это более оптимально, т.е. быстрее.

Ну так я же и написал что всерьез думаю о том чтобы размещать журнал в разделе в начале диска, а все остальное отдавать под filestore. С последовательной записью та же история, кстати. Без кэша - получше. Пробовал вместо стандартного sync движка libaio. С ним картина та же. Меня пока интересует сырая производительность дисков чтобы потом уже решить что и как с ними делать лучше. И вот когда увидел что с выключенным кэшем результаты лучше, тут у меня уже начало зудеть. Хочется какое-то объяснение получить)

Журнал точно надо на ссд выносить

иначе будет печалька

в плане иопсов

Не будет особо никакой печальки) Дисков то много и иопсы не приоритет.

Зато так я смогу осд если что взять и спокойно в другой сервер переткнуть и запустить за две минуты.

Не будет особо никакой печальки) Дисков то много и иопсы не приоритет.

тогда зачем бенчишь

Зато так я смогу осд если что взять и спокойно в другой сервер переткнуть и запустить за две минуты.

важно чтобы они себя в крушмапе обновили в плне своего локейшена

или как там это делается

тогда зачем бенчишь

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

Не будет особо никакой печальки) Дисков то много и иопсы не приоритет.

а вот тут ты немного не прав. парралельные джобы - да, а одна ВМ - у нее скорость будет как у обычного диска, точнее медленнее в 2 раза чем обычный диск

а вот тут ты немного не прав. парралельные джобы - да, а одна ВМ - у нее скорость будет как у обычного диска, точнее медленнее в 2 раза чем обычный диск

Чо это?

а вот тут ты немного не прав. парралельные джобы - да, а одна ВМ - у нее скорость будет как у обычного диска, точнее медленнее в 2 раза чем обычный диск

Хеширование же происходит для каждого объекта, не факт что соседние объекты смапятся в одни и те же PG.

Или я снова чо-то не понимаю)

Хеширование же происходит для каждого объекта, не факт что соседние объекты смапятся в одни и те же PG.

ну а пока объект не прочитался - следующий читаться и не будет