сто лямов документов? не так уж много.

ну смотря какого размера

если по мегабайту, то очень много :)

или если по 10кб, но с тремя десятками индексов

это и был намек =)

если по мегабайту, то очень много :)

Niet.

100Тб это много

100Тб это много

На одном сервере? Прилично.

100Т данных - это по любому много

тут я смотрю у всех петабайтные монгокластеры

Баз на 60 гигов, мастер. После ненормального шутдауна зпускалась _12 минут_, ппц =( Jul 30 21:13:38 conveyor mongod.37017[16636]: [initandlisten] Detected unclean shutdown - /var/db/mongo2/mongod.lock is not empty. Jul 30 21:13:38 conveyor mongod.37017[16636]: [initandlisten] Recovering data from the last clean checkpoint. Jul 30 21:13:38 conveyor mongod.37017[16636]: [initandlisten] wiredtiger_open config: create,cache_size=18G,session_max=20000,eviction=(threads_max=4),config_base=false,statistics=(fast),log=(en abled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0), Jul 30 21:25:27 conveyor mongod.37017[16636]: [initandlisten] Starting WiredTigerRecordStoreThread local.oplog.rs Jul 30 21:25:27 conveyor mongod.37017[16636]: [initandlisten] The size storer reports that the oplog contains 59804846 records totaling to 30178412526 bytes

Ну так рекавери жи.

12 минут?

Рекавери должен быть мгновенным - там журнал включен

Я где-то месяц назад восстанавливал минут 15 базу на 400 GB.

С журналом.

Так что вроде бы ничего необычного.

Так вот странно. По идее размер бд не должен влиять на время, если есть журнал.

Какого лешего она столько времени делает-то?

Проверить на корректность достаточно последние записи в журнале. И всё, погнали, чего еще делать?

Оно вроде весь оплог переливает снова

При recovery

Если оплога было много, займёт много времени

М.. куда переливает?

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

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

я не уверен

не не, это не тот вариант

когда роллбек или догонялки - он пишет об этом в rs.status()

а я следил, в эти 12 минут репликасет вообще считал хост мертвым

{ "_id" : 4, "name" : ".......:37017", "health" : 0, "state" : 8, "stateStr" : "(not reachable/healthy)", "uptime" : 0, "optime" : { "ts" : Timestamp(0, 0), "t" : NumberLong(-1) }, "optimeDate" : ISODate("1970-01-01T00:00:00Z"), "lastHeartbeat" : ISODate("2016-07-30T18:23:21.635Z"), "lastHeartbeatRecv" : ISODate("2016-07-30T17:50:26.748Z"), "pingMs" : NumberLong(1467), "lastHeartbeatMessage" : "Connection refused", "configVersion" : -1 }

вот

Rewrites and defragments all data and indexes in a collection.

repairDatabase который —repair это и есть compact

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

>сутки

да

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

Баз на 60 гигов, мастер. После ненормального шутдауна зпускалась _12 минут_, ппц =( Jul 30 21:13:38 conveyor mongod.37017[16636]: [initandlisten] Detected unclean shutdown - /var/db/mongo2/mongod.lock is not empty. Jul 30 21:13:38 conveyor mongod.37017[16636]: [initandlisten] Recovering data from the last clean checkpoint. Jul 30 21:13:38 conveyor mongod.37017[16636]: [initandlisten] wiredtiger_open config: create,cache_size=18G,session_max=20000,eviction=(threads_max=4),config_base=false,statistics=(fast),log=(en abled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0), Jul 30 21:25:27 conveyor mongod.37017[16636]: [initandlisten] Starting WiredTigerRecordStoreThread local.oplog.rs Jul 30 21:25:27 conveyor mongod.37017[16636]: [initandlisten] The size storer reports that the oplog contains 59804846 records totaling to 30178412526 bytes

Чего-то дохрена в оплоге, кстати. 30гб и 59 млн записей

во всяком случае, в версии 2 была какая-то шляпа с этим репейром

Чего-то дохрена в оплоге, кстати. 30гб и 59 млн записей

дык это таскопровод наш =)

insert query update delete getmore command % dirty % used flushes vsize res qr|qw ar|aw netIn netOut conn set repl time *19 *0 *869 *8 0 22|0 3.9 78.3 0 17.4G 16.5G 0|0 0|0 1k 15k 179 default SEC 2016-07-31T00:15:38+03:00 *38 *0 *730 *18 0 12|0 4.1 78.4 0 17.4G 16.5G 0|0 0|0 897b 10k 177 default SEC 2016-07-31T00:15:42+03:00 *34 *0 *685 *18 0 52|0 4.4 78.4 0 17.4G 16.5G 0|1 0|0 4k 27k 182 default SEC 2016-07-31T00:15:46+03:00 *31 *0 *720 *16 0 17|0 4.5 78.4 0 17.4G 16.5G 0|0 0|0 1k 13k 181 default SEC 2016-07-31T00:15:50+03:00 *19 *0 *693 *11 0 12|0 4.5 78.3 0 17.4G 16.5G 0|0 0|0 803b 11k 181 default SEC 2016-07-31T00:15:54+03:00

600-800 апдейтов в сек - нормальный режим

Сколько доков в базе?

У тебя.

Там несколько баз

А всего доков сколько?

ну. так не помню. миллионов 10, где-то

хотя надо глянуть, ща

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

Сравнить данные.

У меня вот самая большая нода на сто лямов - ест 30 GB оперативки (vsize & res).

Хотелось просто сравнить.

15 млн где-то

Чтобы понять.

15 млн где-то

?

но очень активно обновляется только тысяч 100-300, остальное - архив

Да это working set, понятно.

но, база которая очень активная - там много индексов

Сколько?

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

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

хм, хотя даже как-то удивительно мало (по объему)... неужто, 3-шка жмет так хорошо

default:PRIMARY> db.stats() { "db" : "tasks", "collections" : 4, "objects" : 306741, "avgObjSize" : 7491.015123508107, "dataSize" : 2297801470, "storageSize" : 1356922880, "numExtents" : 0, "indexes" : 36, "indexSize" : 193695744, "ok" : 1 }

db.stats() { "db" : "bot", "collections" : 6, "objects" : 110309007, "avgObjSize" : 431.35387809265654, "dataSize" : 47582217958, "storageSize" : 27080220672, "numExtents" : 0, "indexes" : 14, "indexSize" : 4767297536, "ok" : 1 }

памяти нормально на сервере?

Да, свободно процентов 50%.

Всего 64.

Если очень кратко о проблеме - есть цикл различных агрегаций, который выполняется каждые X минут на сервере. Последнюю неделю я перезапускаю MongoDB по 3-4 раза в день, потому что если этого не делать - время выполнения каждого цикла начинает расти в геометрической прогрессии. Обычно всё выполняется на 5 секунд (например), но потом происходит какой-то провал и тот же цикл выполняется за 15-20 секунд (иногда и в 5-10 раз дольше). Затем, если базу не перезагружать, то время выполнения растёт с каждым новым циклом. Почему перезагрузка базы лечит этот недуг - я пока не знаю.

Вот уже неделю пытаюсь разобраться.

версия обновлена?

Ну не 50% оперативки, но где-то рядом.

Как минимум не забита.

Свапится может?

версия обновлена?

Самая последняя.

Движок - WiredTiger.

Свапится может?

Может. А как узнать и копнуть глубже?

sysctl vm.swappiness

покажи

Ну вот на скриншоте больше полутора гигов свапа

insert query update delete getmore command % dirty % used flushes vsize res qr|qw ar|aw netIn netOut conn time 1006 *0 16 *0 0 55|0 0.2 81.7 0 40.1G 33.8G 0|0 1|0 15k 31k 688 2016-07-30T21:25:41Z 1125 *0 13 *0 0 34|0 0.2 80.8 0 40.1G 33.8G 0|0 1|0 13k 27k 688 2016-07-30T21:25:42Z 3441 *0 29 *0 0 35|0 0.2 80.7 0 40.1G 33.8G 0|0 1|0 30k 29k 688 2016-07-30T21:25:43Z 2830 *0 17 *0 0 37|0 0.2 80.3 0 40.1G 33.8G 0|0 1|0 15k 28k 688 2016-07-30T21:25:44Z 1388 *0 17 *0 0 27|0 0.2 80.2 0 40.1G 33.8G 0|0 1|0 13k 26k 688 2016-07-30T21:25:45Z 2033 *0 21 *0 0 45|0 0.2 80.2 0 40.1G 33.8G 0|0 1|0 19k 30k 688 2016-07-30T21:25:46Z

Если очень кратко о проблеме - есть цикл различных агрегаций, который выполняется каждые X минут на сервере. Последнюю неделю я перезапускаю MongoDB по 3-4 раза в день, потому что если этого не делать - время выполнения каждого цикла начинает расти в геометрической прогрессии. Обычно всё выполняется на 5 секунд (например), но потом происходит какой-то провал и тот же цикл выполняется за 15-20 секунд (иногда и в 5-10 раз дольше). Затем, если базу не перезагружать, то время выполнения растёт с каждым новым циклом. Почему перезагрузка базы лечит этот недуг - я пока не знаю.

какая знакомая проблема

mongostat вроде бы самый обыкновенный.

sysctl vm.swappiness

Да и вот следующий шаг сие уменьшить

Я уже неделю бьюсь.

sysctl vm.swappiness

vm.swappiness = 60

какая знакомая проблема

Решилось?

И памяти добавить:)

Память есть же...

vm.swappiness = 60

Это много

Свободная. Достаточного много ещё.

Решилось?

было на 3.0, на 3.2 пропало

?

пришлось на всех репликасетах переливать данные

sysctl -w vm.swappiness=5

и понаблюдать

Главное, что свапится

пришлось на всех репликасетах переливать данные

Да у меня всё проще - у меня одна нода без шардов и реплик.