да, похоже. Удивительно, что так много...

хотя 0.02%... наверное, я выпендриваюсь...

ага ))

Scaleway снял с эксплуатации свои ARM, мне нравились за 2 евро. Что-то у них не получилось.

Потому что армофилы издают много шума но приносят мало денег

Я не силён в этом.
Я просто сообщил факт, с которым столкнулся

Вместе с уже известным квадрантом по APM-решениям, Gartner также выкатил отчёт по критичным возможностям этих же решений. В этом отчёте те же самые участники квадранта APM сравниваются по следующим критериям:

⚡️ Business analysis
⚡️ IT services monitoring
⚡️ Root cause analysis
⚡️ Anomaly detection
⚡️ Distributed profiling
⚡️ Application debugging

в контексте их применения для следующих целей:

⚡️ IT operations
⚡️ DevOps release
⚡️ Application support
⚡️ Application development
⚡️ Application owner or line of business (LOB)
⚡️ CloudOps

Если вы сейчас выбираете APM-решение, это сравнение может быть полезным для формирования шорт-листа.

Приветстую всех! Коллеги, нужна ваша помощь, есть кластер 3 виртуалки, 3 osd, 3 mon, 1 radosgw, на каждой ноде 4 ядра E5-2630 v2, 16 gb ram, ssd, 10G сеть, osd на xfs по 500gb, в iowait виртуалки не уходят, пишется в кластер довольно редко и мало, после ресайза xfs на одной из нод начал падать на этой же ноде osd

ceph-osd[5927]: tcmalloc: large alloc 1677729792 bytes == 0x560fabf20000 @  0x7f79b074e1e1 0x7f79ae3c1499 0x7f79ae3c2833 0x560f0241f815 0x560f023ce6aa 0x560f023d5978 0x560f023d6be7 0x560f022f3e30 0x560f022f490a 0x560f02306c44 0x560f0230a
26b 0x560f0230a63d 0x560f026b4861 0x560f026b5960 0x7f79afa486ba 0x7f79adac041d (nil)

systemd его перезапускает и начинается долгое восстановление с заблокированными запросами

    health HEALTH_WARN
           1 pgs backfilling
           150 pgs degraded
           149 pgs recovery_wait
           150 pgs stuck degraded
           150 pgs stuck unclean
           1 pgs stuck undersized
           1 pgs undersized
           8 requests are blocked > 32 sec
           recovery 6490/3367710 objects degraded (0.193%)

в логе osd такие сообщение перед падением

2020-05-24 19:49:22.466684 7f79a2964700  1 heartbeat_map is_healthy 'OSD::osd_op_tp thread 0x7f792c7c1700' had timed out after 15.
сеть между osd стабильная, находятся на соседних серверах в стойке, не проседает.

гугление советует повысить значения таймаутов
https://ceph.io/planet/dealing-with-some-osd-timeouts/

Возможно подскажете куда копать? Заранее благодарен

ресайз ксфс - это как было?

стоп osd и mon, исключил из автозапуска osd и mon, стоп виртуалки, через virsh qemu добавил диск, после запуска виртуалки xfs_growfs /dev/vdb1, потом старт osd и mon

версия ceph - jewel 10.2.11

а, в виртуалке цеф живёт ... хм

kvm, ядра проброшены в виртуалки через pass-through

а мониторы все перезапущены были?

в последствии - да, после ресайза только там, где увеличивал диск

проблема всплывает спустя 2-3 дня стабильной работы

osd падает с
2020-05-24 21:16:11.305088 7fc6ab7fb700  1 heartbeat_map is_healthy 'FileStore::op_tp thread 0x7fc6a2e3a700' had suicide timed out after 180
common/HeartbeatMap.cc: 86: FAILED assert(0 == "hit suicide timeout")

где-то старые данные остались, походу

там, случайно, uuid не менялись?

у диска, раздела и т.п. ?