в данный момент ситуация такая, размер рабочей базы к которой идут запросы порядка 9 гб, но со временем работы она постепенно отжирает около 30 гб оперативной памяти и показывает, что всегда висит около 7-9 соединений даже когда активных скриптов нет и к базе, кроме меня через терминал ни кто не обращается

9Гб на диске?

мне помогла установка connectTimeoutMS

9Гб на диске?

База занимает 9, да

Это неверный метод оценки. Смотреть необходимо на collStats, на сумму size и indexSizes. https://docs.mongodb.com/manual/reference/command/collStats/#collStats.size

WT в кэше хранит некомпенсированные страницы

Если у вас хорошо сжимающиеся данные, на working set может потребоваться существенно больше памяти. По поводу «висящих» соединений. Используйте возможности маркировки курсоров https://docs.mongodb.com/manual/reference/method/cursor.comment/ Например, добавляйте туда точку вызова. Дальше через currentOp у вас будет возможность идентифицировать где в вашем приложении «текут» курсоры.

В остальном, если вы уже сталкивайтесь с нехваткой памяти, вам необходимо масштабироваться.

Даже если вы устраните текущие курсоры, это практически не повлияет на объём используемой памяти.

Если вас беспокоят цифры, то это повод перестать беспокоиться. Современные базы данных стараются максимально использовать оперативную память под свои нужды.

Внедрите средства контроля и следите за latency и количеством запросов по типу операций . Все остальные метрики имеют смысл только когда вы ищите проблемы, которые будут видны по росту latency.

я просто к тому, что при удельном весе всей базы в 9, оперативы в итоге уходит 29. Я правильно понимаю, что монго таким образом может кешировать запросы или какие-то еще операции?

я просто к тому, что при удельном весе всей базы в 9, оперативы в итоге уходит 29. Я правильно понимаю, что монго таким образом может кешировать запросы или какие-то еще операции?

«Вес базы» на диске — неинформативная метрика.

Она ничего не значит

я просто к тому, что при удельном весе всей базы в 9, оперативы в итоге уходит 29. Я правильно понимаю, что монго таким образом может кешировать запросы или какие-то еще операции?

скорллируй тогда - вес базы на диске 4 тб, а памяти тоже 29:D

ребяты, подскажите пожалуйста как в group: ... sum: '$column_name' приводить $column_name к числу?

Приводить к числу? Вы строки суммируете?

ребяты, подскажите пожалуйста как в group: ... sum: '$column_name' приводить $column_name к числу?

первая ссыль в гугле https://stackoverflow.com/questions/29487351/how-to-convert-string-to-numerical-values-in-mongodb :)

мне т конвертить в aggregation а не приводить к числу

Приводить к числу? Вы строки суммируете?

да, там строки и числа

но в строках числа

мне т конвертить в aggregation а не приводить к числу

это не понятно, поясните

у меня в бд есть значение value, где может быть строка или число (-1, 0, "1235) я сохраняю как есть код на рубях, но понятно должно быть .aggregate([{'$match': {id: 2234}}, {'$group': {_id: '$id', value: { '$sum': '$value'}}}]) (вообще надо последнюю запись выбрать, но пока хочу хотя бы со всеми сделать) хочу на выходе получить сумму всех value как число, не зависимо от типа value

Если монга 4 версии то можно использовать https://docs.mongodb.com/manual/reference/operator/aggregation/toInt/

Если монга 4 версии то можно использовать https://docs.mongodb.com/manual/reference/operator/aggregation/toInt/

Это вторая ссылка в гугле :))

а чего, как гуглил?

а чего, как гуглил?

https://www.google.com/search?newwindow=1&client=ubuntu&hs=Frg&channel=fs&q=mongodb+string+to+int&spell=1&sa=X&ved=0ahUKEwjy6_2jrdjcAhUEQpoKHdQODKIQBQgmKAA&biw=1080&bih=1817

хм, я думал в aggregation как-то по особенному

тэкс, оказалось что то что мне нужно это $last

слушайте, а какой порядок у полей по дефолту? .aggregate([{ '$match': { key: 2234 } }, { '$sort': { _id: -1 } }, { '$group': { _id: '$key', value: { '$first': '$value' } } }]) делаю так, всё ок, но очень медленно возвращается результат делаю так вот .aggregate([{'$match': {key: 2234}}, {'$group': {_id: '$key', value: { '$last': '$value'}}}]) очень быстро, но чёт смущает что может быть порядок не верный и как можно всю last строку вернуть, а не только одно поле?

тэкс, оказалось что то что мне нужно это $last

обратите внимание, что он имеет смысл только если отсортировано

отсортировано - значит sort в aggregation применен?

отсортировано - значит sort в aggregation применен?

да, конечно. Иначе порядок не гарантирован

а, вон как, а то у меня без сорта очень быстро проходит и результат даже одинаковый

чем с сортом

а как-нибудь sort можно ускорить? там sort по _id, я в монге новый человек, на _id по дефолту нет индекса?

> и как можно всю last строку вернуть, а не только одно поле? Для этого нужно в $group добавить все нужные поля

а как-нибудь sort можно ускорить? там sort по _id, я в монге новый человек, на _id по дефолту нет индекса?

Индекс есть, только прямой, попробуйте отсортировать '$sort': { _id: 1 } и взять не $last а $first

> и как можно всю last строку вернуть, а не только одно поле? Для этого нужно в $group добавить все нужные поля

грустно

грустно

Это ж логично. Чё грустить?

ну у меня есть отчеты по сессиям в монге для пользователей

мне бы хотелось взять для всех пользователей по последнему отчету

в принципе такое { '$sort': { created_at: -1 } } быстрее чем по _id

вот смотрите: у вас пользователь Вася, скажем. Записи о нём: Вася - 2018-06-06, Вася - 2018-06-07, 2018-06-08. Вы группируете по пользователю, значит первое поле будет Вася. А какую дату взять во второе поле? Максимальную? минимальную? Среднюю? Это за вас никто не решит

в принципе такое { '$sort': { created_at: -1 } } быстрее чем по _id

У вас какие индексы на коллекции? db.<имя коллекции>.getIndexes()

для сорта нужен индекс на поле

если большая база

сорт кстати по _id можно делать насколько я помню

для сорта нужен индекс на поле

Ага, можно конечно и без индекса, если ресурсов не жалко :) и порядок важен. Вот здесь можно почитать: https://docs.mongodb.com/manual/indexes/

монговский ид же тоже со временем

и можно его сортировать

сорт кстати по _id можно делать насколько я помню

так оно медленно в данном случае

10 сек против сотых

на created_at индекса нет

а сколько документов в коллекции?

261244

фигня

у меня вот щаз на одной коллекции не влезает результат

261244

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

мне больше интересно почему сорт по _id так медленно работает

и не будет ли тормозов когда добавлю индекс на created_at

мне больше интересно почему сорт по _id так медленно работает

Это нужно разобраться

и не будет ли тормозов когда добавлю индекс на created_at

Тормозов на чтение увеличиться не может. На запись - увеличится, но принебрежительно мало

а что реально сортировка по _id медленнее индекса по времени работает?

на поле времени нет индекса

на поле времени нет индекса

Сделайте

ну вот c { '$sort': { created_at: -1 } } - SUCCEEDED | 0.02214646s c { '$sort': { _id: -1 } } - SUCCEEDED | 10.304851694s

ну вот c { '$sort': { created_at: -1 } } - SUCCEEDED | 0.02214646s c { '$sort': { _id: -1 } } - SUCCEEDED | 10.304851694s

если -1, то индекс использоваться не будет. Проверьте с { '$sort': { _id: 1 } }

3 секунды

в среднем

но created_at даже без индекса быстрее _id

но created_at даже без индекса быстрее _id

Это странно... Можно попробовать поковырять explain https://docs.mongodb.com/manual/reference/operator/meta/explain/

может что-то проясниться...

ну кстати

добавил индекс на поле created_at и сорт начал тормозить

добавил индекс на поле created_at и сорт начал тормозить

Проверяйте explain

explain говорит что sort если на нем нет индекса вообще не участвует

explain говорит что sort если на нем нет индекса вообще не участвует

Вам нужно сделать такой индекс, который будет использоваться при сортировке. Важно, что бы совпадал набор полей, по которым будет сортировка и направление 1 или -1

ну я его делаю db.collection_name.createIndex({'created_at': 1}) добавляю потом в агрегацию { '$sort': { created_at: 1 } } и работает дольше на 3 сек чем без индекса

ну я его делаю db.collection_name.createIndex({'created_at': 1}) добавляю потом в агрегацию { '$sort': { created_at: 1 } } и работает дольше на 3 сек чем без индекса

Делаете всё правильно. Но результат не правильный :) А до сорта у вас какие стейджи?

стейджи?