yopp
но если вы не будете использовать оркестрацию и всякие хитрые стораджи, ничего не будет
Анатолий
ну так mongodb же пишет данные свои на диск, которые получается как раз как volume подключен
yopp
ну вот и прибейте эти вольюмы к контейнерам намертво
yopp
и не используйте оркестрации, третий раз говорю :)
yopp
все проблемы от попытки автоматизировать деплой
Анатолий
да нету у нас оркестрации, поэтому эту часть игнорю )
yopp
ну тогда с чего докер может похерить volumes?
Eugene
и не используйте оркестрации, третий раз говорю :)
а как оркестрация может сломать базу, поделитесь если не секрет, я просто не настраивал ее с монгой
yopp
самый простой вариант, перезапустить на другой ноде, где нет вольюма с данными
yopp
почистить вольюмы за упавшей нодой
Анатолий
я сам хз верить что докер может данные похерить или считать что это не приключится именно со мной
Анатолий
но какие-то багрепорты говорят были
yopp
говорят палка раз в год стреляет
Анатолий
всё на уровне "один знакомый рассказал что видел"
yopp
докер меняется с такой скоростью, что эти сказки они устаревают до того как становятся популярными
Анатолий
просто у нас ситуация - на одном сервере стоит mongodb и redis. и вот редис периодически не может памяти найти чтобы что-то там у себя сохранить - всё захапало mngodb
yopp
если вы не смонтируете сторадж и монга развернёт dbPath внутри контейнера, конечно вы поетряете данные когда контейнер пересоздастся
yopp
это не бага, это фича™
yopp
Анатолий
типа была идея вынести mongodb в контейнер - и тогда она не сможет захапать всю свободную память
yopp
вам надо или overcommit разрешить, чтоб редису хватало на CoW, либо памяти добавить
yopp
зачем?
Анатолий
мы уже добавили...
Анатолий
mongodb всё равно жрёт всё что есть
yopp
она жрёт половину от того что есть
yopp
и правильно делает
Анатолий
не правда
yopp
окей, половину плюс ещё на себя :)
Анатолий
в доке так и написано. мы мол возьмём половину RAM, а потом ещё всё остальное что свободное
yopp
нет, не правда
yopp
монга под кеш возьмёт половину памяти или сколько указано в конфиге и ещё столько, сколько нужно под различные задачи, типа сортировок, агреграций и прочих потребностей
yopp
дальше уже ваша ОС будет под кеш файловой системы использовать всю память.
yopp
ваша пробелма с редисом в том, что вы его вместе с монгой используете и не настроили overcommit и ему не дают сделать чекпоинт, потому что ему в этот момент надо виртуально выделить ещё столько памяти, сколько занимает датасет
Анатолий
The --wiredTigerCacheSizeGB limits the size of the WiredTiger internal cache. The operating system will use the available free memory for filesystem cache, which allows the compressed MongoDB data files to stay in memory. In addition, the operating system will use any free RAM to buffer file system blocks and file system cache.
yopp
ну
yopp
The operating system will use the available free memory for filesystem cache,
yopp
не монга, а ос
Анатолий
вот пока mongodb не перезапустишь - redis не может найти память
yopp
во-первых, вы себе создали проблему положив редис месте с монгой
Анатолий
Can't save in background: fork: Cannot allocate memory
[7480] 29 Jan 16:47:27.034 * 10 changes in 300 seconds. Saving...
yopp
во-вторых, вы сейчас придумываете оправдание неверным настройкам вашей ос
Анатолий
ну мы не знали что они не смогут память поделить
yopp
две базы данных на одной железке — к бурным половым приключениям
yopp
вообще, что-то кроме базы данных на железке, к приключениям
yopp
https://redis.io/topics/faq#background-saving-fails-with-a-fork-error-under-linux-even-if-i-have-a-lot-of-free-ram
yopp
хотя это не чат про редис
Ivan
yopp
хз ¯\_(ツ)_/¯
Іван 🤙
yopp
yopp
если монтировать, то туда, откуда данные случайно не удалят
Іван 🤙
на выбор, или монтировать в файловую систему или использовать docker volume https://docs.docker.com/storage/volumes/
Монтировать в систему это указывать volumes: в docker-compose.yml?
Или нет?
Eugene
Монтировать в систему это указывать volumes: в docker-compose.yml?
Или нет?
не совсем https://docs.docker.com/storage/bind-mounts/
Игорь
Вопрос, если я запросил данные через клиентский курсор и не считал их до конца(возможно крашнулся скрипт, сделавший запрос), данные так и остаются висеть в оперативной памяти? По умолчанию курсор вечный?
Evgeniy
помогите кто может, я немного отчаялся, запрос к базе сильно долго выполняется а если таких запросов много то база начинает тормозить сервер и все падает, памяти на сервере хватает 64 гига но вот процесора не хватает данных в двух коллекциях очень много под 80 гиг. Когда происходит агрегация с $lookup запрос тормозит, https://pastebin.com/aiaWVjpJ , подскажите может быть можно как то оптимизировать этот запрос с агрегацией ?
Nick
помогите кто может, я немного отчаялся, запрос к базе сильно долго выполняется а если таких запросов много то база начинает тормозить сервер и все падает, памяти на сервере хватает 64 гига но вот процесора не хватает данных в двух коллекциях очень много под 80 гиг. Когда происходит агрегация с $lookup запрос тормозит, https://pastebin.com/aiaWVjpJ , подскажите может быть можно как то оптимизировать этот запрос с агрегацией ?
Много сортировок и отсутвие фильтров - прямой путь к тормозам
Nick
Для начала ограничьте временной диапазон и добавьте индеес по нему
Evgeniy
да я забыл написать это вторая часть запроса, в первой части мы сортируем по полю с названием + добвляем фильтры по дате, индексы стоят на всех нужных полях без агрегации все работает быстро. Проблема в том что lookup тормозит весь процес, я выставил индекс на поля в другой таблице в которой идет lookup но ничего не произошло, запрос идет 5 минут а то и больше. А по поводу сортировок , я их убирал из запроса но скорости это не прибавило
Nick
да я забыл написать это вторая часть запроса, в первой части мы сортируем по полю с названием + добвляем фильтры по дате, индексы стоят на всех нужных полях без агрегации все работает быстро. Проблема в том что lookup тормозит весь процес, я выставил индекс на поля в другой таблице в которой идет lookup но ничего не произошло, запрос идет 5 минут а то и больше. А по поводу сортировок , я их убирал из запроса но скорости это не прибавило
у вас в лукапе используется $expr который не использует индексы
Evgeniy
хммм я ставил индексы на эти поля , помоему толку небыло , ок щас проверю еще раз , спасибо за совет
Nick
хммм я ставил индексы на эти поля , помоему толку небыло , ок щас проверю еще раз , спасибо за совет
он их не будет использовать даже если они есть
Іван 🤙
не совсем https://docs.docker.com/storage/bind-mounts/
ну, mounts - как я понял - сохраняет сразу в папку?
а volume поидее физически же должен где-то лежать?
или там спецом сделано так, что бы нельзя было ничего сделать?
(типо как защита)
Evgeniy
он их не будет использовать даже если они есть
а почему не будет использовать ? в чем проблема
Nick
https://docs.mongodb.com/manual/reference/operator/query/expr/#behavior
$expr does not support multikey indexes.
Evgeniy
а если я не использую мульти индексы ? я выставил индекс на отдельное поле , разве они не будут работать ?
Nick
тогда по идее должны
Nick
а если я не использую мульти индексы ? я выставил индекс на отдельное поле , разве они не будут работать ?
'$and': [{
'$eq': ['$news_id', '$$r_source_id']
}, {
'$eq': ['$index', '$$r_index']
}, {
'$eq': ['$doc_type', '$$r_doc_type']
}]
Nick
вот это как рах и хорошо бы покрыть индексом, но ка указано выше работать не будет
Nick
я правильно понимаю что первый лукап уже тормозит всю работу? .т.е если убрать все после
'$limit': 20
}, {
'$skip': 0
то будет все быстро?
Evgeniy
да именно
Evgeniy
но дело в том что этот лукап как бы нужен для логики всего эндпойнта без него эта вся работа не нужна как бы
Nick
но дело в том что этот лукап как бы нужен для логики всего эндпойнта без него эта вся работа не нужна как бы
а у вас всегда лимит на 20?
Nick
или это кастомная величина
Evgeniy
бывает на 50 и на 100 это сделано для максимального просмотра на странице
Evgeniy
по умолчанию 20
CherryTea
Или вы не про ci?
yopp
Про деплоий монги
yopp
Шедулить монгу в докере — к беде