13 521
правка
Изменения
м
Нет описания правки
* При тестировании случайной записи в ceph в один поток (fsync/fdatasync/sync/iodepth=1/rados bench -t 1) вы фактически всё время тестируете ОДИН диск. То есть, всё время тестируются разные диски, но в каждый отдельный момент времени запрос идёт '''только к одной placement group''' (тройке-четвёрке-пятёрке дисков).
* Соответственно, вы '''не увидите''' 100 % утилизации дисков на хостах при тестировании в один поток, однопоточная нагрузка '''не может''' полностью загрузить кластер.
Как тестировать производительность отдельных OSD:
* Создать pool без репликации {{Cmd|ceph osd pool create r1pool 128 replicated; ceph osd pool r1pool set size 1; ceph osd pool r1pool set min_size 1}} и с числом PG, достаточным, чтобы при случайном выборе туда попали все OSD
* Воспользоваться бенчилкой Марка https://github.com/socketpair/ceph-bench - команда вида: {{Cmd|python main.py --keyring /etc/ceph/ceph.client.admin.keyring r1pool osd}}
* Полученный результат — производительность '''отдельных''' OSD
== Производительность случайной записи ==
# Если запись крупная, то она сразу отправляется на диск. Потом Sync.))). и потом тоже обновляем метаданные. Sync.
И ещё всё это приправлено тредами, блокировками… Все мы знаем, что наиболее оптимальный способ написания любых i/o приложений — приложений — nginx-подобный — подобный — «one thread per core + zero-copy». А тут OSD при старте сразу создаёт ~50 потоков, из которых при записи постоянно активны как минимум 4.
То есть получается, что есть как бы журнал, есть данные и есть метаданные. И ещё если мелкие записи то есть очередь отложенной записи (в той же бд, но отдельная), её сначала надо писать, а потом сбрасывать и очищать. В итоге получается на 1 входящую транзакцию штук 5 реальных транзакций.
Итого WA = 4.16 (4926/1183), а sync-ов опять больше, чем запросов записи.
Теоретически 1 запись 4кб блока должна представляться как просто запись 4кб блока + обновление максимум одного сектора в журнале БД (обновление 1 блока в списке блоков объекта всяко не должно занимать больше 512 байт). Если бы так и было — было — WA было бы 1.125. Однако в Bluestore WA находится на уровне 3-5. Предположительные причины:
* отсутствие собственного механизма журналирования
* хранение блоков, занимаемых объектом, не в виде дерева extent-ов (как это обычно делается во всех файловых системах), а в виде одного-нескольких ключей в RocksDB
** С SPDK Ceph собирается и даже собран по умолчанию — но оно опять-таки не работает — вскоре после запуска OSD просто виснет в пространстве
** Code is there, так что, вероятно, всё это можно исправить, если подебажить подольше
* Однако, похоже, в силу неоптимальной реализации самого сетевого кода Ceph ни от DPDK, ни от RDMA ожидать ускорения не приходится - приходится — потому что один чувак недавно отрезал код AsyncMessenger-а от всего остального цефа и попробовал побенчить его отдельно: https://www.spinics.net/lists/ceph-devel/msg43555.html - и получил всего лишь ~80000 iops.
== Краткий экскурс в устройство SSD и флеш-памяти ==