Изменения

Перейти к: навигация, поиск

Производительность Ceph

16 байтов добавлено, 20:17, 10 марта 2020
Нет описания правки
А что хуже? В целом, претензии сводятся к производительности:
* Гораздо хуже производительность случайной записи на SSD+HDD, SSD-раздел не работает как буфер для быстрой записи. Bluestore не пишет быстрее, чем может в среднем сам HDD. То есть, с SSD-журналом и Filestore будет 1000—2000 иопс случайной записи, а с Bluestore (и без bcache) — 200—300. 1000-20001000—2000, конечно, упадёт до 100 или даже ниже, когда у Filestore забьётся журнал и его придётся сбрасывать - сбрасывать — но тем не менее, "буфер" «буфер» для сглаживания пиков Filestore предоставляет. А Bluestore - Bluestore — нет.*: И проблема не только в том, что параметры по умолчанию — умолчанию — deferred_batch_ops и max_deferred_txc — max_deferred_txc — задают частый сброс операций на медленный диск (раз в 64 операции). Проблема ещё в том, что в Bluestore отсутствуют механизмы фоновой очистки «журнала» (очереди отложенной записи). Поэтому, когда очередь забивается, производительность просто падает до HDD-шной до перезапуска OSD. Ну и сама очередь находится в RocksDB, поэтому сильно поднимать её размер, по идее, неполезно.
* До 1.5-2 раз хуже latency случайной записи на SSD/NVMe, ибо накладных расходов на каждую операцию записи у Bluestore больше.
* Жор памяти больше. Да, у Filestore много занимал pagecache, но Bluestore меньше 2 ГБ памяти не жрёт вообще никогда. Причиной тому - тому — RocksDB (одни только memtable-ы с дефолтными настройками съедают 1 ГБ памяти) и собственный кэш метаданных и данных (Bluestore не может использовать pagecache).
* Фрагментация приводит к снижению скорости чтения.
Также BlueStore делает огромное количество fsync-ов (что очень смешно — смешно — даже больше, чем запросов записи), из-за чего не терпит десктопных SSD под журналом. Но FileStore работает похоже, и кардинальных различий производительности это не вносит.
Как полечить высокие задержки на SSD+HDD?

Навигация