Если read into постоянно растёт, то working set скорее всего не умещается в память

Если ещё и растёт written from то значит insert/update операции выстесняют

Если растёт только pages requested from cache значит только данные не помещаются

Ну тем не менее, боттлнек тут где может быть, как по мне 4ЦПУ маловато

как по мне

48гб для монги вполне себе

В первую очередь нужно найти откуда ноги

LA вероятнее всего это или следствие компрессии или следствие cpu intensive computations

Или какой-то побочный эффект

Плюс у вас монга в гипервизоре, с зарезанным количеством ядер и это неудачная идея

Хм... Спасибо)

Но вы продолжаете искать проблемы без метрик

Это тупиковый путь

да я понимаю, но с этим затык

у нас заббикс

Бессмысленно пытаться что-то делать не имея объективной картины происходящего

а там темплейты дерьмо

так что у нас метрики из *** и палок)

Практически гарантированно вы примчите неверное решение без достаточного количества информации

Есть PPM

Задеплоить PPM будет всяко дешевле чем налить железа, которое может и не помочь особо

Спасибо. Подумаем

@dd_bb Еще вопрос Если у нас 48гб ОЗУ и монга использует только +- половину для кэша, можно ли "заставить" монгу использовать бльще своего внутреннего лимита?

Это не имеет смысла и скорее усугубит проблему

Втора вполовина памяти используется под дисковый кеш

Получается, если у нас монга упирается в РАМ (кэш) она начинает иджектить данные на диск за счет ЦПУ И чтоб нам поднять кэш нам надо поднять РАМ, верно?

Компрессия в WT работает таким образом, что в кеше хранятся несжатые страницы и сжимаются они только при сбросе на диск. Выделив больше памяти для кеша, количество сжатых страниц в дисковом кеше уменьшится и в итоге в памяти будет меньше данных

Получается, если у нас монга упирается в РАМ (кэш) она начинает иджектить данные на диск за счет ЦПУ И чтоб нам поднять кэш нам надо поднять РАМ, верно?

Не могу ничего сказать, у меня нет никаких объективных данных чтоб даже гипотезы строить, не говоря уже о решениях

понял) спасибо

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

как то можно при создании документа выставлять число на единицу больше максимального числа из существующих документов? Например , есть документы {id: 2, order: 10} {id: 1, order: 14} {id: 3, order: 53} и когда я вставлю новый документ автоматически вставилось число {id: 4, order: 54}

как то можно при создании документа выставлять число на единицу больше максимального числа из существующих документов? Например , есть документы {id: 2, order: 10} {id: 1, order: 14} {id: 3, order: 53} и когда я вставлю новый документ автоматически вставилось число {id: 4, order: 54}

Этого не стоит делать

Этого не стоит делать

Как тогда упорядочивание делать?

надо же автоматически выставить order поле

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

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

Как тогда упорядочивание делать?

На клиенте назначать порядок и его сохранять

Если в нужен порядок для большого числа документов, то positional math внутри транзакции и механизм разрешения конфликтов

Большое число это тысячи где-то

Спасибо, тарифов всего до 5-7 будет

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

разобрался, если кому-то интересно, то можно сделать через $split + $concat

коллеги пытаюсь запустить транзакцию с шелла не получается session = db.getMongo().startSession() 2020-03-26T15:12:05.194+0100 E QUERY [thread1] TypeError: db.getMongo(...).startSession is not a function : @(shell):1:11 в чем может быть проблема

источник - https://habr.com/ru/post/417131/

коллеги пытаюсь запустить транзакцию с шелла не получается session = db.getMongo().startSession() 2020-03-26T15:12:05.194+0100 E QUERY [thread1] TypeError: db.getMongo(...).startSession is not a function : @(shell):1:11 в чем может быть проблема

Это не официальная документация, для нестабильной версии. официальная вот: https://docs.mongodb.com/manual/reference/method/Session.startTransaction/

Привет. Немного тривиальный вопрос, возможно, уже обсуждавшийся. Есть коллекция, в которой есть два поля с одинаковым типом( время ). Назовем их f1 и f2 Хочется получать данные из коллекции отсортированными по такому условию, выражаясь на языке sql: coalesce(f1,f2). Не могу понять, как это правильно сделать в MongoDB Нашел оператор $ifNull для пайплайнов, но не смог подружить его с индексами, работает очень медленно. Создавал индексы по кажому из полей. Пока вижу только вариант явно создать дополнительное поле f3 = $ifNull(f1,f2) и по нему сделать дополнительный индекс. Но все же не хотелось бы заводить дополнительных полей. Подскажите, собственно, какое традиционное решение такой задачи? Спасибо.

Доброго, подскажите пожалуйста, если ли возможность организовать выборку из коллекции следующим образом: Допустим есть массив данных ['a', 'b', 'c'] в базе есть записи {value: 'a'} {value: 'b'} Я хочу, чтобы выборка из базы мне вернула данные, которых в базе нет, то есть результатом выборки должно быть ['c']

Доброго, подскажите пожалуйста, если ли возможность организовать выборку из коллекции следующим образом: Допустим есть массив данных ['a', 'b', 'c'] в базе есть записи {value: 'a'} {value: 'b'} Я хочу, чтобы выборка из базы мне вернула данные, которых в базе нет, то есть результатом выборки должно быть ['c']

Постановка вопроса конечно адовая "вернула данные, которых в базе нет" ))) но подозреваю что нужно $exists

Постановка вопроса конечно адовая "вернула данные, которых в базе нет" ))) но подозреваю что нужно $exists

ну дык, как есть так и описал)

ну дык, как есть так и описал)

как можно вернуть данные которых нет?

как можно вернуть данные которых нет?

$exists проверяет ключи, а мне нужны значения, а как можно.. вот хз как, этих данных могут быть десятки и сотни тысяч, не хотелось бы проверять каждую запись на наличие, а получить сразу список несуществующих

по вашему вопросу в базе два документа только? {value: 'a'} {value: 'b'} а какой документ вы хотите получить?

$exists проверяет ключи, а мне нужны значения, а как можно.. вот хз как, этих данных могут быть десятки и сотни тысяч, не хотелось бы проверять каждую запись на наличие, а получить сразу список несуществующих

А зачем вам по одной проверять. Получите все из базы и обойдите через for элементы в приложение

список несуществующих документов? 😂

Это вам будет дешевле чем городить адову логику на стороне субд

А зачем вам по одной проверять. Получите все из базы и обойдите через for элементы в приложение

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

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

distinct значений в базе берите и узнаете каких значений там нет(ключ под индекс естественно, а то долго будет)

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

хорошо, задача: прилетает на проверку 20к значений (неважно от куда), в базе уже есть 19995 значений из тех, которые прилетели на проверку (всего в базе 300к значений), нет только 5-ти значений (5-ти это условно, может быть и 10 и 20 и 1000), нужно определить каких значений нет и записать их в базу

хорошо, задача: прилетает на проверку 20к значений (неважно от куда), в базе уже есть 19995 значений из тех, которые прилетели на проверку (всего в базе 300к значений), нет только 5-ти значений (5-ти это условно, может быть и 10 и 20 и 1000), нужно определить каких значений нет и записать их в базу

Что нужно сделать дальше с теми значениями, которые вы определили как уникальные?

Что нужно сделать дальше с теми значениями, которые вы определили как уникальные?

записать их в базу

записать их в базу

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

И сразу вставляйте записи

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

и что тогда предлагаете через insertMany все 20к вставлять?

пытаться вставить вернее

А почему нет, с ордеред фалсе

Я потому и стал уточнять)

Нормально делаю сотировку или жопа?

я думал по контексту это и так понятно

Нормально делаю сотировку или жопа?

Вроде норм с виду

я думал по контексту это и так понятно

нет, это не очевидно

Вроде норм с виду

а то что я не асинхронно ищу и обновляю документы?

а то что я не асинхронно ищу и обновляю документы?

Я node не знаю) с виду по мне норм)

С точки зрения самого запроса к монге

ааа

А почему нет, с ордеред фалсе

Тогда добавлю условие, мне нужно сделать эту запись в 2 коллекции, через транзакцию, и такой вариант уже не катит

Тогда добавлю условие, мне нужно сделать эту запись в 2 коллекции, через транзакцию, и такой вариант уже не катит

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

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

хорошо, задача: прилетает на проверку 20к значений (неважно от куда), в базе уже есть 19995 значений из тех, которые прилетели на проверку (всего в базе 300к значений), нет только 5-ти значений (5-ти это условно, может быть и 10 и 20 и 1000), нужно определить каких значений нет и записать их в базу

Если это задача синхронизации, то самый эффективный способ не проверять существование и заливать все пришедшие документы. К ним добавить какой-то идентификатор «версии синхронизации» и хранить его где-то отдельно, используя его для выборок. Все остальные решения алгоритмически будут сложнее

Подскажите, пожалуйста, как реализовать систему тегов для блога. Это обязательно в две коллекции делается Статьи и Теги или можно как-то строкой хранить в статье?

Подскажите, пожалуйста, как реализовать систему тегов для блога. Это обязательно в две коллекции делается Статьи и Теги или можно как-то строкой хранить в статье?

Лучше в одном документе две сущности