правда я не помню куда попадает findAndModify, кажется в update

Latest: 3.4.2, Stable: 3.2.12. Пришло время обновлятся до 3.4.1+: https://aphyr.com/posts/338-jepsen-mongodb-3-4-0-rc3

правда я не помню куда попадает findAndModify, кажется в update

ага. спасибо то есть find попадает в opCounters в update?

нет, find это просто команды на чтения. а findAndModify это одна команда на найти и обновить

в opcounters скорее всего ты ищешь query

"query" : 959956, "find" : { "failed" : NumberLong(0), "total" : NumberLong(959913) },

ну близко

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

%)

надо уже сесть и дописать экспортер

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

На свой страх и риск можно попробовать вот это: https://github.com/y8/mongo_collection_exporter

нужен прометей и графана

и jre7/8

и монга 3.2.10+

на 3.0.x/3.2.10- тоже почти всё будет работать, но там не будет метрик по тому как конкретной коллекцией/индексами кеш используются (wt cache usage)

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

забикс не умеет собирать статистику по кокнетным коллекциям/индексам afaik

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

тот же серверстатус можно парсить каким-нибудь jq

там не serverStatus пасить надо

а collStats для всех коллекций

а что?

ну ок... какая разница что парсить

иначе толку от того что ты будешь знать что «монга пишет в/из кеша»

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

это же через mongo -e"collstat()" длается все равно?

больше скажу: монга делает больше io чем может прожевать сторадж!

это же через mongo -e"collstat()" длается все равно?

нет, это делается в три этапа: получить список всех баз

потом получить список коллекций в базе

потом пройти по всем коллекциям

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

автообнаружение называется

и сделать db.getCollection(<name>).stats({indexDetails: 1})

а потом парсить каждый документ в стате индексов :)

можешь взять логику из экспортера

пионерам бесполезно предлагать готовое решение :)

да, я именно так и считаю кол-во записей в коллекции

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

да не важно, главное понять что считать

всё

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

что-то в духе ~200 метрик на коллекцию + ~200 на каждый индекс (сходу ~400)

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

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

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

ты меня не слушаешь

тебе от find не холодно и не жарко

тебе serverStatus() тут не поможет

ок. а что мне нужно искать?

это слишком общие метрики, которые ничего кроме «плохо/хорошо» вообще сказать не могут

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

вот вижу я что растет чтение на диске, растет Iowait, есть всплески педжфолтов. Какая дальше должна быть стратегия?

минимальный набор: программа минимум (ключ wiredtiger в stats(): "cache" : { "bytes currently in the cache" : 710342011, "bytes read into cache" : 496185602, "bytes written from cache" : 161808640, "internal pages evicted" : 0, "modified pages evicted" : 14, "unmodified pages evicted" : 0 } "block-manager" : { "checkpoint size" : 194146304, "file size in bytes" : 185212928, "file bytes available for reuse" : 28672, } "cursor" : { "bulk-loaded cursor-insert calls" : 0, "create calls" : 25, "cursor-insert key and value bytes inserted" : 168862327, "cursor-remove key bytes removed" : 0, "cursor-update value bytes updated" : 0, "insert calls" : 1257539, "next calls" : 11398715, "prev calls" : 1, "remove calls" : 0, "reset calls" : 1812770, "restarted searches" : 10372, "search calls" : 466189, "search near calls" : 89095, "truncate calls" : 0, "update calls" : 0 }

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

так что тебе эти данные нужно ещё по _каждому индексу_ в каждой коллекции собирать

(аргумент {indexDetails: 1})

вот вижу я что растет чтение на диске, растет Iowait, есть всплески педжфолтов. Какая дальше должна быть стратегия?

найти какая коллекция или индекс задыхается

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

но обычно по графикам сразу видно примерно что происходит

найти какая коллекция или индекс задыхается

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

я тебе выше скинул метрики

кеш - это про то, что коллекция влезает в кеш или нет, я правильно понимаю?

в третий раз повторяю: по всем базам, по всем коллекциям, нужно сделать db.getCollection(<name>).stats({indexDetails: 1}) и распарсить ключ wiredtiger и indexDetails (в котором ключом будет название индекса, а значением будет примерно тоже самое что в wiredtiger)

кеш - это про то, что коллекция влезает в кеш или нет, я правильно понимаю?

не только коллекция

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

(в большинстве случаев)

а вот если индексы не влезают — очень страшно

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

причём упираемся обычно худшим способом: evict modified, а это записать минимум несколько блоков на диск, а потом чтение нужного

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

ты будешь видеть три вещи

"bytes currently in the cache" : 710342011, "bytes read into cache" : 496185602, "bytes written from cache" : 161808640,

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

нет, это внутренние метрики хранилища

они относительно безобидные в сборке

по крайней мере на порядки более безобидные чем setProfile с 10мс

wt и так собирает кучу информации, так что это просто чтение из памяти без особых изысков

короче

currently in cache покажет тебе сколько данные занимают в памяти (можно сравнить с size и понять сколько вмещается в память)

изменение currently in cache покажет что происходит с кешем конкретной коллекции: кеш вытесняется или вытесняет других

read into покажет как кеш пополняется / wrritten from показывает сколько из кеша выгружается на диск

это позволит определить что коллекция/индекс дрочат диск

дальше берём cursors и смотрим что именно дрочит

ага...теперь вроде более менее понятно

и третий момент

расскажи про курсор, что это?

"block-manager" : { "checkpoint size" : 194146304, "file size in bytes" : 185212928, "file bytes available for reuse" : 28672, }

изменение file size in bytes покажет тебе когда монга аллоцирует ещё места на диске

file bytes available for reuse покажет тебе что у тебя в коллекции много «дырок»: страниц которые помечены как свободные

checkpoint size я чот не помню зачем я сюда ввернул

про курсор можно поподробнее, что он показывает?

ну курсор он и есть курсор

как он дрочит диск и тп, давай подробости)

курсор это штука которая читает данные в wiredtiger

если про wt метрики

в монге любой запрос (в sql терминологии select) на чтение открывает курсор

считай как «постраничная навигация»

ок. так

курсор тебе выдаёт окно в X записей и ты можешь туда-сюда двигать это окно