yopp

я не уверен

Alex

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

Alex

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

Alex

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

Alex

{ "_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 }

Alex

вот

yopp

Rewrites and defragments all data and indexes in a collection.

yopp

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

Alex

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

Anonymous

>сутки

Alex

да

Alex

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

Roman

Баз на 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 млн записей

Alex

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

Alex

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

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

Alex

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

Alex

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

Anonymous

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

Anonymous

У тебя.

Alex

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

Anonymous

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

Alex

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

Alex

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

Anonymous

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

Anonymous

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

Anonymous

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

Anonymous

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

Alex

15 млн где-то

Anonymous

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

Anonymous

15 млн где-то

👍

Alex

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

Anonymous

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

Alex

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

Anonymous

Сколько?

Anonymous

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

Anonymous

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

Alex

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

Alex

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 }

Anonymous

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

Alex

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

Anonymous

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

Anonymous

Всего 64.

Anonymous

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

Anonymous

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

Anonymous

Alex

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

Anonymous

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

Anonymous

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

Anonymous

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

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

Anonymous

Движок - WiredTiger.

Anonymous

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

Alex

sysctl vm.swappiness

Alex

покажи

Anonymous

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

yopp

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

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

Anonymous

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

Anonymous

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

Anonymous

sysctl vm.swappiness

vm.swappiness = 60

Anonymous

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

Решилось?

Anonymous

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

Anonymous

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

yopp

Решилось?

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

Anonymous

😔

yopp

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

Alex

sysctl -w vm.swappiness=5

Alex

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

Anonymous

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

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

Anonymous

И вот такая беда.

yopp

а

Anonymous

В этом вся проблема.

yopp

у нас именно на шарженой базе была такая хуйня

yopp

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

Anonymous

sysctl -w vm.swappiness=5

Я сейчас поменяю, но ты можешь в двух словах объяснить, зачем?

Anonymous

У меня working set в оперативку помещается.

Anonymous

Фулсканов НЕТ.

yopp

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

yopp

из памяти

Anonymous

Так она и не пытается... Вроде бы.

Alex

в двух словах трудно =)

Anonymous

Но я попробую.