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

Ну смотри, я начинаю экспорт, secondary начинает прогибаться под нагрузкой...запросы начнут идти на primary?

если ты сделаешь readPrefrence: secondary — нет

Ну тогда у меня просто зависает secondary и на этом все...

хм

небось запросы без maxTimeMs, да?

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

небось запросы без maxTimeMs, да?

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

у них таймаут в час установлен?

Нет

или в полтора?

Я выключил вообще

:)

вобщем твоя проблема не в монге, а в том как у вас устроен экспорт

ну просто у нас был рост данных и я хз сколько экспорту нужно, сначала было 10 минут, потом стало 30, сейчас полтора часа

ну вот надо смотреть почему полтора часа

60 гигабайт за полтора часа — очень долго

курсор висит потому что я итерирую по объектам, делаю запросы на внешние API и сохраняю результаты, поэтому между итерациями может пройти по 5 минут...

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

11.3777777778 мегабайт в секунду

ммм

я очень люблю эту цифру

это что?

это ~100мбит

которые очень часто говорят о том, что клиент где-то ударился головой в сетевой интерфейс :)

ты к тому что я тупо сделал? :)

нет, это я к тому, что возможно проблема не в io

точнее не в дисковом io, а в сетевом

не ну EBS же по сети :)

сейчас у нас с4.xlarge

не думаю что у ebs полоса 100 мегабит

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

750

на EBS

судя по документации

для начала нужно убедиться что у тебя есть объективная картина происходящего на ноде

как на уровне ос, так и на уровне монги

я рекомендую prometheus + grafana

и туда https://github.com/y8/mongo_collection_exporter

с ноды собирать максимум метрик

там вроде клаудвотч экспортер есть

ок, поработаю над этим

а для начала есть какие-то простые утилиты чтобы собрать это все?

ну типа atop/htop?

толку от этого нет

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

в духе: в монге упали qps, в это же время полка после пика в сетевом io

хм, ну статистика по EBS у меня есть в принципе с AWS

но это не ОС конечно

нужно не только EBS, нужно видеть утилизацию основных ресурсов

по монге ясно...что-то надо прикрутить

CPU, RAM + RAM IO, DISK + DISK IO, NET + NET IO

а есть что-нибудь готовое по мониторингу с docker-compose например?

прометей и графана точно поднимаются из докера

а хотя да, как же засунуть в докер если оно мониторит систему...

а, хм

нормально засунуть

прикольно

потому что для сборки метрик с хоста всегда есть --privileged или --device

а для выгребания метрик из контейнеров три ведра решений

/me

Упс, тыкнулось случайно, извиняйте

Как можно ускорить update_one? Работает намного медленнее, чем insert_many(ordered=False)

Всего около 100 итераций в секунду с обновлением

Понятно, что запись должна быть быстрее, чем перезапись, но почему так критично?

Однажды получилось ускорить этот процесс до 7000 итераций в секунду, но я не знаю что сделал тогда. Монга как-то разогрелась.

Как можно ускорить update_one? Работает намного медленнее, чем insert_many(ordered=False)

Бампер вопрос, тоже интересно

а зачем отказываться от insert_many?

а, update_one лол

Потому что обновление и вставка две разные операции)

ну bulk_operations

там вроде копит по 1к операций и выполняет за раз

у меня upsert ы так работают

Насколько я помню, у меня просто тогда было 1 итерация за 10 секунд

Как раз по 1000

initialize_unordered_bulk_op

у тебя на чем код?

А вот unordered не делал вроде

если питон то вот initialize_unordered_bulk_op

У меня pymongo

и туда пишешь что хочешь, хочешь апдейты, хочет что угодно

ну вот

как раз оттуда

у меня тоже )

http://api.mongodb.com/python/current/examples/bulk.html

Но почему тогда он как-то сам мог разогнаться?) Я замечаю, что монга требует разогрева, первая операция всегда дольше последующих

Хотя занимает 50% озу для кэша

к примеру bulk = db.test.initialize_unordered_bulk_op() bulk.find({'_id': 4}).upsert().update({'$inc': {'j': 1}}) потом после того как накопил сколько нужно операций >>> try: ... bulk.execute() ... except BulkWriteError as bwe: ... pprint(bwe.details)

Но почему тогда он как-то сам мог разогнаться?) Я замечаю, что монга требует разогрева, первая операция всегда дольше последующих

хз, я не делал особых замеров, по докам если хочешь ускорить кучу операций - делай unordered bulk operations :)

Но insert_many на bulk работает

по поводу скорости наверняка прогревается

но все-равно unordered bulk будет быстрее имхо

я так понял оно все кеширует в памяти, потом по 1к скармливает монге и та уже как-то параллельно пишет, сама разбирается как ей лучше

@dd_bb подскажи пожалуйста, а если у меня будет 2 secondary ноды, и я укажу приоритет на чтение с secondary - оно будет напрягать ноды равномерно?

От клиента зависит

update конечно медленнее чем insert.

Для update сначала find надо сделать

Ну да, кстати, индексы же ускорят этот процесс