yopp
fio это синтетика, она неинтересна
yopp
я рекомендую собрать больше данных, чтоб понять где именно возникло бутылочное горлышко
Max
она интересна и обязательна в предзапуске
не единожды было, когда 2 диска большого размера вели себя по-разному.
и даже сейчас такой сервер есть, но нагружен и проверить синтетикой я его не могу.
ближе всего планка, в которую упираюсь - это max bw на инстансе.
Max
в пиках это выглядит так
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvde 0.00 6.00 3310.00 6246.00 42.73 100.53 30.70 145.73 15.36 0.94 23.00 0.10 100.00
но опять же - это в пиках
Max
шикарное форматрование, эх
yopp
а какой эффект от этого всего? падает qps, latency увеличивается?
yopp
есть ли выявленные корреляции?
Max
а какой эффект от этого всего? падает qps, latency увеличивается?
растет очередь данных, которые должны уехать в монгу, плюс задержки с репликацией на secondary
Max
и я тут думаю, что если убрать на 40% данных в документе, то поток записываемых данных на диск тоже должен упасть.
и если поток уменьшится хотя бы на 10%, будет уже неплохо.
yopp
на мой взгляд, пришло время вписываться в шард
yopp
10% это совсем небольшой запас capacity
yopp
впрочем 150мб/с bw это не много. можно переехать на инстанс пожирнее
Max
на мой взгляд, пришло время вписываться в шард
active mongoses:
"3.6.10" : 102
"3.6.9" : 1
autosplit:
yopp
эм
yopp
тогда почему нагрузка на одну ноду?
Max
впрочем 150мб/с bw это не много. можно переехать на инстанс пожирнее
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html — тут же в топе 14k Mbps
Max
тогда почему нагрузка на одну ноду?
это праймари шард
что могли размазать по остальным - размазали
yopp
а что мешает размазать остальное?
Max
если правильно помню - не родили, как правильно шардировать без диких перекосов.
большие объемы данных - ну те, которые пишутся - они размазаны
но есть, видать, чтото еще :)
yopp
а уже точно известна коллекция которая к этому приводит?
Max
это соль на рану.
Да, бОльшая часть известна
точнее если просто сравнивать с другими шардами и потоком данных на них
yopp
я бы не данные пилил, а топологию кластера в этом случае
yopp
вам надо больше информации собрать, чтоб точно найти кто льёт такой поток
yopp
и этот поток поделить на несколько нод
Max
соль на рану.
но с идеей согласен.
yopp
не тратье время на оптимизацию данных
yopp
если у вас уже шард, то ищите какая коллекция его нагружает и какими запросами
Max
тут не оптимизация даже - тут выяснилось, что практически дебаг пишется.
куча инфы, которая нужна 1 раз в пару месяцев по требованию, и может быть включена-выключена при необходимости.
отсюда - данные эти будут удаляться в любом случае. И это, конечно, никак не исключает то, о чем вы говорите про распределение потока.
Nick
тут не оптимизация даже - тут выяснилось, что практически дебаг пишется.
куча инфы, которая нужна 1 раз в пару месяцев по требованию, и может быть включена-выключена при необходимости.
отсюда - данные эти будут удаляться в любом случае. И это, конечно, никак не исключает то, о чем вы говорите про распределение потока.
ощущение, что эта информация должна писаться не в базу а в логи на диски
yopp
чтоб было две проблемы :)
Nick
))))
yopp
тут не оптимизация даже - тут выяснилось, что практически дебаг пишется.
куча инфы, которая нужна 1 раз в пару месяцев по требованию, и может быть включена-выключена при необходимости.
отсюда - данные эти будут удаляться в любом случае. И это, конечно, никак не исключает то, о чем вы говорите про распределение потока.
соберите больше информации, у вас явно не хватает данных чтоб принимать решение
yopp
чистить данные это временное решение в любом случае. во-первых это будет долго, во вторых дорого
yopp
и вероятно ещё и больно
yopp
а самое главное, это не решит проблему, а только её отсрочит
yopp
так что это просто соженное время и деньги
Max
а самое главное, это не решит проблему, а только её отсрочит
это явно не решение проблемы - это чистка, ибо незачем хранить ненужный мусор. и вообще не ясно, зачем его сейчас пишут. как выяснилось.
Max
в остальном - всё так.
yopp
мусор это не причина, это просто триггер
yopp
причина — у вас что-то с шард-ключом
yopp
или с его отсутсвием ;)
Max
Totals
data : 33567.5GiB docs : 20634779427 chunks : 65537
Shard DSPRSv01 contains 33.33% data, 33.33% docs in cluster, avg obj size on shard : 1KiB
Shard DSPRSv02 contains 33.33% data, 33.33% docs in cluster, avg obj size on shard : 1KiB
Shard DSPRSv03 contains 33.33% data, 33.33% docs in cluster, avg obj size on shard : 1KiB
yopp
равномерное распредление данных не ваша проблема
yopp
ваша проблема равномерное распредление нагрузки :)
Max
в ней шард ключ не поможет.
что могли - растянули по шардам.
остальное пока не поддаётся.
но там архитектурных проблем очень много, они известны, тащемта.
yopp
шард ключ и поможет
yopp
но вообще, уберите тогда с праймари шарда шардированные коллекции
Max
но вообще, уберите тогда с праймари шарда шардированные коллекции
movechunk руками поделать и отключить на этих коллекциях балансировщик?
yopp
сделайте зону, запретите шардированным колелкциям жить на праймари и введите ещё один шард, чтоб туда ухеало шардированное
yopp
зонировать просто тегами можно, не добавляя тега на праймари
yopp
это самый дубовый способ снизить нагрузку на праймари сейчас
Max
да, тегам вы тоже в свое время научили :)
yopp
но сначала убедитесь что шардированные коллекции действительно создают нагрузку
yopp
ppm например воткните
Max
шардированные коллекции размазаны равномерно между тремя шардами.
на 2м и 3м шарде нагрузка +- одинаковая, что позволяет предположить, что эта же нагрузка включена и на primary шард.
вот надо будет обдумаь, чтобы вообще все с pri двинуть на два остальных.
интересно.
почцему эта мысль пришла в голову не мне?
аж стыдно
yopp
шардированные коллекции размазаны равномерно между тремя шардами.
на 2м и 3м шарде нагрузка +- одинаковая, что позволяет предположить, что эта же нагрузка включена и на primary шард.
вот надо будет обдумаь, чтобы вообще все с pri двинуть на два остальных.
интересно.
почцему эта мысль пришла в голову не мне?
аж стыдно
перед этим надо убедится что на двух остальных есть capacity чтоб туда 1/3 данных влезло
Veaceslav
Привет мужики, подскажите плиз как мне указать в аполло что я передам в переменую массив ?
Max
перед этим надо убедится что на двух остальных есть capacity чтоб туда 1/3 данных влезло
да, но там куча ресурсов для увеличения, и это не будет проблемой, 100%
Veaceslav
Пробовал Json!. Но не сработало.
Nick
да, но там куча ресурсов для увеличения, и это не будет проблемой, 100%
не забывайте что данные должны полностью мигрировать
yopp
ну недельку помигрирует и чо
Nick
ставлю на месяц
Nick
хотя может на нормальных дисках оно будет существенно быстрее
yopp
4 гигабита. ну тоесть секунд по 30 на чанк. 600 000 секунд или 167 часов
yopp
неделя :)
yopp
неделя-две
Max
оптимистичненько :)
yopp
опс спит, миграция идёт
Nick
хорошо когда диски хорошие)
yopp
16 мегабайт в секунду sequentual write не так и страшно
Nick
а разве чанки единым куском лежат?
Max
а потом через rangedeleter
yopp
соседние документы в проессе консолидации скорее всего будут на соседних страницах, но ето не точно
yopp
пушо сама коллекция адресуется по внутреннему id, а он последовательный и тут вероятно будет зависеть от того как документы в чанках раскладываются по стораджу
Nick
поэтому я прикидывал по иопсам, считая что на 300к доков может потребоваться 50к ио, чтобы их хотя бы вычитать