yopp
В currentOp
yopp
Значит создался. Попробуйте сбросить кэш планировщика
yopp
https://docs.mongodb.com/manual/reference/method/PlanCache.clear/#PlanCache.clear
Viktar
Без изменения, ошибка воспроизводится
Viktar
Починилось. Гео поле должно быть на первом месте в индексе.
𝚂𝚑𝚞𝚔𝚑𝚊
𝚂𝚑𝚞𝚔𝚑𝚊
Viktar
Всем привет, нашёл в логе слоу квери
{
"c": "COMMAND",
"msg": "Slow query",
"attr": {
"type": "command",
"ns": "catalog.addressCatalog",
"command": {
"getMore": 3782244515638288166,
"collection": "addressCatalog",
"lsid": {
"id": {
"$uuid": "045882e8-ca04-4029-8878-0dc781a4f990"
}
},
"$db": "catalog"
},
"originatingCommand": {
"find": "addressCatalog",
"filter": {
"loc_mdb": {
"$near": {
"$geometry": {
"type": "Point",
"coordinates": [
-81.969772,
33.506252
],
"maxDistance": 200,
"spherical": true
}
}
}
},
"planSummary": "IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 },
IXSCAN { loc_mdb: "2dsphere", cityId: 1 }",
"keysExamined": 22291,
"docsExamined": 22161,
"storage": {
"data": {
"bytesRead": 1907097881,
"timeReadingMicros": 17993195
}
},
"protocol": "op_msg",
"durationMillis": 19723
}
}
неужели столько раз делается сканирование индекса?
Проблема у меня с гео запросами такая, что 62 гб памяти и 8 cpu съедается за пару минут. Потом монга стопается из за нехватки памяти
Viktar
какой размер индекса и сколько оперативы?
"indexSizes" : {
"_id_" : 1484193792,
"state_1" : 386150400,
"residentsCount_1" : 421351424,
"loc_mdb_2dsphere_cityId_1" : 1306357760
},
ОЗУ 64 Gb
Viktar
нагрузка серьёзная, я эти запросы в 50 потоков лью. Но загрузка по IO около 60%
Nick
эм, тогда ничего удивительного
Nick
ограничивайте область для уменьшения рабочего датасета
Viktar
не совсем понял. разбить коллекцию на части так?
Андрей
Монга умеет в качестве входящего условия выборки документов по полю взять файл со значениями этого поля? Последовательно его прочитать, сравнить...
Nick
не совсем понял. разбить коллекцию на части так?
у вас под выборку попадает 22к доков в том конкретном запросе - попробуйте уменьшить область поискать, чтобы меньше данных тянулось с дисков
Nick
а самих данных много? количество и общий размер
Nick
выборки прям по всем могу проходиться?
Viktar
Nick
Монга умеет в качестве входящего условия выборки документов по полю взять файл со значениями этого поля? Последовательно его прочитать, сравнить...
именно чтобы из файла сформировать запрос на выборку не видел, скорее всего над оскрипт ручками писать
Nick
С гео точно не знаю как лимиты будут работать, но попробуйте
Viktar
С гео точно не знаю как лимиты будут работать, но попробуйте
С памятью лимит помог, а вот со скоростью не сильно.
{
"msg": "Slow query",
"attr": {
"type": "command",
"ns": "catalog.addressCatalog",
"command": {
"find": "addressCatalog",
"filter": {
"loc_mdb": {
"$near": {
"$geometry": {
"type": "Point",
"coordinates": [
-153.629618,
64.724809
],
"maxDistance": 200,
"spherical": true
}
}
}
},
"limit": 50,
"lsid": {
"id": {
"$uuid": "20868712-7600-488d-8360-cc26e1e0e0b6"
}
},
"$db": "catalog",
"$readPreference": {
"mode": "primaryPreferred"
}
},
"planSummary": "GEO_NEAR_2DSPHERE { loc_mdb: \"2dsphere\", cityId: 1 }",
"keysExamined": 1706,
"docsExamined": 1701,
"storage": {
"data": {
"bytesRead": 119315156,
"timeReadingMicros": 1613168
}
},
"protocol": "op_msg",
"durationMillis": 1835
}
}
индекс стал сканироваться 1 раз по логу
Nick
"keysExamined": 1706,
"docsExamined": 1701,
"storage": {
"data": {
"bytesRead": 119315156,
"timeReadingMicros": 1613168
}
},
Nick
теперь 1.6секунды
Nick
лучше тех 18секунд что были)
Viktar
Viktar
по ио нагрузка не большая, а вот процессор на все 100 используется
Viktar
похоже он и является ботелнеком теперь
Viktar
теперь 1.6секунды
всё равно долго, 111 млн документов по 1.6 сек на каждый, получается очень долго
Nick
на каждый запрос, в последнем запрсое у вас всеравно обработано 1700 доков
Viktar
на каждый запрос, в последнем запрсое у вас всеравно обработано 1700 доков
да, но фетч делается только для 50
Viktar
я надеюсь))
Alexandr
Товарищи, подскажите как быть? Надо с работающего одинокого сервера перетащить на shardcluster примерно терабайт данных.
Alexandr
Пробовал mongodump | mongorestore, но не срабатывает. Отваливается периодически и все заново....
Viktar
Товарищи, подскажите как быть? Надо с работающего одинокого сервера перетащить на shardcluster примерно терабайт данных.
если можно сервер остановить, то можно скопировать папку с данными
Alexandr
И?..
Viktar
а потом её использовать на втором сервере
Alexandr
Копировать всё? Или только какие-то отдельные файлы?
Viktar
всё
Aleksey
Пробовал mongodump | mongorestore, но не срабатывает. Отваливается периодически и все заново....
может быть разобраться в причинах отвала?
Viktar
Копировать всё? Или только какие-то отдельные файлы?
с правами на папку с данными на втором сервере не забудте разообраться
Aleksey
это же не нормально что у вас рестор не работает, значит в случае аварии из бекапа не подняться
Alexandr
рестор работает
Alexandr
мы на сервере приемнике запускали дамп и дальше пайп в рестор
Alexandr
в какой-то момент дамп падает после выкачивания 7 - 15 гигов и соответственно всё остальное тоже
Aleksey
оу, а если не через пайп а дамп - рсинк - рестор ? или простой подобный непозволителен?
Viktar
дампить и ресторить террабайт данных очень долго, индексы потом делать и т.п. копировать проще
Aleksey
собрать этот сервер в шард кластер, добавить к нему дополнительные сервера. а потом задрейнить этот, после того как чанки утекут на другие?
Viktar
собрать этот сервер в шард кластер, добавить к нему дополнительные сервера. а потом задрейнить этот, после того как чанки утекут на другие?
тоже не самый быстрый вариант, с репликой тоже. у меня терабайт данных сейчас. Копирование самый быстрый вариант. занимает около 4 часов
Aleksey
Viktar
я вывожу один сервер из реплики, копирую его, догоняю апдейты и переключаю сервера в приложении, после собираю новую реплику
Alexandr
оу, а если не через пайп а дамп - рсинк - рестор ? или простой подобный непозволителен?
позволителен, но надо что-то понадежнее чем дамп терабайта по сети
Aleksey
а в чем ненадёжность дампа размером в терабайт?)
Aleksey
позволителен, но надо что-то понадежнее чем дамп терабайта по сети
терабайт это гзип дамп или чистые данные?
Alexandr
а в чем ненадёжность дампа размером в терабайт?)
очень долго и за это время может произойти обрав связи (на доли секунды -пользователи и не заметили бы), но дамп прерывается
Aleksey
позволителен, но надо что-то понадежнее чем дамп терабайта по сети
да и через пайп терабайта по сети - вот тут надежность под большим вопросом)
Alexandr
терабайт это гзип дамп или чистые данные?
они равны друг другу ибо там терабайт киношек....
Aleksey
собрать этот сервер в шард кластер, добавить к нему дополнительные сервера. а потом задрейнить этот, после того как чанки утекут на другие?
тогда подозреваю что наиболее безопасно просто создать шард кластер из этой ноды, ну в общем как тут писал
Alexandr
а в чем ненадёжность дампа размером в терабайт?)
Если бы локально сохранять этот дамп... А так - сделали дамп на удаленную машину, стали разворачивать, а оно не развернулось ибо где-то контрольная сумма оказалась не правильной. Значит пока лили - произошла какая-то ошибка
Aleksey
Если бы локально сохранять этот дамп... А так - сделали дамп на удаленную машину, стали разворачивать, а оно не развернулось ибо где-то контрольная сумма оказалась не правильной. Значит пока лили - произошла какая-то ошибка
я полагал что места для дампа локально достаточно, ошибался видимо
Alexandr
я полагал что места для дампа локально достаточно, ошибался видимо
нет. потому на шардинг и переезжаем
Alexandr
место заканчивается
Aleksey
тогда подозреваю что наиболее безопасно просто создать шард кластер из этой ноды, ну в общем как тут писал
а с этим вариком какие проблемы?
Alexandr
Итого: либо копировать каталог как есть, либо перезапустить старый сервер указав, что он теперь будет в replicaset, зайти на него, добавить ему новый в качестве реплики, дождаться синхронизации, сделать на старом stepdown, еще раз перезапустить убрав из конфига упоминание про replicaset, а на новом удалить реплику (новый сервер) из репликасета. Потом уже новому добавлять шарды. Так?
Alexandr
Кажется перекинуть каталог с терабайтом - быстрее будет...
Aleksey
Кажется перекинуть каталог с терабайтом - быстрее будет...
если вопрос именно скорости - перенос стейта всегда быстрейший вариант
еще быстрее только попросить винт с данными переткнуть в новый серв)
Alexandr
если вопрос именно скорости - перенос стейта всегда быстрейший вариант
еще быстрее только попросить винт с данными переткнуть в новый серв)
Дата-центры разные. Кажется даже в разных государствах...
Viktar
Дата-центры разные. Кажется даже в разных государствах...
если у одного провайдера, то можно договориться о переносе снепшотов
Viktar
мы так делали с диджитал ошен
Alexandr
Не, разные.
Alexandr
опять же снепшоты то откуда? Там железки выделенные...
Alexandr
Провайдер с них ничего не снимает
Aleksey
Дата-центры разные. Кажется даже в разных государствах...
ну и последняя идея)
это же файлы в gridfs? можно написать миграцию =)