Ребята, ахтунг. Может кто сталкивался. В кластере практически остановились операции записи, при отсутствии каких-то особых проблем. Чтение с RBD тома в показывает до 30k iops, на запись стремится к 0. inactive pg нет, с сетью проблем вроде тоже нет. Куда копать?
- Ну ты конечно же сделал ceph --admin-daemon /run/ceph/ceph-osd.0.asok dump_ops_in_flight и определил этап на котором тормозят операции? - ... - Как не сделал?!
Получилось, кластерная сеть была почти в коме, хотя связность была и пакеты бегали, iperf показывал до 10ГБит. Однако запись в пул стремилась к нулю. Короче вопрос скорее в телеграм канал по инфинибенду, чем по цефу)
Ну вот если бы посмотрел стату пр окоторую я тебе написал - то увидел бы долгие waiting for rw locks, долгие ожидания коммитов от дочерних OSD и одновременно быстрые коммиты самих слейвов, что в 99% случаев означает проблему в сети
Получилось, кластерная сеть была почти в коме, хотя связность была и пакеты бегали, iperf показывал до 10ГБит. Однако запись в пул стремилась к нулю. Короче вопрос скорее в телеграм канал по инфинибенду, чем по цефу)
Ну вот если бы посмотрел стату пр окоторую я тебе написал - то увидел бы долгие waiting for rw locks, долгие ожидания коммитов от дочерних OSD и одновременно быстрые коммиты самих слейвов, что в 99% случаев означает проблему в сети
народ, подскажите плз. Есть вывод команды ceph osd perf. Чем отличается commit latency и apply. Как я нагуглил, commit latency - время записи в журнал, а apply на девайс osd.. Но что-то не сходится, так как эти latency у меня равны (bluestore).
народ, подскажите плз. Есть вывод команды ceph osd perf. Чем отличается commit latency и apply. Как я нагуглил, commit latency - время записи в журнал, а apply на девайс osd.. Но что-то не сходится, так как эти latency у меня равны (bluestore).
Потому что это со времён filestore, на bluestore и должны быть равны