вы просто неосили, мы все знаем )

у вас там деньги зарабатывать вот это все.

вам некогда изучать. путь ХХП )

все-все-все

пля как посмотреть?

движок

у меня дежавю

в конфиге нету энгина

приходите на hl++ послушать наши доклады, серьезно

там и решите, неосилили мы, или просто умнее многих

какие нах доклады у меня тут мастер монги падает

а я не вам :)

в конфиге нету энгина

db.server.status().storageengine

serverstatus слитно

actr:PRIMARY> db.serverstatus().storageengine 2016-05-17T13:41:12.803+0300 E QUERY TypeError: Property 'serverstatus' of object test is not a function at (shell):1:4

приходите на hl++ послушать наши доклады, серьезно

а я вам вопросы даже задавал на прошлом. и как бы не осилили )

там, небойсь, еще и своп на серверах есть

это тоже важно. я бы, извините, начал с его отключения

actr:PRIMARY> db.serverstatus().storageengine 2016-05-17T13:41:12.803+0300 E QUERY TypeError: Property 'serverstatus' of object test is not a function at (shell):1:4

ну наберите там правильно, потабайте

на прошлом hl++ я рассказывал про фс. чего я там не осислил-=то?

Хм. сорян я попутал наверно

понял ща

а про мускули и РТБ не вы ? )

а на hl я про rtb рассказывал, осенью

да, я

во )

чего я не осилил там?

обратная связь - это важно

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

чтобы сейчас не быть голословным

не

"storageEngine" : { "name" : "mmapv1"

всё такие он не в кеш уходит

тоска...

а в кешированую память

так точнее будет

это норм.

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

sysctl -a | grep swapp

vm.swappiness = 60

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

А, с жтим проблем вроде не было. Были "претнезии" к реализации \ решению описанному в докладе и то что было представленно проблемами и их решением.

free -g

free -g total used free shared buffers cached Mem: 62 62 0 0 0 60 -/+ buffers/cache: 2 60 Swap: 31 0 31

ну оно наверняка у вас уползает в своп

в графиках своп пустой почти

вырубите своп, либо для начала своппиннес в 0 выставите

хм

там пара сотен мегабайт гоняющихся по нему при забитой памяти могут привести к проблемам.

как назначить?

во вторых. на реплике выставите stoage engine wired tiger

vm.swappiness

мож откл свопа поможет

компрессию соавьте стандартную.

у нас на самых плохих кейсах комперссия составляла 2.2 где то.

но нужно чтобы у вас был свободный cpu компрессия даст примерно процентов 15 сверху к той нагрузке что была.

в рабочее время, а не во время восстановления.

и посмотрите размер вашего лога. если репликации идет медленно и данных много, вы можете не успеть

James Maynard, [17.05.16 13:20] Коллеги подскажите с такой ситуацией James Maynard, [17.05.16 13:20] в общем есть база в 750 гб James Maynard, [17.05.16 13:20] при запуске репликации проходит 2 часа и на серваке всё уходит в кеш и потом отваливается процесс (на мастере) James Maynard, [17.05.16 13:21] можно ли как то это залимитить ?

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

в общем кроме смены движка выхода не вижу

оплог?

увеличить лог?

да. Скорее всего разрыв репликации из-за того, что данные не успевают влится в slave

там есть командочки

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

rs.printreplicationinfo()

оплог не меняется "на ходу"

ERROR: S client not available

дайтека командочки

rs.status()

или ткните что сделать

сек

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

https://docs.mongodb.com/manual/core/replica-set-oplog/

*оплоге

да там вообще лучше весь раздел проштудировать, он совсем небольшой

если вы за период с указанного там времени до текущего, не успеете репликацию сделать - все плохо )

connecting to: test actr:PRIMARY> rs.status() { "set" : "actr", "date" : ISODate("2016-05-17T11:09:36.308Z"), "myState" : 1, "members" : [ { "_id" : 0, "name" : "ып:27017", "health" : 1, "state" : 1, "stateStr" : "PRIMARY", "uptime" : 3138, "optime" : Timestamp(1463483376, 14), "optimeDate" : ISODate("2016-05-17T11:09:36Z"), "electionTime" : Timestamp(1463480278, 1), "electionDate" : ISODate("2016-05-17T10:17:58Z"), "configVersion" : 47573, "self" : true }, { "_id" : 1, "name" : "ып:27017", "health" : 1, "state" : 5, "stateStr" : "STARTUP2", "uptime" : 2993, "optime" : Timestamp(0, 0), "optimeDate" : ISODate("1970-01-01T00:00:00Z"), "lastHeartbeat" : ISODate("2016-05-17T11:09:34.344Z"), "lastHeartbeatRecv" : ISODate("2016-05-17T11:09:34.924Z"), "pingMs" : 2, "syncingTo" : "ып:27017", "configVersion" : 47573 }, { "_id" : 2, "name" : "ып:27017", "health" : 1, "state" : 7, "stateStr" : "ARBITER", "uptime" : 3099, "lastHeartbeat" : ISODate("2016-05-17T11:09:34.875Z"), "lastHeartbeatRecv" : ISODate("2016-05-17T11:09:34.907Z"), "pingMs" : 0, "configVersion" : 47573 } ], "ok" : 1 }

ну почему плохо? Нормально, оплог подкрутить и все станет хорошо

здесь просто татус

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

connecting to: test actr:PRIMARY> rs.status() { "set" : "actr", "date" : ISODate("2016-05-17T11:09:36.308Z"), "myState" : 1, "members" : [ { "_id" : 0, "name" : "ып:27017", "health" : 1, "state" : 1, "stateStr" : "PRIMARY", "uptime" : 3138, "optime" : Timestamp(1463483376, 14), "optimeDate" : ISODate("2016-05-17T11:09:36Z"), "electionTime" : Timestamp(1463480278, 1), "electionDate" : ISODate("2016-05-17T10:17:58Z"), "configVersion" : 47573, "self" : true }, { "_id" : 1, "name" : "ып:27017", "health" : 1, "state" : 5, "stateStr" : "STARTUP2", "uptime" : 2993, "optime" : Timestamp(0, 0), "optimeDate" : ISODate("1970-01-01T00:00:00Z"), "lastHeartbeat" : ISODate("2016-05-17T11:09:34.344Z"), "lastHeartbeatRecv" : ISODate("2016-05-17T11:09:34.924Z"), "pingMs" : 2, "syncingTo" : "ып:27017", "configVersion" : 47573 }, { "_id" : 2, "name" : "ып:27017", "health" : 1, "state" : 7, "stateStr" : "ARBITER", "uptime" : 3099, "lastHeartbeat" : ISODate("2016-05-17T11:09:34.875Z"), "lastHeartbeatRecv" : ISODate("2016-05-17T11:09:34.907Z"), "pingMs" : 0, "configVersion" : 47573 } ], "ok" : 1 }

https://gist.github.com/, извините

да не нада ждать

нужно в репликейшен инфо глянуть

и понять

я то и жду но сервак не выдерживает

PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 15644 mongodb 20 0 1.6T 40.9G 40.8G S 5.2 65.3 1:50.59 /usr/bin/mongod —config /etc/mongodb.conf

давайте уточним - что значит "не выдерживает"? реплика падает в карантин?

это хтоп

ну и что? OOM срабатывает?

65.3 сейчас

мастер падает

просто процесс отваливается

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

в логах что?

когда становится память 100%

с+ выхлоп

могу скинуть

освободить мастер можно?