Moodle тормозит: что проверить до того, как покупать сервер помощнее

Начинать нужно отсюда, потому что это самая частая находка. При установке и настройке администратор включает «Режим дизайнера тем» (Theme designer mode) и уровень отладки DEVELOPER, чтобы видеть ошибки и изменения в стилях. После запуска их забывают выключить.

Режим дизайнера тем отключает кеширование CSS: каждая страница у каждого пользователя пересобирает стили заново. На тестовом стенде с одним человеком это незаметно, на сотне одновременных слушателей — заметно очень. Отладка добавляет к этому сбор и вывод диагностики на каждый запрос. Оба переключателя выключаются за минуту и в проде должны быть выключены.

Moodle кеширует данные через собственный механизм MUC. По умолчанию кеш лежит в файлах, то есть каждое обращение к нему — это операции с диском. Для установки, где учатся несколько десятков человек, это терпимо. Дальше кеши приложения и сессии имеет смысл перенести в Redis или Memcached.

На уровне PHP проверьте, включён ли OPcache и хватает ли ему памяти: Moodle — большое приложение, и без OPcache интерпретатор разбирает одни и те же файлы на каждом запросе. Состояние кешей видно в отчёте о производительности в самом Moodle.

Cron в Moodle отвечает за рассылки, отложенные задачи, пересчёт оценок, чистку временных данных. Если его не настроили через системный планировщик, задачи выполняются в момент, когда кто-то открывает страницу, и этот кто-то ждёт. Правильная схема: запуск раз в минуту от системного cron, веб-запуск закрыт.

Отдельно посмотрите очередь адхок-задач. Если она копится, значит cron падает или не успевает, и это надо чинить, а не игнорировать.

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

Срок хранения журналов настраивается. Решите, какая глубина вам действительно нужна для отчётности, выставьте её и дайте задаче чистки отработать. Перед этим — резервная копия, потому что удалённые записи не вернуть.

Каталог moodledata должен лежать вне веб-корня и на быстром диске. Файлы курсов Moodle хранит по хешу содержимого, дубликаты не плодятся, но объём всё равно растёт, и мониторинг свободного места экономит нервы.

По базе данных смотрите долгие запросы. Чаще всего они приходят из отчётов, из журнала событий и из плагинов, которые ставили «попробовать» и не удалили. Отключённый плагин продолжает лежать в системе; неиспользуемые лучше удалять.

После того как выключен режим отладки, кеши переехали в память, cron работает по расписанию, а журналы почищены, становится видно реальную нагрузку. Если и после этого страницы отдаются медленно на обычной активности, разговор о ресурсах уже предметный: понятно, чего именно не хватает — процессора, памяти или диска.

ЦИТР проводит аудит платформы с отчётом по этим пунктам и берёт установки на сопровождение: обновления версий, мониторинг доступности, резервное копирование.