Диагностика нагрузки на сервер / медлительность
У меня есть машина с Ubuntu Server, которая сегодня испытывала серьезные проблемы без видимой причины. Две службы, которые он выполняет, - apache2 и ssh, и в течение периода, когда сервер работал медленно, я тоже не смог получить к нему доступ.
Я проверял журналы в /var/logs/
, Это не пролило свет на этот вопрос, но опять же, я не уверен, что я ищу...
Как я могу диагностировать проблему, чтобы я мог принять меры, чтобы предотвратить ее повторение в будущем?
Полная история / детали:
- Сегодня во время урока я дал упражнение (своего рода экзамен) примерно 35 студентам-информатикам. Они должны были получить доступ к двум экземплярам Trac, которые я ранее установил на своем сервере. У каждого студента были свои учетные данные.
- Сервер на самом деле является виртуальной машиной VMWare с Ubuntu 11.10 и живет в той же сети, из которой студенты получали к ней доступ.
- Когда экзамен начался, студенты вводили адрес, который им дали в своих веб-браузерах. Трое из них действительно смогли увидеть первую веб-страницу trac, но после этого сервер перестал отвечать на запросы (браузеры просто продолжали ждать, пока не истекло время ожидания)
- Я также попытался получить доступ к консоли сервера через SSH и через VMWare VSphere Client, но в обоих случаях консоль также полностью не отвечала.
- Я не был уверен, что еще попробовать, поэтому я перезагрузил виртуальную машину. Он загрузился, но ничего не изменилось после этого: все службы, которые я упомянул выше, остались без ответа.
- Я загрузил его снова - ничего нового.
- В этот момент я отправил всех домой, так как у нас больше не было времени на экзамен. Когда около половины из них выключили ноутбук, сервер снова начал отвечать. Я не думаю, что это было совпадением, но до сих пор не могу объяснить, какие именно были проблемы с сервером и как их предотвратить.
Обновить
Аппаратное обеспечение, назначенное этой конкретной виртуальной машине:
- 1 процессор
- 512 МБ памяти
- 60 ГБ на жестком диске (в настоящее время 80% свободного места)
1 ответ
Судя по вашему обновлению, 512 МБ ОЗУ НИЧЕГО достаточно для 35 одновременных учеников, если вы не выполнили настройку из коробки (и она может не сработать, даже настроенная). Если у вас есть возможность сделать это, увеличьте ограничение памяти до 2 ГБ. Это должно обеспечить безопасную прокладку, чтобы коробка не менялась так сильно, чтобы она не реагировала.
Кроме того, вы можете начать с отключения поддержки активности в вашем httpd.conf, если они включены, чтобы соединения не оставались открытыми. Далее будет отключение любых модулей httpd, которые вы не используете, чтобы попытаться минимизировать использование памяти для каждого процесса. В-третьих, если вы не смогли увеличить лимит памяти, измените MaxClients в вашем httpd.conf на 8 (если вам удалось увеличить ОЗУ сервера, попробуйте RAM/64 в качестве значения). В-четвертых, хотя это может показаться нелогичным, поскольку у вас мало памяти, установите APC для кэширования кода операции PHP. Вы пожертвуете небольшим объемом оперативной памяти для кеша, но соединения могут обслуживаться немного быстрее, освобождая их для других людей.
В конце концов, посмотрите на переключение httpd в режим "работник / событие" и запуск PHP под FastCGI или на более легкий веб-сервер, такой как nginx.