Recurrent bug with incorrectly calculated user upload limits / Повторяющаяся ошибка с некорректным расчетом лимита загрузок
См. сообщение https://pastvu.com/news/153?hl=comment-2260284 Участник: https://pastvu.com/u/Pirogov/manage


@klimashkin что-то вручную делал в таких случаях - то ли обновлял статистику, то ли перезапускал апп. Но нужно уже однажды разобраться, что эе происходит, и починить.
нашел старую инструкцию для пересчета
mongo
use pastvu
db.loadServerScripts()
calcUserStats()
Может, нужно это дело раз в сутки запускать, по расписанию?
Может, нужно это дело раз в сутки запускать, по расписанию?
я запустил один раз, стало лучше?
По идее само должно работать: https://github.com/PastVu/pastvu/blob/master/app.js#L317
Может, нужно это дело раз в сутки запускать, по расписанию?
Раз в двое запускается на данный момент. @aeifn ошибок в логах нет?
По идее само должно работать: https://github.com/PastVu/pastvu/blob/master/app.js#L317
Может, нужно это дело раз в сутки запускать, по расписанию?
Раз в двое запускается на данный момент. @aeifn ошибок в логах нет?
ошибок в логах primary-приложения нету.
ошибок в логах primary-приложения нету.
@paul-k-pastvu сейчас как выглядит, исправилось после ручного запуска? Честно сказать, я не до конца уверен, что проблема в задаче пересчета. По идее, текущая статистика в большинстве случаев пересчитывается по мере изменений влияющих на нее (https://github.com/PastVu/pastvu/blob/master/controllers/photo.js#L942).
Да, в тот раз исправилось. Вопрос, почему время от время от времени сбоит (это далеко не первый раз). Вопрос несрочный, раз лечится пересчетом, но интересный.
Я думаю, что дело в масштабировании приложения. Я как раз с этой функцией разбирался в процессе изменений для Monogo 4. calcUserStatsJob запускается только на "праймари", у этой задачи есть две части - одна обновляет статистику в базе (через dbEval вызов), вторая часть обновляет статистику у пользователей с открытыми сессиями. Вот эта вторая часть тоже запускается только на праймари, т.е. срабатывает не для всех пользователей. С функцией, которая пересчитывает в режиме реального времени, аналогичная ситуация - в базу она изменения внесет, но та часть которая должна обновить текущего пользователя сработает только в случае если модератор и пользователь находятся в момент изменения статуса снимка на одном фронтэнде.
В качестве временного решения - если пользователь разлогинится и зайдет снова - статистика будет верной.
calcUserStatsJobзапускается только на "праймари", у этой задачи есть две части - одна обновляет статистику в базе (через dbEval вызов), вторая часть обновляет статистику у пользователей с открытыми сессиями.
А как этот вопрос был решен на английской версии?
Вот эта вторая часть тоже запускается только на праймари, т.е. срабатывает не для всех пользователей.
Вернее, ни у кого, т. к. инстанс primary никак не выпущен наружу.
Я думаю, что дело в масштабировании приложения.
Да, но это самое реплицирование сейчас обеспечивает по крайней мере
- стабильную работу без зависаний и без необходимости вручную что-то администрировать
- возможность обновлений без остановки приложения
Пользовательские инстансы должны быть подписаны на некоторую IPC-шину, и обновлять состояние при получении сервисных сообщений. Следуя принципу Оккама, можно вообще использовать redis в качестве брокера.
А как этот вопрос был решен на английской версии?
Как я понимаю там calcUserStatsJob до https://github.com/PastVu/pastvu/commit/61756231a0f6d4aa353689816c2842d76efab50b работал так же как и на мастере, т.е. задача в полном объеме запускалась для каждого инстанса.
Да, но это самое реплицирование сейчас обеспечивает по крайней мере
Это бесспорно.
Пользовательские инстансы должны быть подписаны на некоторую IPC-шину, и обновлять состояние при получении сервисных сообщений.
Все верно, так примерно и будет, только не напрямую к редис, а через API Bull task manager (sneak peek ) 😉
В качестве временного решения - если пользователь разлогинится и зайдет снова - статистика будет верной.
Похоже я ошибался, в качестве временного решения это не подходит. Хотя я смог тогда воспроизвести ситуацию где обновление счетчика не происходило как я описал в комментарии выше, по всей видимости проблема в чем-то другом.
что делать то... Доступный лимит: 3 Всего неподтвержденных: 147 в модерации висит 20 https://pastvu.com/news/153?hl=comment-2470214
Пока можно вручную запустить пересчет через консоль mongo:
use pastvu
db.loadServerScripts()
calcUserStats()
В mongo4 заложены изменения этого процесса - будем надеяться, что починится.
Пока можно вручную запустить пересчет через консоль mongo:
Может на крон поставить?
Пока можно вручную запустить пересчет через консоль mongo:
Может на крон поставить?
Да он и так по идее. Если ручной запуск точно помогает, то может быть чаще запускать (каждые 6 часов к примеру).
Пока можно вручную запустить пересчет через консоль mongo:
Может на крон поставить?
Да он и так по идее. Если ручной запуск точно помогает, то может быть чаще запускать (каждые 6 часов к примеру).
Я имею в виду системный крон на хосте (который сейчас бекапы делает)
Пока можно вручную запустить пересчет через консоль mongo:
Может на крон поставить?
Да он и так по идее. Если ручной запуск точно помогает, то может быть чаще запускать (каждые 6 часов к примеру).
Я имею в виду системный крон на хосте (который сейчас бекапы делает)
Сначала стоит убедиться что пересчет таким образом решает проблему, если да, то уменьшить интервал с 2 дней до нескольких часов. На системный крон выносить мне кажется смысла пока нет (но если так удобнее, то можно, только потом нужно будет не забыть убрать после апгрейда).
вручную пока лимит увеличить?

та же проблема у https://pastvu.com/u/Oleg_Andreev/manage в неподверженных 40 фотографий

На системный крон выносить мне кажется смысла пока нет (но если так удобнее, то можно, только потом нужно будет не забыть убрать после апгрейда).
Ну если что, системный крон у нас управляется через https://github.com/pastvu/ansible
Скорее всего проблема будет окончательно решена в #435