13 494
правки
Изменения
Нет описания правки
Задержки часто важнее простой пиковой производительности случайного чтения/записи, так как далеко не каждое приложение может загрузить диск при большом параллелизме / глубокой очереди (32-128 запросов).
Ceph — это SDS, его задержки всегда выше, чем у устройств при прямом доступе, и от этого никуда не денешься. В интернете есть доклад Nick Fisk «Low-Latency Ceph», в его исполнении Low latency это 0.7ms, то есть на лучший результат рассчитывать особенно не приходится. 0.7ms — это всего лишь примерно ~1500 iops в 1 поток(хорошая новость — другие SDS и просто SAN-ы тоже тормозят :)).
Сначала прогоните fio на голом диске:
* Задержка записи в журнал: {{Cmd|1=fio -ioengine=libaio -sync=1 -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=write -runtime=60 -filename=/dev/sdX}}
* Задержка случайной записи: {{Cmd|1=fio -ioengine=libaio -sync=1 -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=randwrite -runtime=60 -filename=/dev/sdX}}
* Пиковые IOPS случайной записи: {{Cmd|1=fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 -rw=randread randwrite -runtime=60 -filename=/dev/sdX}}
«А почему так мало…» — см.ниже.
* Для SAS и NVMe включайте blk-mq (ну или юзайте свежие ядра, в районе 4.18 оно включается по умолчанию). Но для SATA blk-mq обычно бесполезен или почти бесполезен.
* Фактическая глубина очереди, используемая Ceph OSD при случайной записи, редко больше 10 (посмотреть можно при работе утилитой {{cmd|iostat -xmt 1}}).
== Процессоры ==
* На SSD Ceph ОЧЕНЬ СИЛЬНО упирается в процессор. Можно сказать, что процессор — основной bottleneck.
* Как сказано в презентации Ника Фиска — Ceph is a Software-Defined Storage '''and every piece of Ceph «Software»''' will run faster with every GHz of CPU frequency.
* Кроме частоты, на серверных процессорах часто наличествует NUMA (Non-Uniform Memory Access). То есть, часть памяти и оборудования доступна процессору напрямую, а часть — только через другой процессор.
* Для максимизации производительности конфигураций с NUMA лучше избегать, а процессорам с бОльшим числом ядер и меньшей частотой лучше предпочитать бОльшую частоту и меньшее число ядер…
* …но в пределах разумного, так как даже один OSD на серверном SSD под нагрузкой может спокойно выжрать на 100 % ядер 6.
* Под частотой подразумевается номинальная частота, а не Turbo Boost, так как оный актуален только для однопоточных нагрузок.
* Рекомендации по привязке OSD к отдельным CPU (taskset), можно сказать, неактуальны, так как Ceph OSD сильно многопоточные — при записи постоянно активно как минимум 4 потока, и ограничение их несколькими ядрами сильно урезает производительность.
* Есть два параметра, которые регулируют число рабочих потоков OSD — osd_op_num_shards и osd_op_num_threads_per_shard…
* …Но менять их бесполезно, поднять производительность таким образом не получается абсолютно, дефолтные значения (1x5 на HDD и 2x8 на SSD) оптимальны.
* Есть одна мера, которая помогает поднять производительность сразу раза в 2-3: отключение экономии энергии процессором:
** <tt>cpupower idle-set -D 1</tt> — отключает C-States (либо опции ядра processor.max_cstate=1 intel_idle.max_cstate=0)
** <tt>for i in {0..63}; do cpufreq-set -c $i -g performance; done</tt> (вместо 63 подставьте своё число ядер минус 1) — отключает снижение частоты через множитель
* После этих двух команд процессор начинает греться как ПЕЧ, но iops-ы увеличиваются сразу раза в 2 (а то и 3)
* Также жор CPU — одна из причин НЕ делать из Ceph «гиперконвергентное облако» (в котором совмещены узлы хранения и запуска виртуальных машин)
== Оценка производительности кластера ==
** Bluestore, видимо, за счёт параллелизма, выдаёт чуть больше iops-ов даже на SSD без конденсаторов, чем просто те же ssd могут выдать с fsync — я лично смог добиться от тестового пула на 3-х Intel SSDSC2KW256G8 8000 iops (случайная запись), хотя сами ssd с fsync выдают примерно 5500
** И обратно, даже если SSD мегабыстрая, цеф — это огромный оверхед, он жрёт проц и никаких 220000 iops из одной SSD не выжмет. См. ниже [[#Пример теста от Micron]] — там в суперкрутом сетапе у них вышло всего 8750 iops в пересчёте на 1 NVMe (но это у них без SPDK/DPDK).
* Правильное применение для всяких оптанов и супербыстрых NVMe этоМожно считать, видимо, журналы, но какое на практике увеличение что лимит iops-ов при добавлении условно оптана к тем же обычным серверным ssd — опять же, сходу не ясно.* Увеличение IOPSв пересчёте на одну SSD/NVMe находится на уровне ~10000-ов Ceph обычно сопровождается увеличением жора CPU15000. CPU нужны хорошие. :)** Примечание: лучше больше гигагерц, но меньше сокетов (Большой разницы между хорошей SATA SSD и возможно ядер, если они неравноправные)даже NVMe в цефе — нет.* Однопоточные IOPS-ы целиком и полностью зависят от задержекЕсли SATA SSD плохая — разница есть. Важно всё — диски, процессор, контроллер, сетевая карта, коммутатор, Infiniband и SPDK/DPDK по возможности. Да и сам Bluestore латентнее, чем Filestore… хотя:) плохим можно считать всё, что даёт меньше 20000 iops в один поток с другой стороны, разница — условных 280 или 350 iops на дисках, которые сами по себе могут на порядок-два больше, что, имхо, непринципиальноsync.* <s>Лайфхак для ускорения однопоточной нагрузки: mdadm RAID 0 из RBD-образов внутри самой виртуалки</s> — проверено, не работает.* Лайфхак для очень быстрых дисков: несколько OSD на одном дискедиске — работает, но ценой сильного увеличения жора CPU.* Гипотетический монстр производительности в вакууме: мощные процы, Intel NVMe, Infiniband или Intel сеть 25-40GbE+ Гбит/с или Infiniband, <s>SPDK/DPDK</s> (SPDK работает, но не даёт прироста, DPDK не работает вообще).
== Картина маслом «Тормозящий кэш» ==
Виртуалку, в которой тестировал — даже не перезапускал между тестами.
== Почему вообще Bluestore такой медленный? ==
== Пример теста от Micron ==
Пример самолётного сетапа от Micron с процами по полляма (2x Xeon Gold), 100-гбит сетью и 10x топовыми NVMe (с конденсаторами, ага) в каждом узле, 4 узла, репликация 2x: https://www.micron.com/resource-details/30c00464-e089-479c-8469-5ecb02cfe06f
Всего 350000 iops на запись в пике на весь кластер, при 100 % загрузке CPU. Казалось бы, довольно много, но если поделить 350000/40 osd — получится 8750 иопс на 1 osd. С учётом репликации на диски нагрузка двойная, выходит, 17500 иопс. Ок, журналы тоже удваивают нагрузку, итого — 35000 iops на запись смог выжать ceph из одной NVMe… которая сама по спеке может 260000 иопс в одиночку. Вот такой вот overhead.
Данных по задержкам в 1 поток нет (а было бы интересно узнать). UPD: Поправка: <s>в чём микрон неправ — они не использовали SPDK и DPDK. Есть большая вероятность, что в их случае выигрыш мог быть в несколько раз.</s> Нет, это бессмысленно.
== Модели ==
* Micron серий 5100/5200
* HGST SN260
* Intel P4500
https://docs.google.com/spreadsheets/d/1E9-eXjzsKboiCCX-0u0r5fAjjufLKayaut_FOPxYZjc
[[Category:Ceph]]
