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

обычно выделяют половину памяти

можно ещё http://lwn.net/Articles/317814/

но ваще, если монге надо столько памяти, я бы добавил памяти

сколько индексы занимают?

Не знаю как узнать

https://docs.mongodb.com/manual/tutorial/ensure-indexes-fit-ram/

Per collection?

там слева есть отличное меню, в котором можно обнаружить db.stats()

Посчитал, где-то 700мб

ну вот

тебе памяти надо больше

если индексы не влазят в память всё очень плохо

а ещё надо место на горячие страницы

А как знать что они не влазят? 700мб влазит в 1.9гб

Как оценить в отношении того сколько нужно самой монге

2 гига памяти при учёте что 700 мегабайт только одни индексы это уже в притык

Понял

Спасибо

Как оценить в отношении того сколько нужно самой монге

есть понятие working set, это типа сколько суммарно занимают «горячие» документы и индексы

А горячие документы как-то измерить можно?

примерно прикинуть по avgobjsize и какое количество документов из коллекции используется

IO какое преобладает? R/RW/W?

если R то можно грубо 4 * размер индексов

хотя в любом случае, без метрик, это всё катание какашек

яб просто пока перетащил на тачку в 8 гигами памяти и посмотрел бы

скорее всего 8 гигов за уши хватит на ближашее время

яб просто пока перетащил на тачку в 8 гигами памяти и посмотрел бы

Понял

монга очень чувствительна к количеству памяти

хотя в любом случае, без метрик, это всё катание какашек

А метрики, внутренние монговские статсы?

да

можно взять прометея, если на MMS денег жалко

монга очень чувствительна к количеству памяти

Да, я уже заметил)))

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

Prometheus.io?

Общий вопрос, насколько хороша монго для больших объёмов документов? Ну вот например 200к и это только начало, через год уже будет за 5 млн доков, стоит уже задумываться над каким-то другим решением или при правильной настройке монга может схавать?

задумываться над другим решением надо сразу

))) какой следующий эвалюционный шаг? Cassandra? Hadoop?

Общий вопрос, насколько хороша монго для больших объёмов документов? Ну вот например 200к и это только начало, через год уже будет за 5 млн доков, стоит уже задумываться над каким-то другим решением или при правильной настройке монга может схавать?

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

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

у меня есть подшефный кластер в котором десятки миллиардов документов, только размер там меньше террабайта. и это всё более-менее спокойно крутится на шарде из 3 репликасетов

на железе которое чуть моложе самой монги :)

))) какой следующий эвалюционный шаг? Cassandra? Hadoop?

следующий эволюционный шаг, правильный дизайн документов

мы например даже с компрессией в WT перешли на короткие имена ключей

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

Господа, а действительно, как просить монгу не занимать всю доступную память? А то дев-сервер, а она как скушает себе все 8 гигабайт загнобив приложения и в итоге остаются в памяти редис, мемкеш и монга.

ulimit и ручки у WT

Всё-таки кастовать на ulimit, угу. Спасибо! :)

тоесть услово дать ulimit 4 гига, под WT кеш выделить 2

у меня есть подшефный кластер в котором десятки миллиардов документов, только размер там меньше террабайта. и это всё более-менее спокойно крутится на шарде из 3 репликасетов

Это значит один на запись и два на чтение?

нет, это значит что данные размазываются по 3 репликасетам. у нас запрет на чтение со слейвов, они только для HA

нет, это значит что данные размазываются по 3 репликасетам. у нас запрет на чтение со слейвов, они только для HA

А зачем так?

А зачем так?

replication lag

mongooplog is deprecated starting in MongoDB 3.2.

вот пидоры

а что это ?

штука которая позволяла стримить оплог на другой хост

без включения сервера в кластер

hidden нода ?

Mongo::Error::OperationFailure: CachedPlanStage killed during plan selection (96)

Кто-нибудь знает, почему такое могло произойти?

они на свет прут

Гаси!!!

Господа

а какие есть варианты максимально атомарного и быстрого применения разных снепшотов в монге ?

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

кроме prepare queries а потом bulk 500k нет никаких идей почему то )

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

нет, спасибо )

мышки плакали кололись, но упорно ели кактус (цэ)

это вы про поцгрес ? )

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

про монгу.

30M записей это прилично.

30M записей это прилично.

вобще, это копейки.

Ну ладно.

постгрес давно уже поддерживает JSONB с приличным языком запросов + ACID + UUID вот тебе это и монга, только без головняков =)

постгрес давно уже поддерживает JSONB с приличным языком запросов + ACID + UUID вот тебе это и монга, только без головняков =)

только скейлится ончерез жопу

вспомнить как кластер монги развавливается при неверном репликейшен сете ? :)

сравните процесс создания шардов \ реплицированных шардов \ добавление новых реплик \ роутинг по репликам в монге и постгре

ой да вспоминайте хоть провал форсквейра )

не в курсе за это

это ничего не показывает, кроме черствости ваших знаний )

и отсуствие опыта эксплуатации видимо )

нет

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

если не умеете решать проблемы кластеризации

в RDBMS не беритесь.

ну лечитесь, что поделать

я не хочу это делать в 2016м году также как в 2002м

заебало, чес слово, простите конечно

думать заебало ? :)

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