У меня довольно загруженный веб-сервер. Это довольно стандартно: Apache с mod_php во FreeBSD 7.1. Он подключается к отдельному серверу MySQL. Он обслуживает множество статических изображений.
Пользователи жаловались на медленное время ответа. Сегодня у меня очень медленная загрузка, затем в моем браузере появляется сообщение «Не удалось подключиться, попробуйте еще раз».
Сверху видно, что сервер практически простаивает! И все же он отказывался от дальнейших связей. Примерно через минуту он снова начал отвечать (хотя все еще медленно).
netstat -s включает
161796 listen queue overflows
но я не уверен, что это проблема, так как я увеличил somaxconn.
Я, должно быть, исчерпал лимит ресурсов. На что еще следует обратить внимание, чтобы диагностировать проблему?
Первый. Вашим узким местом почти наверняка является серверная часть MySQL (или сеть между веб-интерфейсом и серверной частью). Итак, у вас есть неактивный интерфейс.
Второй. Вы можете использовать статический сервер через nginx / lighttpd, если это действительно высоконагруженный веб-сервер.
Третий. Я разместил краткое руководство по Настройка sysctl FreeBSD, вы можете найти это полезным.
PS. Также существует директива apache ListenBacklog, которую вы можете увеличить вместе с MaxClients.
MaxClients от Apache - большой. Вы можете просмотреть текущее количество клиентов / подключений, включив mod_status и запустив "apachectl status" или загрузив "http: // localhost / статус-сервера"в веб-браузере с веб-сервера
Возможно, у вас относительно небольшой MaxClients, пакеты поддержки активности с длительным таймаутом и довольно много запросов.
Браузеры обычно будут удерживать соединение открытым в течение 30 секунд или около того, если вы им разрешите, поэтому не устанавливайте поддержку активности слишком долго.
Наличие поддержки активности в течение короткого периода полезно для ваших пользователей, но при этом расходует ресурсы. Вы можете видеть табло Apache (то есть страницу статуса сервера?)? Все ли ваши слоты заняты в состоянии «K»?
В общем, смешивание обслуживания приложения (вашего PHP-приложения) и статических файлов большого объема - плохая идея, у них разные требования. Толстый процесс Apache (например, с PHP) будет тратить много памяти на обслуживание статических изображений, которые вместо этого может обслуживать тонкий. Рассмотрите возможность размещения их на отдельных наборах физических серверов или на отдельных экземплярах серверов на одном наборе серверов (с очень разными конфигурациями).
В зависимости от масштаба вашего статического изображения вы можете запустить что-то вроде lighttpd рядом с ним для обслуживания изображений. Как правило, лучше работать только со статическими изображениями. Lighttpd (lighty) - это просто lighttpd, который будет обслуживать статический контент намного быстрее, а немного настроенный, вероятно, не столкнется с этими ограничениями. То же самое можно было бы сделать с Apache, но Apache немного здоровен только для статического контента.
Выполняет ли он обратный поиск в DNS? (отключите их)
Авахи-демон запущен? (убей это)