на мастере "stateStr" : "STARTUP2",

потеря индекса на _id это круто. :( Имхо, вам стоит подумать о переезде на другое железо и более production ready OS..

потеря индекса на _id это круто. :( Имхо, вам стоит подумать о переезде на другое железо и более production ready OS..

ну вот, теперь и ты занимаешься gentoo shaming

мастер прокачал 92 гб и опять упал

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

как тебе это удаётся?

так снова repair, если помогает

да так и сделал

но я не могу понять почему падает

но я не могу понять почему падает

а в логе что?

тоже что и было в первый раз

но я не могу понять почему падает

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

ну кто тож знает

где гарантия что она опять не ляжет даже когда засинхронитсья

да никто не знает. ругается она на файл, который по её мнению был да всплыл. Чтобы попытаться понять что за файл вообще она ищет, я писал, попробуйте запустить mongod через strace , т.е # strace -e open .../mongod ...опции...

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

спасибо попробую

Коллеги, ищем докладчиков по Mongo на http://devconf.ru/ru/offers

Как там дела у James?

Мы вот сегодня сделали первый шаг по переходу с 2-ки на 3.2. Поскольку сразу на 3.2 нельзя, надо сначала на 3.0, а с нее уже прыгать на 3.2. Вооот. Делали всё по доке. Обновили обе ноды в репликасете, но бд оставили в старом формате. Потом на слейве переключили на WT. Реплика пересоздалась, вроде всё ок. Сделали её мастером - и началось! Все запросы на запись в бд завершались ошибкой без каких-либо вменяемых описаний - Error update и всё тут. Вернули мастером ноду с базой в старом формате. Повторили переключение еще раз - со второго раза вроде завелось... Ох. Игра с огнем эта монгадб.

Ну, wt - хороший движок ;) но отдельно от монги :)

Внутри ВАЗ 2108 тоже неплохой движок. Но отдельно от ВАЗ 2108 =) А толку,

Я использовал wt отдельно от монги :)

Но потом забил

А может кто знает, зачем монга (3, 3.2) при создании реплики "с нуля" на secondary ноде дважды перестраивает индексы? Т.е мы наблюдаем такое: убиваем данные на secondary, начинается sync init. После этого - запускается создание индексов. После этого опять sync init , но уже быстрый, данных для синка нет, и снова - пересоздает индексы! o_0 Повторение мать учения, чтоли?

2

ну, в смысле, всего 2 сервера в сете

+арбитр, конеч

привет

count очень медленный что делать?

db.media.explain().find({ok: true, is_private: false, created_year:{$in: [2000, 2001, 2002]}}).sort({ index: 1, min_created_date: 1 }).count()

{ "stage" : "IXSCAN", "keyPattern" : { "is_private" : -1, "ok" : 1, "index" : 1, "min_created_date" : 1, "created_year" : 1 } }

но почему выполняется 68508ms

что я делаю не так?

как жить?

да знаю

но что делать?

сори но я не понял

а зачем sort в count?

да

я сам не заметил

ну вообще в коде и так без сорт выполняется

ну а размер БД, индексов и сколько памяти на сервере?

Serge почему-то не спросил про версию =)

3.2 запущена на моем mbp retina i5 с 8гб > db.stats() { "db" : "picryl", "collections" : 23, "objects" : 4934972, "avgObjSize" : 2385.8588638395518, "dataSize" : 11774146689, "storageSize" : 5409226752, "numExtents" : 0, "indexes" : 128, "indexSize" : 2304520192, "ok" : 1 }

> db.media.stats() { "ns" : "picryl.media", "count" : 2793589, "size" : 6722435508, "avgObjSize" : 2406, "storageSize" : 3025006592, "capped" : false, }

ну а размер БД, индексов и сколько памяти на сервере?

если вас интересует размер памяти и индексов значит эта проблема с индексами решаема?

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

минута на этот запрос - это много

я не знаю точно в чем проблема. Возможно, индексы вытеснены из памяти и монга шуршит диском. Какая ОС? Что-то еще тяжелое запущено?

раньше была такая выборка { ok: true, is_private: false, max_created_date: { '$gte': Tue Jan 01 1895 03:00:00 GMT+0300 (MSK) }, min_created_date: { ' $lte': Sun Dec 31 1905 03:00:00 GMT+0300 (MSK) } } sort: { index: 1, min_created_date: 1 } это гораздо хуже работало

вообще я не желаю получить ответ

просто хотел убедиться что это не только у меня проблема

imho, памяти не хватает

у медия нет точной даты создания - есть диапазон он хранится как 2 поля min и max и мне нужно выбрать например медиа в диапазоне с 1900 по 1915

так запрос в индекс бьет же

IXSCAN

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

(ну, примем это как пасутлат =)

выгрузите все лишние процессы и повторите запрос пару раз

вангую, что после первого раза начнет быстро работать

да, а что за ОС-то, яблоко?

да

когда 2 границы нельзя в индекс попасть

что видно? темку KDE? :)

конечно, проще погадать, чем просто написать. ок .

то что chrome canary а не chromium уже палит что не линукс)

может он имя процесса поменял

=)

если открыть хтопом

и заценить слева направо

сколько туда улетает параметров

а free -m в яблоках нет?

но как это связано?

ты посчитал количество хромовых процессов

а там слева направо экранов 10 параметров, эт так прост смешнявочка)

о, ща

Это только верхушка верхушки айсберга