13 494
правки
Изменения
м
Ceph — это SDS, его задержки всегда выше, чем у устройств при прямом доступе, и от этого никуда не денешься. В интернете есть доклад Nick Fisk «Low-Latency Ceph», в его исполнении Low latency это 0.7ms, то есть на лучший результат рассчитывать особенно не приходится. 0.7ms — это всего лишь примерно ~1500 iops в 1 поток (хорошая новость — другие SDS и просто SAN-ы тоже тормозят :)).
Нет описания правки
[[en:Ceph performance]][[File:Ceph-funnel.svg|500px|right]]Ceph — это SDS (по-русски — программная СХД), которая по некоторым параметрам является уникальной в своём роде, и в целом, умеет очень многое — S3, диски виртуалок, CephFS + огромный багаж дополнительных фич. И всё было бы хорошо — бери, ставь, запускай своё облако и руби бабло — если бы не один маленький нюанс: ПРОИЗВОДИТЕЛЬНОСТЬ. Жечь 95 % ресурсов в Production-е разумным людям обычно жалко. «Облакам» типа AWS, GCP, Яндекса — не жалко — у них тоже собственные крафтовые SDS и они тоже тормозят примерно так же. Но этот вопрос оставим — кто мы такие, чтобы их судить. Причина в том, что локальные SSD сейчас ОЧЕНЬ быстрые (особенно NVMe). Порядок latency: 0.05ms. Догнать их SDS-ке крайне трудно (одна только сеть сожрёт те же 0.05ms), перегнать — наверное, вообще невозможно. В этой статье собран опыт о том, что (и почему) можно сделать с Ceph-ом, чтобы он стал побыстрее. Примерным ориентиром служит доклад Nick Fisk «Low-Latency Ceph», в его исполнении Low latency это 0.7ms; на лучший результат рассчитывать особенно не приходится. 0.7ms — это всего лишь примерно ~1500 iops в 1 поток.
== Бенчмаркинг ==
Задержки обычно важнее простой пиковой производительности случайного чтения/записи, так как далеко не каждое приложение может загрузить диск при большом параллелизме / глубокой очереди (32-128 запросов).
=== Тестирование дисков ===
