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

иначе б не спрашивал ничего)))

потому что там есть журнал, там есть кеш wt, там есть кеш файловой системы

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

у тебя есть немного ручек в линуксе чтоб покрутить дисковый кеш

возможно твои 100% busy без симптомов в монге это именно эффективно работающий дисковый кеш

слишком мало улик, а ты уже полез в кишки wt

я понял твой послы, попробую пособирать

nmon замени на node_exporter и сделай рядом графики моего экспортера и iops на диске

если у тебя нжмд, время начать переезжать на ssd

raid 10 не нужен

если нужна надёжность, добавляй реплики

развалившийся рейд убьёт тебе монгу

resync сожрёт вообще весь iops и монга будет стоять раком

если не хватает iops, но есть cpu и ты уже на ssd, нужно смотреть на nmve

на это повлять особо не поулчится

рейд софтовый?

на самом деле хз

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

хай пипл

подскажите почему долгая запись

2017-03-31T13:09:45.100+0300 I COMMAND [conn1435846] query somebasename.activity_31 query: { $query: {}, $orderby: { request_time: -1 } } planSummary: COLLS CAN, COLLSCAN cursorid:4130067536824 ntoreturn:25 ntoskip:0 keysExamined:0 docsExamined:390534 hasSortStage:1 keyUpdates:0 writeConflicts:0 numYields:3051 nreturned:25 reslen:11190 locks:{ Global: { acquireCount: { r: 6104 } }, Database: { acquireCount: { r: 3052 } }, Collection: { acquireCount: { r: 3052 } } } 665ms

Для того чтоб вернуть 25 документов монга прочитала 390к. Тебе нужен индекс.

Поставили mongo-exporter, настроили графану. собственно вопрос по самим метрикам - в Query Executor Query Executor и Query Executor как должны соотноситсья?

«в Query Executor Query Executor и Query Executor»?!

тебе нужен второй воркспейс: Mongo Collection

https://gist.github.com/y8/f566c5b6101e29e241075ad71f9b15d7

монга какая?

там в одном из минорных релизов 3.2 добавили самое интересное: стату по индексам

тебе нужны графики WT * Activity

они показывают активность кеша по данным и индексам

меня конечно местами убивает работа с тегами/зонами в монге. Теги уже успели стать зонами, а диапазоны всё ещё надо, сука, в config.tags смотреть.

возьми вот это https://github.com/y8/mongo_collection_exporter подними прометея и графану и посмотри структуру нагрузки

нее. не бери. это abandonware :(

$)

на следующей неделе туда патчи поедут

о круто

а ещё вот такие вещи очень умиляют. https://yopp.in/11LM

https://yopp.in/11Mf

потому что кеширование это вторая по сложности задача, после придумывания имён. на продуктивном шарде, где к коллекции летают запросы, вы такого врядли увидите, а вот локально легко. (просто сделайте запрос который выполнится на всех шардах, например `find({}).count()`)

парни, а почему при билде индексов background: true не дефолт ?

А почему должен быть?

ибо не блокирующий

Условно

есть хоть одна причина почему стоит на продуктовой базе делать индекс без этого ключа ?

Потому что на продуктовой базе это самоубийство, проще реплики по одной вывести и сделать индекс без background

ну тоесть роллинг индекс ?

Ну я не уверен как оно точно называется, но видимо да

в чем плюс такого подхода ?

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

других плюсов не понимаю

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

ага. ок.

Ещё, до недавних пор, слейвы вообще не умели background:true

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

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

тоесть при праивльном планировании ресурсов background: true всё еще рулит.

тогда почему он не дефолт :)

потому что это может занять бесконечное время

это блокирует ряд операций

это требует памяти

перезапускаешь в standalone, делаешь индекс, ставишь обратно в кластер, догоняешь оплог, промутишь в мастер

бесконечное время это аргумент.

я так понимаю это агрумент при высокой нагрузке на запись ?

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

Вот тут немного не понял. Допустим, у тебя 16 физических ядер. Как одно ядро в полку компенсирует 15 остальных?

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

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

что в 99% случаев приведёт к пиздецу неизвестной продолжительности

хорошо. звучит убедительно.

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

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

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

что такое роллинг индекс?

это вот то что вы описываете роллинг индекс. по одной выводим строим вводим

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

background займёт дольше

потому что там алгоритм другой

я перефразирую: так сделали чтоб народ не стрелял себе в коленку

(хотя я всё ещё не понимаю почему у курсоров по-умолчанию таймаута нет)

https://github.com/mongodb/mongo/blob/584ca76de9ee66b3e11987e640f5317ae40975e4/src/mongo/db/index_builder.h#L46

если ещё проще: создание индекса ебически дорогая операция с точки зрения cpu и io. ты должен думать головой перед тем как строить индекс, иначе ты почти гарантированно наебнёшь кластер

https://github.com/mongodb/mongo/blob/584ca76de9ee66b3e11987e640f5317ae40975e4/src/mongo/db/index_builder.h#L46

м?

https://github.com/mongodb/mongo/blob/72408d7f852058088e1446f77cbea06c029df133/src/mongo/db/catalog/index_create.h#L71

as there is no concurrency benefit to building a subset of * indexes in the background, but there is a performance benefit to building all in the * foreground. */

but there is a performance benefit to building all in the foreground.

ну

но

foreground 2017-04-02T13:13:23.421+0300 using default 'dump' directory 2017-04-02T14:18:49.055+0300 done background 2017-04-02T14:20:47.295+0300 using default 'dump' directory 2017-04-02T15:13:51.539+0300 done

второе получено из первого путем for f in *.json.gz; do cp "$f" "$f~" && gzip -cd "$f~" | sed 's/"background":false/"background":true/g' | gzip > "$f" done

это всё конечно замечательно. но какую проблему ты пытаешься решить?

лишь понять зачем так

because reasons

так себе ответ

я тебе выше уже аргументы дал

да дал. и комменты в коде говорят что нет бенефита.

на незагруженной базе, коненчо разница будет на уровне статистической прогрешности. bg будет немного медленее fg (там иначе данные из хранилища достаются)

но я от чегото вижу этот бенефит

потому что твой тест говно :)