yopp
нет, не должен
Anonymous
У меня все логи включены.
Anonymous
Но там нет ни ошибок ни warning'ов.
Alex
Map-reduce в MongoDB выполнялся на одном.
не знал. Мы не юзаем, поэтому не в теме. Как-то кисло
Alex
пойду почитаю
Dan
oh shi~ я уже шёл по этим же вопросам... и по фрагментации, и по логам
Alex
нахуа она тогда вообще нужна, блин =)
Anonymous
не знал. Мы не юзаем, поэтому не в теме. Как-то кисло
Map-reduce в MongoDB может использовать только одно ядро.
Dan
(( но решения так и не нашли ((
Anonymous
Я когда смотрел агрегации - думал что так и норм.
yopp
они сами рекомендуют af
Anonymous
Что оно по одному ядру занимает.
Anonymous
Только вы меня, господа, наверное, не совсем правильно поняли.
Anonymous
Одно ядро забивается на пару секунд.
Anonymous
Потом - другое.
Anonymous
При этом это одна и та же агрегация.
Alex
Правильно правильно
Anonymous
Да.
Alex
Лично я не понимаю почему не использовать несколько ядер одновременно
Alex
но, видимо, есть причины
Alex
если это by design
Anonymous
Я не думаю, что это проблема.
Anonymous
В моём случае.
Alex
угу
Alex
А редис активно работает?
Anonymous
Очень активно.
Anonymous
К сожалению в отличии от MongoDB мониторинга на Redis у меня нормального нет.
yopp
а чо mongotop говорит?
Anonymous
Но примерно по 100 запросов в секунду он принимает.
Anonymous
Я не думаю, что это мешает MongoDB.
Anonymous
Так как суммарно Redis ест не больше 1 GB оперативки.
Anonymous
И процессор не забивает совершенно.
Alex
Я бы предположил фрагментацию памяти. Это объясняет почему помагает рестарт и почему не жрет цпу
Alex
но если честно слету не скажу как это диагностировать =(
Anonymous
А чего там смотреть нужно?
yopp
подержи немного
Anonymous
Держу. Сейчас выполняю агрегацию, смотрю.
Anonymous
Но там 500-800ms и всё.
Anonymous
У меня есть агрегация, которая выполняется практически сразу, за 1 секунду.
Anonymous
Когда происходит провал, она выполняется за 300-600 секунд.
Alex
либо тут какие-то заковыки с редьюсом, в котором я не алё.
Anonymous
Вот она меня беспокоит больше всего.
Anonymous
Там $addToSet в нескольких местах, я ещё не решил, грешить на него, или нет.
yopp
а ты у верен что оно равномерное количество данных агрегирует?
Anonymous
Я сейчас перезагрузил базу.
Anonymous
И у меня агрегация Z выполнилась за 800ms.
yopp
потому что разница на три порядка это пиздец
Anonymous
Меньше, чем за секунду.
Anonymous
Когда происходит "провал" - она выполняется за 300-600 секунд.
Anonymous
Мне кажется, всё дело в ней.
Anonymous
Но я пока не понял, почему.
yopp
ты уверен что провал не связан с тем что в агрегацию попадает больше данных?
Anonymous
а ты у верен что оно равномерное количество данных агрегирует?
Не равномерное, но working set - один и тот же.
Anonymous
Roman
хм, хотя даже как-то удивительно мало (по объему)... неужто, 3-шка жмет так хорошо
Это не трешка жмёт, это данные так жмутся
Anonymous
А почему вся база тормозить начинает тогда?
Anonymous
Там 99% агрегаций с $in.
Anonymous
$in всегда разный, но ограничен по ID.
Anonymous
Получаем последние данные за X дней.
yopp
первое, проверь что оно точно выбирает по индексам
yopp
дважды
yopp
второе, включи отладочный лог на медленные запросы, вроде оно будет туда и агрегации складывать
yopp
и посмотри на порядки попадающих данных
Anonymous
Anonymous
Сначала медленных запросов нет.
Anonymous
Потом происходит какое-то событие.
Anonymous
Все запросы становятся медленнее в N*2 раз.
yopp
просто если оно в одном случае у тебя агрегация по 1к документов, а в другом на 1м документов, то всё логично ваще :)
Anonymous
С каждым новым выполнением - всё более медленные.
yopp
вообще все?
yopp
включи slow log
Anonymous
Да, проседают абсолютно все запросы.