Мы работали с парой веб-сайтов из инфраструктуры Amazons AWS уже около двух лет, и примерно два дня назад веб-сервер начал выходить из строя один или два раза в день с единственной ошибкой, которую я могу обнаружить:
HTTP/1.1 503 Service Unavailable: Back-end server is at capacity
CloudWatch не запускает никаких сигналов тревоги (CPU / Disk IO / DB Conn). Я попытался перейти на сайт через эластичный IP, чтобы пропустить ELB, и получил это:
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.
Я не вижу ничего необычного в логах apache и проверил, что они правильно вращаются. У меня нет проблем с доступом к компьютеру, когда он «выключен» через SSH и, просматривая список процессов, я вижу 151 процесс apache2, которые кажутся мне нормальными. Перезапуск apache временно устраняет проблему. Эта машина работает как веб-сервер за ELB. Любые предложения будут ценны.
Среднее использование ЦП: 7,45%, минимум: 0,00%, максимум: 25,82%
Среднее использование памяти: 11,04%, минимум: 8,76%, максимум: 13,84%
Среднее использование свопов: N / A, минимум: N / A, максимум: N / A
Использование дискового пространства для / dev / xvda1, установленного на / Среднее: 62,18%, Минимум: 53,39%, Максимум: 65,49%
Позвольте мне уточнить, я думаю, что проблема связана с отдельным экземпляром EC2, а не с ELB, я просто не хотел исключать это, даже если мне не удалось достичь эластичного IP. Я подозреваю, что ELB просто возвращает результаты попадания в настоящий экземпляр EC2.
Обновление: 2014-08-26 Я должен был обновить это раньше, но «исправить» было сделать снимок «плохого» экземпляра и запустить получившийся AMI. С тех пор оно не уменьшилось. Я просматривал проверку работоспособности, когда у меня все еще возникали проблемы, и я мог перейти на страницу проверки работоспособности ( curl http://localhost/page.html), даже когда у меня возникали проблемы с емкостью с помощью балансировщика нагрузки. Я не уверен, что это была проблема проверки работоспособности, но так как никто, включая Amazon, не может дать лучший ответ, я отмечаю его как ответ. Спасибо.
Обновление: 2015-05-06 Я подумал, что вернусь сюда и скажу, что частью проблемы, которой я сейчас твердо убежден, были настройки проверки работоспособности. Я не хочу исключать их проблемы с AMI, потому что она определенно улучшилась после запуска заменяющего AMI, но я обнаружил, что наши проверки работоспособности были разными для каждого балансировщика нагрузки и что у него больше всего проблем был действительно агрессивный нездоровый порог и время ожидания ответа. Наш трафик имеет тенденцию к непредсказуемым скачкам, и я думаю, что между агрессивными настройками проверки работоспособности и всплесками трафика это был идеальный шторм.
Ответы:
Вы получите «Внутренний сервер загружен», когда балансировщик нагрузки ELB выполняет свои проверки работоспособности и получает «страницу не найдена» (или другую простую ошибку) из-за неправильной конфигурации (обычно с хостом NameVirtual).
Попробуйте очистить папку с файлами журналов с помощью пользовательского агента "ELB-HealthChecker". например
Как правило, это даст вам ошибку 4x или 5x, которую легко исправить. например, Flooding, MaxClients и т. д. дают слишком много проблем.
К вашему сведению, Amazon: почему бы не показать возвращенный ответ на запрос? Даже код состояния поможет.
источник
Я просто столкнулся с этим вопросом сам. Amazon ELB вернет эту ошибку, если не будет исправных экземпляров. Наши сайты были неправильно настроены, поэтому проверка работоспособности ELB не удалась, из-за чего ELB вывел два сервера из ротации. При нулевых исправных сайтах ELB вернул 503 Служба недоступна: внутренний сервер загружен.
источник
[РЕДАКТИРОВАТЬ после лучшего понимания вопроса] Не имея опыта работы с ELB, я все еще думаю, что это звучит подозрительно, как ошибка 503, которая может появиться, когда Apache запускает Tomcat и устанавливает соединение.
В результате, если Apache доставляет больше запросов на соединение, чем может обработать серверная часть, входные очереди серверной части заполняются до тех пор, пока не будет принято больше соединений. Когда это происходит, соответствующие выходные очереди Apache начинают заполняться. Когда очереди заполнены, Apache выдает 503. Из этого следует, что то же самое может произойти, когда Apache является бэкэндом, а внешний интерфейс выполняет поставку с такой скоростью, чтобы заполнить очереди.
(Гипотетическое) решение заключается в определении размера входных разъемов внутреннего интерфейса и выходных разъемов внешнего интерфейса. Это превращается в баланс между ожидаемым уровнем затопления и доступной оперативной памятью задействованных компьютеров.
Чтобы это произошло, проверьте настройки maxclients и следите за занятыми работниками в Apache (mod_status.). Если возможно, сделайте то же самое с тем, что есть в ELB, которое соответствует журналу ожидания соединителя Tomcats, maxthreads и т. Д. Короче, посмотрите на все, что касается входных очередей Apache и выходных очередей ELB.
Хотя я полностью понимаю, что это не применимо напрямую, эта ссылка содержит руководство по настройке размера для соединителя Apache. Вам нужно будет изучить соответствующие технические особенности очереди ELB, а затем выполнить математику: http://www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-on-tomcat-during- полный дс /
Как отмечается в комментарии ниже, переполнение коннектора Apache не является единственной возможностью. Если некоторые запросы обслуживаются медленнее, чем другие, более высокое их соотношение также может привести к заполнению очередей соединителя. Это было правдой в моем случае.
Кроме того, когда это случилось со мной, я был озадачен тем, что мне пришлось перезапустить службу Apache, чтобы снова не получать обслуживание 503: s. Простого ожидания затопления разъема было недостаточно. Я так и не понял, но можно предположить, что Apache обслуживает из своего кэша?
После увеличения числа рабочих и соответствующих настроек pre-fork maxclients (это был многопоточный Apache в Windows, у которого есть пара других директив для очередей, если я правильно помню), проблема 503 исчезла. На самом деле я не занимался математикой, а просто настраивал значения до тех пор, пока не смог наблюдать широкий запас по пиковому потреблению ресурсов очереди. Я позволил этому идти в этом.
Надеюсь, это помогло.
источник
Вы можете увеличить значения проверки работоспособности elb, чтобы один медленный ответ не вытащил сервер из elb. Лучше, чтобы несколько пользователей получали услугу недоступно, чем когда сайт закрыт для всех.
РЕДАКТИРОВАТЬ: мы можем обойтись без предварительного прогрева кэша, увеличив время проверки работоспособности до 25 секунд ...... через 1-2 минуты ... сайт реагирует как черт
РЕДАКТИРОВАТЬ :: просто запустите кучу по требованию, и когда ваши инструменты мониторинга покажут руководству, насколько быстро вы работаете, тогда просто предоплатите RI amazon: P
РЕДАКТИРОВАТЬ: это возможно, одного зарегистрированного экземпляра elbend недостаточно. просто запустите еще несколько и зарегистрируйте их в elb, и это поможет вам сузить проблему
источник
Уже несколько лет, но, надеюсь, это поможет кому-то.
Я видел эту ошибку, когда экземпляру за ELB не был назначен надлежащий публичный IP-адрес. Мне нужно было вручную создать Elastic IP и связать его с экземпляром, после которого ELB почти мгновенно поднял его.
источник