Всем привет. Подскажите, пожалуйста, как убрать лишние сообщения в логах? Уже установил logLevel в 0, quiet тоже стоит. У меня множественные коннекты к БД и остался спам сообщения: mongod[25605]: 2018-07-25T14:38:00.709+0300 I NETWORK [conn1] received client metadata from 127.0.0.1:33528............. Как это убрать на фиг?

Всем привет. Подскажите, пожалуйста, как убрать лишние сообщения в логах? Уже установил logLevel в 0, quiet тоже стоит. У меня множественные коннекты к БД и остался спам сообщения: mongod[25605]: 2018-07-25T14:38:00.709+0300 I NETWORK [conn1] received client metadata from 127.0.0.1:33528............. Как это убрать на фиг?

Это вам в консоль сыпется?

Это вам в консоль сыпется?

Ну куда настрою, туда и сыпится. И в логфайл сыпалось, сейчас у меня journalctl используется, теперь туда (через syslog).

Ну куда настрою, туда и сыпится. И в логфайл сыпалось, сейчас у меня journalctl используется, теперь туда (через syslog).

Судя по I в сообщении - это уровень info, а тут https://docs.mongodb.com/manual/reference/method/db.setLogLevel/ пишут, что ниже него сделать нельзя

> Ну куда настрою, туда и сыпится Может в /dev/null настроите? Там и места побольше и IO жрать не будет :)

Да я это уже прочитал, и прямо, и задом наперёд. Поэтому и пишу. У меня в результате машина половину ресурсов тратит не на полезную работу, а на спам вот этого. Драйвер переписывать - тоже не айс идея.

Ну дело пахнет к /dev/null, но блин, у меня только что было ощущение, что можно делать прямо, красиво. Выводить всякие ошибки и ворнинги, читать их по утрам вместе со свежей прессой. Ан... нет. Опять через ж...

а не пробовали db.setLogLevel(-1, "network" ) ?

Дык -1 это использовать родительскую настройку. А родительская можетбыть только 0, -1 поставишь - не стартанёт.

Дык -1 это использовать родительскую настройку. А родительская можетбыть только 0, -1 поставишь - не стартанёт.

точно, увидел, извините

Ладно. Плюнул. Дефнул.

больше мыслей нет

Да я это уже прочитал, и прямо, и задом наперёд. Поэтому и пишу. У меня в результате машина половину ресурсов тратит не на полезную работу, а на спам вот этого. Драйвер переписывать - тоже не айс идея.

Эээ

Половина ресурсов на логи?

больше мыслей нет

Спасибо за попытку :)

Спасибо за попытку :)

юр велкам :)

Половина ресурсов на логи?

Это художественная гипербола, литературный приём для подчёркивания моего негодования. Ну на самом деле journal настроен у меня сейчас не писать логи на диск, только в памяти. Сейчас парсится на виртуалке база около 40 гигов, там парсится бэкэндом большой xml и распихивается всё в MongoDB. Ну так journal при обработке логов процессор жрёт неплохо, ибо идёт спам от монги.

Информация о подключениях не просто так остаётся в логах. Если у вас в логах много сообщений о подключениях, то скорее всего вам необходимо использовать connection pool

@GennadyKovalev Чёт как-то странно это....

Открытие соединения — дорогая операция, особенно если используется TLS

Открытие соединения — дорогая операция, особенно если используется TLS

Тогда не логи грузят систему, а открытие соединений и оптимизировать нужно в этом месте.

Про connection pool, про драйвера - это всё очень понятно. У меня вопрос не как убрать множественные коннекты, ибо это вопрос драйвера, а как убрать сообщения в логах. С драйвером мне всё понятно.

Про connection pool, про драйвера - это всё очень понятно. У меня вопрос не как убрать множественные коннекты, ибо это вопрос драйвера, а как убрать сообщения в логах. С драйвером мне всё понятно.

Никак и это намеренно.

Метрики говорят, что пока грузит обработка логов. У меня задача за неделю файл распарсить, переписыванием драйверов я не хочу сегодня заниматься :) Ну /dev/null спасёт мир.

Отключите обработку логов и пишите в файл. Даже на высоконагруженных кластерах логгирование это около одного-двух мегабайт в секунду

Зачем мне писать логи в файл и дополнительно грузить диск, если я это читать не буду?

Это sequential write, который в таких объёмах не является проблемой

Сделал: while true; do echo hellohellohellohellohellohellohello | systemd-cat; done получилось: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19771 root 20 0 27676 8248 3160 S 28.6 0.1 0:07.58 bash 265 root 20 0 41580 9516 7032 S 9.0 0.1 0:12.55 systemd-journal Не то что бы сильно много и это с записью в файл

Вот, пожалуйста, /dev/null и грузит только мой бэк и монга. Всё нормуль.

Моя мысль в том, что у вас проблемы не с самим фактом журналирования, а где-то на этапе обработки журнала. Если это продуктивная инсталляция, то лечить надо причину, а не симптом

@AstraSerg ну понятно, у меня покруче нагрузочка была. bash несколько медленее...

@AstraSerg ну понятно, у меня покруче нагрузочка была. bash несколько медленее...

Неужели количество установок соединений был больше чем echo в цикле? Жуть какая! Тогда вам точно нужно что-то делать с переиспользованием соединений, а то реально катострофа...

Моя мысль в том, что у вас проблемы не с самим фактом журналирования, а где-то на этапе обработки журнала. Если это продуктивная инсталляция, то лечить надо причину, а не симптом

Мысль ясна. Но первопричина всё-таки это а) множественные конекты - вопрос к драйверу, б) лишнее логгирование, которое мне не нужно.

Как я уже говорил: несколько мегабайт журнала в секунду (тысячи записей в журнал в секунду) , не должны являться проблемой. Если это является проблемой, это серьезный симптом

@AstraSerg ну я вчера залез в исходники драйвера... и как-то сник :) Если бы, как всегда, не срочность... Ну я сейчас обработаю свои 40 гигов с /dev/null, потом займысь выпрямлением количества коннектов.

@AstraSerg ну я вчера залез в исходники драйвера... и как-то сник :) Если бы, как всегда, не срочность... Ну я сейчас обработаю свои 40 гигов с /dev/null, потом займысь выпрямлением количества коннектов.

Вот и отлично.

Как я уже говорил: несколько мегабайт журнала в секунду (тысячи записей в журнал в секунду) , не должны являться проблемой. Если это является проблемой, это серьезный симптом

Да выша мысль-то понятна. По-умолчанию systemd-journald` использует временное хранилище, которое живёт на `tmpfs`. Настраивать это можно сколь угодно долго, но это теоретически упрется в ресурс. Либо дай диск для хранение объёма, либо настрой фильтр чего логировать, а чего нет - это процессор, либо дай оперативки для хранения, либо настрой стирание старых записей - это тоже процессор. В данном случае у меня упор ушёл в процессор. И то не упор, а просто увидел, что "поджирает...". Можно долго настраивать всякие rate limit и не собирать много сообщений от одой службы, но фокус вопроса не как обработать поток дряни, у меня вопроса тут нет. А почему вообще этот поток существует. С учётом того, что множественные соединения я прямо сегодня победить не могу, вот и задал вопрос как отключить поток всякого г... от монги. А то я может в читал доку и в упор чего-то не увидел. Ответ получил. Тоже никак. Ну значит срочняк решим с /dev/null, а лечить будем драйвер, а не обработку ненужного потока г...

> а лечить будем драйвер А что за язык, если не секрет?

Питон, c motor.

Питон, c motor.

Так pymongo жеж

motor - обёртка для pymongo для поддержки ассинхронности. Вернее для псевдоассинхронности.

motor - обёртка для pymongo для поддержки ассинхронности. Вернее для псевдоассинхронности.

Почему псевдо? Это ж под торнадо чтоб вызовы делать

Псевдо, потому что внутри motor создаёт пул тредов для запуска соединений с mongodb, а треды - это не асинхронность. В каждом треде живёт одно соединение. Асинхронного драйвера для mongodb в питоне нет.

Кстати, если кому интересно. Раскопал драйвер для python, вроде асинхронный по-настоящему: https://github.com/ZeoAlliance/aiomongo. Внутри посмотрел асинхронное соединение прямо с сервером и никаких тредов. Пишут, что сильно производительнее motor. Но его, особо никто не использует почему-то. И вялый проект какой-то. Странно...

Кстати, если кому интересно. Раскопал драйвер для python, вроде асинхронный по-настоящему: https://github.com/ZeoAlliance/aiomongo. Внутри посмотрел асинхронное соединение прямо с сервером и никаких тредов. Пишут, что сильно производительнее motor. Но его, особо никто не использует почему-то. И вялый проект какой-то. Странно...

Спасибо, может пригодится. 25 звёздочек - это норм, имхо.

Я тоже потестирую на досуге... По фичам вроде всё основное есть.

только вот Python 3.5.2 or later нужен. Не у всех есть...

Как можно понять, был ли документ изменен, добавлен, или документ вообще не изменялся при update?

Как можно понять, был ли документ изменен, добавлен, или документ вообще не изменялся при update?

После выполнения операции в консоль возвращается сколько документов изменено

но как я понимаю, если даже документ существует и в нем ничего не было изменено, он всеравно возвращает что документ изменен?

но как я понимаю, если даже документ существует и в нем ничего не было изменено, он всеравно возвращает что документ изменен?

нет, если не измененено он пишет, что изменено 0

вот пример: rs0:PRIMARY> db.stat_tmp.update({status: 8}, {x: 1}) WriteResult({ "nMatched" : 0, "nUpserted" : 0, "nModified" : 0 })

а у меня возвращает nModified: 1 даже если документ совпадает

а у меня возвращает nModified: 1 даже если документ совпадает

Верьте, значит изменён. Может тип данных поменялся

тип?

да нет, один и тот же код испольняю через nodejs, один и тот же обьект

тип?

да, поправил :)

да нет, один и тот же код испольняю через nodejs, один и тот же обьект

а документ большой? Попробуйте вместо update сделать find и посмотреть что с ним происходит

🤦‍♂️ сори, туплю, у меня там Date.now() в документе)

🤦‍♂️ сори, туплю, у меня там Date.now() в документе)

:) ну и хорошо, что разобрались :)

Привет всем!

Есть такой запрос http://dpaste.com/1K8VY4D . Он находит дату первого заказа для каждого пользователя. Теперь мне надо выбрать из заказов данные { id, is_first_order }. Это по сути $lookup, только для уже выбранных данных. Подскажите, как это сделать..

Есть такой запрос http://dpaste.com/1K8VY4D . Он находит дату первого заказа для каждого пользователя. Теперь мне надо выбрать из заказов данные { id, is_first_order }. Это по сути $lookup, только для уже выбранных данных. Подскажите, как это сделать..

Ну вообще, в агрегате вы можете сделать несколько лукапов. Вот ка здесь: https://stackoverflow.com/a/44153229/2733113

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

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

судя по as: 'users' в первом лукапе и далее foreignField: 'users._id' второй как раз на данных первого строится. Тут проще прпобовать

или в своем случае я могу сделать привязку 2 раза к таблицы orders, а потом просто сгруппировать нужные данные..

или в своем случае я могу сделать привязку 2 раза к таблицы orders, а потом просто сгруппировать нужные данные..

Да, пробуйте

Что-то вроде того - http://dpaste.com/2J91FZ5 и результат http://dpaste.com/2HKFD7A

Не знаю оптимально ли это, но тут по сути 2 запроса всего

Что-то вроде того - http://dpaste.com/2J91FZ5 и результат http://dpaste.com/2HKFD7A

Круть!

Спасибо за наводку)

пару часов просидел, думая

Не знаю оптимально ли это, но тут по сути 2 запроса всего

а объём данных какой? Если меньше миллиона, то и не заморачивайтесь

1000 где-то

пару часов просидел, думая

Взгляд со стороны всегда помогает :) на том и стоим :)

1000 где-то

1000 оно в памяти держать может даже без индексов

В конце еще добавлю { $group: { _id: { month: { $month: '$date_created', year: { $year: '$date_created' } } } и будет видна статистика returned и onetime покупателей по каждому месяцу

В конце еще добавлю { $group: { _id: { month: { $month: '$date_created', year: { $year: '$date_created' } } } и будет видна статистика returned и onetime покупателей по каждому месяцу

дело, сам статистику люблю!

с монго раньше не работал просто