я все знаю

балансировка == не нужна

я ж говорю что долго

мне нужно разметить тыщу чанков хотя бы

и ещё раз

move _не нужен_

он нужен только для первых N чанков

дальше чанки уже на нужном шарде делить

чтоб избежать вообще балансировки

мув не нужен в моем случае только для четверти

4 ноды

для равномерности раскидал на 1000 чанков примерно

эти 100 чанков раскидываю по 4 нодам

ну вот теперь делаем 1) MinKey … 1/4, 1/4 .. 2/4, 2/4 … 3/4, 3/4 … MaxKey

2) Move MinKey … 1/4 => sh1, 1/4 .. 2/4 => sh2, , 2/4 … 3/4 => sh3, 3/4 … MaxKey => sh4

будет дикий перекос по нагрузке

3) и на sh1 делим чанк хоть на миллиард

задача начала на лету меняться :))))

т.е. надо не pre-split сделать

давай как обычно: начнём с проблемы

пробелма в том, что в 3.6 добавили охеренную опцию, которая дико тормозит процесс, и видимо еще чтото, т.к. moveChunk нулевого размера занимает не меньше полсекунды

нет, это не проблема

полсекунды это уже после выставленной опции в ноль

чо ты вообще делаешь?

и зачем?

хороший вопрос

с него и надо начинать

корень пробелмы прост диски обычные хдд и монга почемуто не успевает балансить данные. чанки размером в полгига мигрируют пару часов

в чанке +-200к доков

replication lag большой? delayed реплики есть?

т.е. ты хочешь за монгу поделить существущие чанки на куски и растащить их по шардам?

лага нет, нагрузка на диски в районе 10%, реплики полные дубли

т.е. ты хочешь за монгу поделить существущие чанки на куски и растащить их по шардам?

да

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

не успевает почему?

и какая монга?

не успевает почему?

почему == куда

кстати про 10% я наверн нагнал, это нужно отльно проверить, по графикам просто ест ькуда расти, да и iowait не превышает процентов 20 монга 4.0.6, онбволяли на прошлой неделе как раз расчитывая, на то что будет поулчше а вот почему не успевает особо не известно, в логах балансер пишет количество клонирваонных доков и просто наблюдая за счетчиком станвоится так печально что хочется все это самому сделать

а куда не успевает-то?

серваки точно такие же, сеть минимум гигабит

в пределах цода

а куда не успевает-то?

^

не понял вопроса? не успевает балансить чанки между нодами шардов

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

в какие рамки не укладывается балансировка?

в моем случае данные прибывают быстрее на одну ноду, чем успевает с нее раскидываться

т.е. возник перманентный перекос?

большой?

влияет на производительность?

на производительность не влияет, влияет на то что через месяц место кончится)

так, начинаем подбираться к реальной проблеме )))

запросы на секондарях делаете?

Нет

тогда можно попробовать поставить очень низкое значение orphanCleanupDelaySecs

и посмотреть что будет

а мув пустого чанка раньше занимал до десяти секунд, так что полсекунды это жочень жорошо

Выставил в ноль, собственно поэтому пресплит сделался для новой коллекции. Посмотреть как будет стандартный балансер с этим жить можно конечно попробовать, но чтото не думмю что с высоты пары часов будет както заметно изменение с 15 минут

Сейчас на 60 секундах, над будет запустить балансер поеаблюдать

orphanCleanupDelaySecs нужен чтоб чтения на secondary которые начались до миграции до конца своего выполнения видели чанк

потому что праймари в шарде ничо не знает про то что происходит на секондарях

если чтений с секондарей нет, то orphanCleanupDelaySecs можно поставить низехонько.

Before deleting the chunk during chunk migration, MongoDB waits for orphanCleanupDelaySecs or for in-progress queries involving the chunk to complete on the shard primary, whichever is longer. However, because the shard primary has no knowledge of in-progress queries run on the shard secondaries, queries that use the chunk but are run on secondaries may see documents disappear if these queries take longer than the time to complete the shard primary queries and the orphanCleanupDelaySecs.

т.е. проблема судя по всему в «waits for orphanCleanupDelaySecs OR for in-progress queries involving the chunk to complete on the shard primary, whichever is longer.»

судя по всему orphanCleanupDelaySecs is longer ;)

Ну да оно же 15 минут по дефолту

вообще moveChunk же не _waitsForDelete

по сему moveChunk должен быстрее работать

вообще такое поведение своейственно ситуациям когда чанк долго читают

есть ли у вас жирные долгие запросы, которые например ещё и броадкастом что-то тянут?

Ото всего избавился, остались запросы по одному спарсед индексу и по идшникам

Конечно то что индексы по ид уже в память не влазят наверняка аффектит, но горячий набор данных достаточно мал

Да вынеся все в одельную коллекцию на время и полностью убрав запросы именно к этой коллекции ничего не поменяло

вопрос не избавились или нет, а есть ли продолжительные по времени запросы

хм

интересно

а размер чанка дефолтный?

1гб

Как раз при перелеливке использую более гранулированный ключ

На один ключ часто бывает 250к доков по 1.5 кб

интересненько