Извините за новичок в этом вопросе. Я веб-разработчик, но у меня нет большого опыта в обслуживании серверов или отладке и устранении проблем с производительностью.
У меня есть сайт Moodle (Moodle 2.2.3), работающий на сервере Apache (стек LAMP), который использует базу данных MySQL.
В последнее время, когда некоторые пользователи пытаются войти в систему, они сообщают о тайм-ауте - они просто видят пустую страницу после определенного времени. Некоторые пользователи могут войти в систему без проблем. Похоже, это определяется тем, на какие курсы зарегистрирован пользователь. Например, пользователь-администратор без курсов может войти в систему без проблем.
Мне удалось увеличить значение таймаута в php.ini с 60 до 120 секунд и увидеть то же самое поведение. Используя $top, я вижу, что CPU, используемый www-data, подскакивает примерно до 99%, пока не сработает таймаут.
Я предполагаю, что происходит долгий вызов базы данных или что-то подобное.
Как мне увидеть сообщения об ошибках, записанные в журнал mysql? как мне увидеть сообщения об ошибках, записанные в журнал PHP? По умолчанию error_log (/var/log/php.log), который определен в моем php.ini, похоже, отсутствует? Как мне заставить PHP записывать ошибки в этот файл, чтобы я мог видеть, что происходит?
Moodle также регистрирует ошибки в logs/error.log, но это не проливает света на ситуацию.
Приветствуются любые хорошие предложения - спасибо!
решение1
Мы много занимались оптимизацией производительности Moodle, где я работал, и использовали профилирование PHP Xdebug, чтобы помочь с этим. Включение профилирования создаст файл *.cachegrind, который затем будет доступен для чтения многим читателям - я использую QCacheGrind на Windows или KCacheGrind на Linux. Затем вы сможете точно определить функцию, которая занимает много времени.
По памяти, это, вероятно, объем данных курса, которые он пытается загрузить, когда пользователь входит в систему. Если данных слишком много, и он берет все данные с сервера SQL, а не только необходимые, это может значительно замедлить работу. Это также можно определить с помощью медленного журнала, как упоминалось в комментарии выше, при условии, что именно SQL-запрос вызывает проблему производительности.
Я бы также определенно рекомендовал обновить ваш экземпляр Moodle до чего-то более нового, так как я знаю, что было много исправлений производительности, отправленных в репозиторий upstream с Moodle 2.2.3. Мы отправляли их в Moodle как официальный партнер Moodle.