yopp
у вас стоит socketTimeoutMS: 30000,
yopp
это 30 секунд
yopp
вы там писали что у вас есть скрипт который пинает лямбды раз в 15 минут. 15 минут > 30 секунд
yopp
https://github.com/Automattic/mongoose/issues/5849#issuecomment-363942588
yopp
ну вобщем-то да
yopp
conn = yield mongoose.createConnection(uri, { useMongoClient: true });
conn.model('Test', new mongoose.Schema({ name: String }));
yopp
они тоже мемоизируют соединение, но там обсуждают вопрос что readyState не сразу обновляется
Pavel
Привет, куда можно глянуть кроме sysloga и лога монги, что бы узнать почему она убивается со статусом 9/KILL? В логе проскакивало что-то типа slow perfomance(удалял лог некоторое время назад, точно не помню и нагуглить не получилось)
следов oom-killer'а в /var/log grep'ом не нашел
Началось примерно одновременно с тем как на этом сервере подняли вордпресс с апачем и mysql + парсер на ноде.
Но после отключение всех установленных в последнее время приложений, кроме монги и сайта ее использующей она продолжила умирать.
Вообщем, в какую сторону можно посмотреть?
**~# mongod --version**
db version v3.2.20
git version: a7a144f40b70bfe290906eb33ff2714933544af8
OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
allocator: tcmalloc
modules: none
build environment:
distmod: ubuntu1604
distarch: x86_64
target_arch: x86_64
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial
ОЗУ 2ГБ
yopp
2гб памяти мало
yopp
вынести монгу на отдельный сервер
Max
они тоже мемоизируют соединение, но там обсуждают вопрос что readyState не сразу обновляется
сорри, только сейчас увидел месседжи
Pavel
вынести монгу на отдельный сервер
спс за наводку, пойду разведывать
с моими текущими знаниями об оом кажется странным, что он БД выбирает
yopp
кто памяти просит, того и убивают :)
Max
читаю тот тикет
Max
бл... дак а как конекшен стейт проверять если он апдейтится не сразу?
yopp
либо увеличить интервал когда у вас лямбды прогреваются, до минуты например
yopp
либо увеличить таймаут до интервала прогрева
yopp
но таймут может быть и со стороны сервера
Max
yopp а если в пуле будет больше 1-го конекшена - они единомоментно закроются по истечению таймаута?
yopp
вопрос в понте к монгусу, который некорректно работает в подобных окружениях
yopp
я рекомендую попробовать сделать как в том тикете: установить соединение, сохранить его вне контекста хендлера и посмотреть что будет
yopp
судя по тому что тикет не обновлялся, возможно это работает
yopp
Раз в минуту если дергать, то 60*24*30*53 = 2 289 600. Пусть у вас там 512мб на лямбду, это по 0.000000834 за 100мс + $0.0000002 за вызов. итого 2.3674464$ в месяц
yopp
впрочем я бы дергал раз в пять минут и поставил бы таймут сокета в 10 минут
yopp
а там как таймеры работают между вызовами хендлеров? никак?
Max
впрочем я бы дергал раз в пять минут и поставил бы таймут сокета в 10 минут
стоп - дак мы ж лямбду будем дёргать, не монгу. там конекшен по идее всё равно отвалится
yopp
вам внутри лямбды надл дергать монгу
yopp
т.е. нода фактически саспендится когда не выполняется хендлер?
yopp
если сделать таймер внутри процесса, он не сработает?
yopp
в этом то и есть проблема: драйвер обычно пингует сервер в фоне, даже если запросов нет
Max
если сделать таймер внутри процесса, он не сработает?
ну если контейнер в котом крутится лямбда погаснет, то да, не сработает
yopp
ловите исключения с таймаутами и делайте retry
yopp
либо постоянно пинайте ваши лямбды, с каким-то агрументом типа ping, который будет дергать монгу. например делать isMaster
yopp
раз в минуту
yopp
или раз в 5 минут
yopp
не забудьте поднять socketTimeout
Max
или раз в 5 минут
ну раз в 5 минут - это норм, пинать лямбды не проблема - есть serverless-warm-up плагин.
yopp
не меньше чем интервал между прогревами лямбд
Max
не меньше чем интервал между прогревами лямбд
понял, спасибо, попробую -
конченый стек, убогий монгуз, какие-то сырые лямбды... ещё и руки кривые...
yopp
это лямбды
yopp
вы хотели дешево и безболезненно. так не бывает :)
yopp
копеечная стоимость лямбд берётся не из кармана безоса, а из того что вам продают процессорное время. если вы за него не платите, ваш процесс не работает
Max
вы хотели дешево и безболезненно. так не бывает :)
неее, я нифига не хотел) я топил за еластик бинсток как мог)
заказчик упёрся рогом - хочу скалебел
Max
я правда долго пытался уламать
Max
хорошо хоть админку писали под сервер - изначально нам предложили делать на лямбдах
ᅠ ᅠ ᅠ ᅠ
ребят, а можно с помощью Compass подгрузить локальную бд, а не к облачной грузиться?
ᅠ ᅠ ᅠ ᅠ
через консоль и оболочку пробовал - гибче, а вот Compass еще нет
Nick
что мешает попробовать?
Max
There seem to not be any limitations on our end for these that I am aware of.
ответ касательно запроса - нету у них лимитейшенов на socketTimeoutMS
Alex
Pavel
99% что это OOM
А если я записал в oom_score_adj -17, oom_score стал 0, а через 10 минут монгу кто-то кильнул? Еще раз попробую
Lev
Добрый день! Получаю такую ошибку, когда делаю Bulk.Run()
Lev
BSONObj size: 22298654 (0x154401E) is invalid. Size must be between 0 and 16793600(16MB) First element: insert: "action_traces"
Lev
Может ли это быть связанным с, например, огромным размером bulk-а? (сейчас Bulk-и по 25000 больших документов)
Pavel
Pavel
@martelev
Lev
Т.е. проблема в слишком большом размере запроса?
yopp
вероятно проблема в вашем дравере
yopp
если у вас монга до 3.6 то лимит на один bulk батч тысяча документов
yopp
в 3.6 лимит подняли до ста тысяч
Lev
у меня > 3.6
yopp
разбейте на более мелкие батчи
Lev
(+ 12 миллионов документов таким образом уже влетели, проблемы начались только сейчас)
Lev
попробую
yopp
ваш драйвер не оценивает размер складываемых в буффер документов и не разбивает большой батч на более мелкие, котоые влазят в документ
yopp
потому что wire protocol монги построен на базе bson документов и как следствие размер одного батча не может быть больше 16Мб
Lev
спасибо
Anonymous
Подскажите, в монгус как написать хук, чтоб поле апдейтилось при каждом обновлении и сохранении? типа лога изменений документа.