А🐎
А то и быстрее
Size: a a a
2021 March 03
А🐎
Но платформа там ваще другая
D
да, вполне вероятно, что дело не в настройках
я не уверен что именно может вызывать фриз, может гуру подскажут :) я не сталкивался с такими симптомами
но на микс кластере (5 ссд х 1.92ТБ, 7 х механика 4ТБ) и с более слабыми процессорами 4214 тоже запускалось без фризов.
я не уверен что именно может вызывать фриз, может гуру подскажут :) я не сталкивался с такими симптомами
но на микс кластере (5 ссд х 1.92ТБ, 7 х механика 4ТБ) и с более слабыми процессорами 4214 тоже запускалось без фризов.
D
нюанс - у меня везде SAS, учитывая что у ОП кажется САТА - может быть именно полу-дуплекс и пропускная способность вызывают троттл
ПС
мне кажется при таких параметрах системы, и при таком количестве данных, 30 секундный фриз это не нормально.
вообще процесс пиринга я понимаю весьма поверхностно, вероятно Виталий мог бы более детально прокоментировать, но при синхронизации pg_log и при сравнении epoch и состояния групп, насколько я понимаю медленные диски не должны вызывать задержку (именно во время пирринга).
У вас пока 30 секунд фриз - что ceph -s пишет про PG?
вообще процесс пиринга я понимаю весьма поверхностно, вероятно Виталий мог бы более детально прокоментировать, но при синхронизации pg_log и при сравнении epoch и состояния групп, насколько я понимаю медленные диски не должны вызывать задержку (именно во время пирринга).
У вас пока 30 секунд фриз - что ceph -s пишет про PG?
cluster:
id: 1ba3f6f9-0848-439c-bc23-23aefd1124c9
health: HEALTH_WARN
clock skew detected on mon.ceph2.domain, mon.ceph3.domain
2 osds down
Reduced data availability: 599 pgs peering
Degraded data redundancy: 719754/2167023 objects degraded (33.214%), 875 pgs degraded, 936 pgs undersized
services:
mon: 3 daemons, quorum ceph1.domain,ceph2.domain,ceph3.domain (age 7s)
mgr: ceph1.domain(active, since 3s), standbys: ceph2.domain, ceph3.domain
osd: 54 osds: 52 up (since 136y), 54 in (since 136y)
rgw: 3 daemons active (ceph1.domain, ceph2.domain, ceph3.domain)
task status:
data:
pools: 10 pools, 1993 pgs
objects: 722.34k objects, 2.7 TiB
usage: 9.8 TiB used, 182 TiB / 192 TiB avail
pgs: 53.036% pgs not active
719754/2167023 objects degraded (33.214%)
1057 peering
875 active+undersized+degraded
61 active+undersized
io:
client: 342 KiB/s rd, 29 MiB/s wr, 42 op/s rd, 714 op/s wr
D
и кстати да уровни 1 10 100 ни разу не спасут от спиловера )))
вы молодой, горячий и куда-то спешите :)
перечитайте еще раз, пожалуйста, вдумчиво, о том как compaction работает. И от того как третий уровень в 100ГБ на разделе в 100ГБ может помочь от спилловера при размере базы свыше 30ГБ. Но если не интересно, не читайте!
перечитайте еще раз, пожалуйста, вдумчиво, о том как compaction работает. И от того как третий уровень в 100ГБ на разделе в 100ГБ может помочь от спилловера при размере базы свыше 30ГБ. Но если не интересно, не читайте!
D
За сим - всем приятного дня/вечера! командировка :)
ПС
может дело в clock skew?
D
54 in (since 136y) 😂
А🐎
может дело в clock skew?
Ясен хрен время важно для клустера
ПС
вообще странно что там время кривое..
After=network-online.target local-fs.target time-sync.target
А🐎
ntpd везде надо синхрить
ПС
так он и есть, видимо не успевает на момент загрузки засинкать
А🐎
Эмм... ШТО?
ПС
хотя в systemd after time-sync стоит.
А🐎
сравни время на нодах
ПС
время нормальное. Видимо в момент старта osd еще не нормальное. Я не думал что это может так влиять.. Пойду поищу какого хрена оно не успевает засинкать.
А🐎
for i in `cat nodeip`; do ssh $i 'ntpdate ntp2.stratum2.ru'; done
;-\
А🐎
время нормальное. Видимо в момент старта osd еще не нормальное. Я не думал что это может так влиять.. Пойду поищу какого хрена оно не успевает засинкать.
С чего ты решил что не успевает?
А🐎
сделай синк времени, перезапусти мониторы и мгр