yopp
Можно на коленке, включив slowms: 0 и читать system.profile через tailable cursor
A
За вивид спасибо - гляну
yopp
вивид дороже ньюрелика
A
Можно на коленке, включив slowms: 0 и читать system.profile через tailable cursor
Да, я так и собирался делать, но надеялся что есть что-то вроде человечьего профайлера с распределением частоты запросов.
A
Ладно, и на том спасибо 🙂
yopp
https://github.com/mrsarm/mongotail
yopp
и вот https://github.com/heewa/mongotime
yopp
но у mongotime кажется нет возможности показать запрос
yopp
и ещё такой момент: из запроса желательно отфильтровывать значения, оставляя только ключи.
очень часто бывает, что есть запросы, например «последние сообщения», которые не такие медленные чтоб попасть в профайлер, но их очень много и у них постоянно меняется ключ в запросе converstations.find({user_id: xyz}).sort({last_message_at: -1})
yopp
в таких запроса значения xyz или -1 лучше отбросить, ключи отсорировать и считать статистику по таким вот нормализованным отпечаткам, например сразу в нотации команд: {find: ‘conversations’, filter: {user_id: nil}, sort: {last_message_at: nil}}.
очень часто, такие запросы и надо оптимизировать
A
Ну вот в общем да. У меня сейчас затык в том, что инстанс (он один, не бейте ногами), фризится иногда. Профайлер показывает что медленных запросов нет. Значит либо проблема ниже с дисковым IO (это потом будем изучать), либо летит жирная пачка мелких и коротких запросов. И исходя из того, как работает приложение, которое базу использует, скорее второе чем первое
yopp
начните с https://www.percona.com/software/database-tools/percona-monitoring-and-management
yopp
а, туда и query analytics завезли
yopp
ну вот и решение :)
yopp
https://pmmdemo.percona.com/graph/d/1Xwy8CKmz/_pmm-query-analytics?from=now-12h&to=now&orgId=1&var-host=mongocnf1wt&queryID=adcdc4d03a8376dc3c71f9079b7c3df1&type=mongo
A
Оно еще и бесплатное, чтоли ?)
AstraSerg
начните с https://www.percona.com/software/database-tools/percona-monitoring-and-management
оооооооооооооо, сколько графичков!!! беру!!
yopp
проблема всех графиков в том, что они бесполезны без человека который их умеет читать
yopp
как кардиограмма
AstraSerg
A
А существуют какие-то "нормальные" значения для количества одновременных команд в монге?
yopp
нет
A
Понятно, что от железа зависит.
yopp
вам стоит начать с понимания что такое «фриз»
yopp
это очень абстрактный симптом
yopp
более того, который который может быть совершенно не связан с монгой.
например при включеном tls и достаточно частой аутентификации, в системе может закончится энтропия и хендшейк при установке соединения будет блокироваться до момента пока пул энтропии достаточно не наполнится, а это могут быть минуты
A
вам стоит начать с понимания что такое «фриз»
а вот я и пытаюсь понять.
api-сервер иногда залипает на минуты. Я по нему прошёлся профайлером - с ним всё в относительном порядке. Глянул после этого в бесплатный new relic - он говорит, что база отвечает очень долго в моменты залипания.
Вот теперь пытаюсь понять, что в такие моменты происходит с базой. Печаль в том, что это происходит в разное время и в разных местах.
Рабочие версии следующие:
- приложение иногда извлекает больше данных чем нужно, но быстрыми маленькими запросам по id. Однако в некоторых случаях их может быть очень много. Соответственно если это так, то хотелось бы увидеть, что в базу ушла условная тысяча запросов вот такого "сорта". Ну и соответственно обратно идти в приложение, и делать так, чтобы запросов было меньше. Сразу идти нельзя, потому что таких потенциальных мест довольно много, и все их не поправить за раз.
- что-то не так с дисковым IO. Такое уже было на амазоне у нас, но правда на инстансе поменьше. Но тогда всё было характерно видно на графиках. Сейчас - нет.
А tls для хендшейка с базой не используется - база с приложением на одном инстансе стоят.
yopp
собирайте метрики с инстанса и с сервера базы
yopp
смотрите что происходит в момент отказа
A
У вас репликасет?
Нет. Дело происходит на предрелизной платформе - там всё живёт в одном AWS инстансе
Constantin
Нет. Дело происходит на предрелизной платформе - там всё живёт в одном AWS инстансе
Я бы еще посмотрел на пул коннекшенов, иногда фризится на стороне приложения — когда пропускной способности открытых коннектоы не хватает.
A
начините с observability. это всё гадание на кофейной гуще, которое вас никуда не приведёт
Есть хороший гайд с чего начать?
A
Я бы еще посмотрел на пул коннекшенов, иногда фризится на стороне приложения — когда пропускной способности открытых коннектоы не хватает.
да по идее тоже нет. Но как правильно заметил yopp , без метрик это и в самом деле гадание на кофейной гущи.
yopp
задача сводится к установлению причинности. собираейте метрики об общем состоянии системы (диск, сеть, процессор, память), ждёте отказа. когда он случился изучаете как изменялись метрики до и после отказа
Andrey
Всем привет. Есть база данных base1. Нужно ее склонировать в рамках одного mongod instance в новую базу. Я правильно понял, мои действия запустить db.copyDatabase("base1","base1new") ? Или лучше использовать db.cloneDatabase? Что быстрее и безопаснее. База порядка 500Гб.
yopp
Всем привет. Есть база данных base1. Нужно ее склонировать в рамках одного mongod instance в новую базу. Я правильно понял, мои действия запустить db.copyDatabase("base1","base1new") ? Или лучше использовать db.cloneDatabase? Что быстрее и безопаснее. База порядка 500Гб.
Если вы можете остановить монгу на время, то самый быстрый способ через копирование файлов хранилища. Составляете список, создаёте новую базу, в ней пустые коллекции, через collStat составляете список файлов, останавливаете монгу и заменяете файлы новых коллекций копией файлов оригинальных коллекций.
Второй вариант mongodump и mongorestore. Запускаете на другом порту и через pipe делаете копию.
Если вы не можете остановить монгу и в базу продолжается запись, то у вас будут проблемы и в общем виде задачу будет очень сложно решить. Так как copy и clone во-первых не point-in-time а значит данные будут неконсистентные, во-вторых они ещё и блокируют операции с базой, что может привести к отказу в обслуживании
Andrey
Если я остановлю все что пишет в бд и запущу db.copydatabase это насколько долгий процесс? Допустим на 500гб? Или все зависит по ресурсам?
yopp
Зависит от ресурсов, да. Но будет долго
yopp
Долго == часы
yopp
Если у вас НЖМД может и сутки
Andrey
а есть способ проверить что в базу уже никто ничего не пишет? чтобы убедиться что можно копирование начинать. Сам только начал знакомится с монго
yopp
отобрать у всех пользователей права на запись
Vova
И в каких-то прекрасных апках без try..catch всё ляжет при попытке записи😂
Constantin
И в каких-то прекрасных апках без try..catch всё ляжет при попытке записи😂
Вы будете удивлены, но у некоторых микросервисов умышленно закладывается поведение вывалиться, если другой сервис (а СУБД — это всего-навсего сервис), от которого он зависит выслал отказ в обслуживании.
Gleb
Вы будете удивлены, но у некоторых микросервисов умышленно закладывается поведение вывалиться, если другой сервис (а СУБД — это всего-навсего сервис), от которого он зависит выслал отказ в обслуживании.
странно это звучит - если вы жыли в эпоху до контейнеров то просто отдайт 500, а там балансер сам отрубит уже обращение к сервису, а в 2018 году просто под с приложухой убьется после хелсчека или я так превартно слово «вывалиться» интерпретировал?
Constantin
странно это звучит - если вы жыли в эпоху до контейнеров то просто отдайт 500, а там балансер сам отрубит уже обращение к сервису, а в 2018 году просто под с приложухой убьется после хелсчека или я так превартно слово «вывалиться» интерпретировал?
Не все приложения укладывют в контейнеры в 2018 году.
Но принцип примерно как вы описали, разве что и так будет 500, если сервис упал, ему ничего отдавать не нужно.
Вместо него оркестровщик попробует поставить новый.
Gleb
ну ок согласен, я просто испытваю некую боль тк был знаком с разработчиками у которых софт просто в эксепшен падал навсегда
Constantin
ну ок согласен, я просто испытваю некую боль тк был знаком с разработчиками у которых софт просто в эксепшен падал навсегда
try/catch тоже может таить много опасностей. Поставить его в неверном месте, и вместо падения и перезапуска в «нормальном» режиме, можно получить сервис, часть которого работает, а другая ушла в себя. Получается сервис с софт-локом. Нежить одним словом, которая может отдавать некорректный результат.
Anonymous
Salom xamaga
Sm•ok
salam voram
Anonymous
Всем доброй ночи.
Вопрос.
Монго/Монгуз. Есть модель
const jobSchema = new mongoose.Schema ({
name: String,
result: {}
})
На определенном этапе в result прилетает ключ tweets который является массивом. Как после этого обновлять массив?
Как сделать unshift result.tweets в такой модели?
Constantin
Посмотрите на команду $pull, но вам нужен будет какой-то уникальный идентификатор внутри result.tweeets, чтобы делать это без костылей.
Anonymous
пулл же для удаления
Constantin
Тогда вам нужен $push
Anonymous
проблема в том что массив внутри объекта. я не доганаю как быть в таком случае? я знаю есть $push и тд. но как применить если массив внутри объекта?
Constantin
Просто в ключе полный путь укажите:
$push: { 'result.tweets': newTweet }
Чтобы сделать unshift, нужно вроде $position в 0:
$push: { 'result.tweets': { $position: 0, $each: [newTweet] } }
Anonymous
точно отработало! спасибо. а то я нестил по другому. еще вопрос, $unshift же тоже есть? а то $push в конец добавляет, а надо в началао
Constantin
точно отработало! спасибо. а то я нестил по другому. еще вопрос, $unshift же тоже есть? а то $push в конец добавляет, а надо в началао
https://docs.mongodb.com/manual/reference/operator/update/push/#push — вот тут все есть, $unshit нету, делается через $push. Написал выше как может срабоатать.
Anonymous
спс попробую осилить
Anonymous
а можно в массив добавить сразу 2 объекта? он что по одному добавляет?
Anonymous
как-то кажется неправильно дергать 2 раза бд
Constantin
Просто в ключе полный путь укажите:
$push: { 'result.tweets': newTweet }
Чтобы сделать unshift, нужно вроде $position в 0:
$push: { 'result.tweets': { $position: 0, $each: [newTweet] } }
Вы просто вставляете все элементы массива $each в указанную позицию $position, в $each можете положить столько, сколько нужно элементов вставить
Anonymous
+++ вам также!
уже что-то. это работает.
const update = await Job.findOneAndUpdate({name: jobName}, {$push: {"result.tweets": {$each: [...difference]}}}, {new: true})
теперь догнать бы как в начало пушить а не в конец
Anonymous
для эого надо sort и слайс?
Constantin
Constantin
$position
Constantin
Anonymous
точно увидел. прошу прощеняи пропустл. видимо тоже сплю уже
Anonymous
все работает как надо, спасибо еще раз!