D
Size: a a a
2020 May 27
D
но я пришел к выводу, что данные такие... "это норма"
AM
парты мержатся в определенном порядке, если парта нет из-за того что send выключен, мерж стоит и ждет пока парт скачается
о
а парты, получается, приписаны к нодам?
если такой-то парт на такой-то ноде, то он только оттуда будет качаться, если реплика в зк активна?
а парты, получается, приписаны к нодам?
если такой-то парт на такой-то ноде, то он только оттуда будет качаться, если реплика в зк активна?
AM
тут столкнулись еще с тем, что
при этом, сервер ни во что не упирается, диски утилизируются на 10%, проц 70% одного ядра, памяти ест вообще чуть
пока не поняли, из-за чего может быть так медленно
активных кусков у таблицы - 31, так что в 150 (параметр чего-то там delay) не упираемся
insert into ... select начался с 200 мб/с и через час стал около 30 мб/спри этом, сервер ни во что не упирается, диски утилизируются на 10%, проц 70% одного ядра, памяти ест вообще чуть
пока не поняли, из-за чего может быть так медленно
активных кусков у таблицы - 31, так что в 150 (параметр чего-то там delay) не упираемся
T
Может у вас стоит 1 поток в конфиге?
DC
о
а парты, получается, приписаны к нодам?
если такой-то парт на такой-то ноде, то он только оттуда будет качаться, если реплика в зк активна?
а парты, получается, приписаны к нодам?
если такой-то парт на такой-то ноде, то он только оттуда будет качаться, если реплика в зк активна?
вот у вас нода1. Там случился инсерт, вы там сделали send stop, она никуда этот парт-инсерт не рассылает. В зукипере есть инфомация про этот парт, нода 1 назначает мерж этого парта с другими, ноды 2 и 3 останавливают мержи потому что скачать парты не могут, случается too many parts
DC
тут столкнулись еще с тем, что
при этом, сервер ни во что не упирается, диски утилизируются на 10%, проц 70% одного ядра, памяти ест вообще чуть
пока не поняли, из-за чего может быть так медленно
активных кусков у таблицы - 31, так что в 150 (параметр чего-то там delay) не упираемся
insert into ... select начался с 200 мб/с и через час стал около 30 мб/спри этом, сервер ни во что не упирается, диски утилизируются на 10%, проц 70% одного ядра, памяти ест вообще чуть
пока не поняли, из-за чего может быть так медленно
активных кусков у таблицы - 31, так что в 150 (параметр чего-то там delay) не упираемся
там и должно быть, это все expected. Долго объяснять почему.
скорее всего поможет max_insert_threads=16
скорее всего поможет max_insert_threads=16
AM
вот у вас нода1. Там случился инсерт, вы там сделали send stop, она никуда этот парт-инсерт не рассылает. В зукипере есть инфомация про этот парт, нода 1 назначает мерж этого парта с другими, ноды 2 и 3 останавливают мержи потому что скачать парты не могут, случается too many parts
а, да, всё понял, спасибо!)
DC
я не верю, кто-то врет.
AM
там и должно быть, это все expected. Долго объяснять почему.
скорее всего поможет max_insert_threads=16
скорее всего поможет max_insert_threads=16
16 это просто фигура речи или про ядра?
и вообще, читал в доке про max_threads, замысловато
их можно оба просто в число ядер выставить и не думать? *_*
и вообще, читал в доке про max_threads, замысловато
их можно оба просто в число ядер выставить и не думать? *_*
DT
я не верю, кто-то врет.
дочитал до момента, когда после оптимайза парт еще жирнее стал?
DC
16 это просто фигура речи или про ядра?
и вообще, читал в доке про max_threads, замысловато
их можно оба просто в число ядер выставить и не думать? *_*
и вообще, читал в доке про max_threads, замысловато
их можно оба просто в число ядер выставить и не думать? *_*
доку прочитайте про max_insert_threads
без max_insert_threads инсерт однопоточный, и упирается в одно ядро на сортрировке парта
без max_insert_threads инсерт однопоточный, и упирается в одно ядро на сортрировке парта
AM
дада, я ее выставил в 6
DC
дочитал до момента, когда после оптимайза парт еще жирнее стал?
я не читал тред
AM
потому что там такой выставился max_threads
AM
оно с max_insert_threads=6 действительно стало быстрее намного
но просто через час деградировало, меня это и смутило)
но просто через час деградировало, меня это и смутило)
DC
я не читал тред
скорее всего кто-то ZSTD на LZ4 поменял
A
я не читал тред
Там самый прикол в том что после OPTIMIZE FINAL активные парты стали занимать сильно больше места.
До optimize final
202004 event_datetime 14949814777 13.90 GiB(сжатых) 55.69 GiB(разжатых)
После optmize final:
202004 event_datetime 14949814777 35.42 GiB(сжатых) 55.69 GiB(разжатых)
До optimize final
202004 event_datetime 14949814777 13.90 GiB(сжатых) 55.69 GiB(разжатых)
После optmize final:
202004 event_datetime 14949814777 35.42 GiB(сжатых) 55.69 GiB(разжатых)
A
скорее всего кто-то ZSTD на LZ4 поменял
я вот по этому и спрашивал про изменения между версиями, потому что руками 100% это не крутили и все по дефолту
DC
Там самый прикол в том что после OPTIMIZE FINAL активные парты стали занимать сильно больше места.
До optimize final
202004 event_datetime 14949814777 13.90 GiB(сжатых) 55.69 GiB(разжатых)
После optmize final:
202004 event_datetime 14949814777 35.42 GiB(сжатых) 55.69 GiB(разжатых)
До optimize final
202004 event_datetime 14949814777 13.90 GiB(сжатых) 55.69 GiB(разжатых)
После optmize final:
202004 event_datetime 14949814777 35.42 GiB(сжатых) 55.69 GiB(разжатых)
ну можно предположить что в партах хорошо жалось потому что лежали рядом одинаковые datetime, и после мержа стало больше места занимать, такое бывает, увеличивается в размере процентов на 5, но на 100% это слишком невероятно, это даже специально такое не сделать