Removed msg from Павел. Reason: new user + forwarded

😁😁😁

Тут помню про ceph спрашивали, в сравнении с ZFS, вот поясняющая картинка, как по мне — очень тонкая ) Кстати, применимо и к glusterfs )

любой дистрибюшн)

ну мы же онтопик типа, люди хотели сравенения ) а тут каг бы картинка про то, что это разные вселенные (параллельные в основном), хотя конечно много можно сравнивать. Хотя, Ceph ближе к ZFS, чем к любой дгугой файловой системе (если уместно ZFS называть просто файловой системой), как минимум на уровне работы самого OSD с диском (скорее всего с оглядкой на ZFS и делали), те же LZ4 компрессия на лету, CoW и связанное с этим снэпшоты, клоны, send-receive функционал

единственно, что ZFS у меня добавляет свреху до 100 мкс на одну операцию ввода-вывода (реально меньше 70мкс для SSD диска со средней lat 35мкс), а ceph OSD 500-700 мкс )

единственно, что ZFS у меня добавляет свреху до 100 мкс на одну операцию ввода-вывода (реально меньше 70мкс для SSD диска со средней lat 35мкс), а ceph OSD 500-700 мкс )

А сколько иопс?

где? на Ceph в один поток на OSD 4k блоками где-то получается 1200-1500 IOPS при random write, в 16-32 потока 10-15к случайной записи по 4к блока, чтение там хорошо работает, легко можно упереться в потолок сети (у меня это 3,2GiB/s или около 29Gbit/sec) уже на блоках по 64к, фактически на мелких блоках молотит где-то 30-50к операций в секунду, т.е. средний lat меньше 0.5мс

Неплохой наборчик.

Фио кстати умеет симулировать процентное распределение нагрузки

кстати да, не плохо по результатам, рядом с нормальными цифрами для ceph. Если бы еще RDMA без глюков работал, хоршо бы помогло, а так TCP стэк свое жрет тоже, процентов 10-15% реально ужирает, не говоря о процессорном времени на переключении контекстов. У меня при тестировании на одну SSD (OSD) cpu sw заклинивает под 200к в секунду

Кстати о ZoL вспомнилось, оно бывает замирает на sync операциях, вот именно когда саму команду дергаешь, подвисает она и ждет в TASK_UNINTERRUPTIBLE (т.е. не убьешь его) и их может наплодится пакован, и load можно увидеть в 100-200 ) P.S. Несколько раз встречалось, например, при обновлении ядра, там есть скрипт update-initramfs - в нем дергается команда sync в одном месте, вот может подвиснуть, которая помогает тестировать отдельные OSD и смотреть на то как оно себя ведет

Фио кстати умеет симулировать процентное распределение нагрузки

Та у меня есть написанная хорошими людьми тулза

а перцентили для SLO вручную считать? :)

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

где выпадения

это на 16секундном интервале тестирование?

нет, минута. Параметр — это количество потоков, т.е. 16 потоков

попробуй минут 10-15 записи, чтобы кеш забить

посмотри, как оно себя будет вести

можно, да

чего куда подскочит и сместится

там кэш чей забить мне надо? там кэш отключен

у тебя кеш записи присутствует в системе?

в самом цефе

или он директ синк(по терминологии зфс)

тем более операциями по 4k даже в 32 потока (около 50мб в секунду) кэш особо не забьешь, оно будет сбрасываться точно быстрее

пиши по мегабайту блоками :)

директ, конечно. Тем более это же DC SSD с кондеями

и с локалхоста

а смысл по 1М тестить? оно упрется просто в скорость шины (около 400МБ), т.е. меньше 400 iops, да и наглядности мало, такой нагрузки не бывает в реале и она не цеф тестирует, он 400 операций легко пропихнет

сча покажу, а то теоритизирую )

что ж у тебя за шина такая

sata3 же — 6 Gbit/s

6 гигабит чтоль?

понятно

ну так у тебя же рейд

нет, нельзя рейд и CEPH

ты ведь не экспандером его расширял

я не про физический рейд

а скорее про методы записи

в смысле репликация?

скорее, аналог страйпа

нет, я тестирую OSD, т.е. репликация отключена, чтобы увидеть пределы по производительности конкретных хостов, дисков и все такое

ну понятно.

для сифы хороший лейтенси

в смысле size репликации = 1 )

я даж удивлён немножк

ну дык а я про что )

вполне у меня тут кластер, близко с хорошими значениями около пределов самого софта

это вот тест в один поток по трем OSD чтобы увидеть, что оно даже ровненько

т.е. proof of concept )

а эт ты не синхронно ли сейчас в них заливал данные с коммитами?

синхронные

не очень понял, у CEPH все операции синзронные, других нету по архитектуре

причем WA там около 11 )))

1.5к иопс на ноду..

не очень понял )

ладно. :)

если операции в среднем делаеются за 0,6 миллисекунды — то это где-то около 1500 IOPS )

миллисекунды

ну это да.

а в чем вопрос?

да я уж посмотрел :)

сами диски у меня выдают где-то 24-25к IOPS на 4к в один поток с sync

в транзакциях захлёбывается вся эта штука.

а знаешь.. проведи тест. вынеси ка одну из нод и посмотри, что будет. :)

вот реальный WA у CEPH на bluestore — где-то около 6-7

т.е. 35мс (lat sync у SSD)*6 ~ 200мс (правда там в несколько потоков может, но будем считать так) + сеть на TCP ~80-90мс + ну и сам код на себя ужирает 300-400 мс (не меньше)

кстати, сеть через RDMA дает +20мс всего, но на таких масштабах цифер это не очень существенно, но где-то 10-15% можно вытянуть, если бы оно там не глючило )

там с RDMA переключений контекстов еще меньше, что опять же ускоряет исполнение самого кода OSD

но код конечно у ceph та еще радость (

но, в защиту скажу, что у конкурентов (типа glusterfs, если можно его хотя бы близко так рассматривать, корректнее наверное сказать, что нет и конкурентов то), там совсем печаль в коде )))

вот так и живем ))

Вот не тонуло бы оно в транзакциях.

в каком смысле? где оно должно тонуть, о чем речь?

в каком смысле? где оно должно тонуть, о чем речь?

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

Эх... Там много что не подоходит, не говоря уж про то, что высокая нагрузка - это всегда специальная штука, там нет общего решения, кроме — "нафиг вы её делаете" :) нужно обходить и не делать высокой нагрузки. 99% ситуаций с высокой нагрузкой — кривой код и запросы без индексов в БД.

Я бы сказал так, ceph не очень подходит для высоких iops записи в один поток... Ну и это "внезапный дипскраб, хуже татарина" :) (т.е. не гарантированный отклик, если твои данные попали на пг в дипскрабе - у тебя резко lat скакнет)

Эх... Там много что не подоходит, не говоря уж про то, что высокая нагрузка - это всегда специальная штука, там нет общего решения, кроме — "нафиг вы её делаете" :) нужно обходить и не делать высокой нагрузки. 99% ситуаций с высокой нагрузкой — кривой код и запросы без индексов в БД.

Не все нагрузки поддаются оптимизации :) например, банальная телеметрия(не прометеевская) с сотен тысяч хостов.