Мы запускаем несколько веб-сайтов на базе инфраструктуры Amazon 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%
Среднее использование свопа: н / д, минимум: н / д, максимум: н / д
Использование дискового пространства для / 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), поэтому он потребуется время, чтобы увидеть, что экземпляр снова здоров.
Вы получите сообщение «Внутренний сервер загружен», когда балансировщик нагрузки ELB выполнит свои проверки работоспособности и получит сообщение «Страница не найдена» (или другая простая ошибка) из-за неправильной конфигурации (обычно с хостом NameVirtual).
Попробуйте найти папку с файлами журнала с помощью пользовательского агента "ELB-HealthChecker". например
grep ELB-HealthChecker /var/log/httpd/*
Обычно это дает ошибку в 4 или 5 раз, которую легко исправить. например Флуд, MaxClients и т. Д. Придают слишком большое значение проблеме.
К вашему сведению, Amazon: почему бы не показать возвращенный ответ на запрос? Даже код статуса поможет.
Я сам столкнулся с этой проблемой. Amazon ELB вернет эту ошибку, если нет исправных экземпляров. Наши сайты были неправильно настроены, поэтому проверка работоспособности ELB завершилась ошибкой, из-за чего ELB отключил два сервера от ротации. При отсутствии работоспособных сайтов ELB возвратил 503 Service Unavailable: Back-end сервер загружен.
[ИЗМЕНИТЬ после лучшего понимания вопроса] Не имея никакого опыта работы с ELB, я все еще думаю, что это подозрительно похоже на ошибку 503, которая может быть выдана, когда Apache выходит на Tomcat и заливает соединение.
В результате, если Apache доставляет больше запросов на соединение, чем может быть обработано серверной частью, очереди ввода серверной части заполняются до тех пор, пока больше подключений не будет принято. Когда это происходит, соответствующие очереди вывода Apache начинают заполняться. Когда очереди заполнены, Apache выдает ошибку 503. Из этого следует, что то же самое может произойти, когда Apache является серверной частью, а интерфейс выполняет доставку с такой скоростью, чтобы очереди заполнялись.
(Гипотетическое) решение состоит в том, чтобы определить размеры входных разъемов внутреннего и выходного разъемов внешнего интерфейса. Это превращается в баланс между ожидаемым уровнем переполнения и доступной оперативной памятью задействованных компьютеров.
Итак, когда это происходит, проверьте настройки maxclients и отслеживайте занятых рабочих в Apache (mod_status.). Сделайте то же самое, если возможно, с любым ELB, который соответствует backlog коннектора Tomcats, maxthreads и т.д. Короче говоря, посмотрите на все, что касается входных очередей Apache и выходных очередей ELB.
Хотя я полностью понимаю, что это не применимо напрямую, эта ссылка содержит руководство по определению размеров коннектора Apache. Вам нужно будет изучить соответствующие технические аспекты очереди ELB, а затем выполнить математические вычисления: http://www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-on-tomcat-during-full-gc/
Как видно из комментария ниже, перегрузка коннектора Apache резкий скачок трафика - не единственная возможность. Если одни запросы обслуживаются медленнее, чем другие, большее их соотношение также может привести к переполнению очередей соединителей. Так было в моем случае.
Кроме того, когда это случилось со мной, я был сбит с толку тем, что мне пришлось перезапустить службу Apache, чтобы снова не получить 503: s. Просто переждать флуд коннектора было недостаточно. Я так и не понял, но, возможно, можно предположить, что Apache обслуживает из своего кеша?
После увеличения количества воркеров и соответствующих настроек maxclients перед форком (это был многопоточный Apache в Windows, у которого есть пара других директив для очередей, если я правильно помню), проблема 503 исчезла. На самом деле я не занимался математикой, а просто настраивал значения до тех пор, пока не смог увидеть большой запас по пиковому потреблению ресурсов очереди. Я позволил этому уйти.
Надеюсь, это помогло.
вы можете увеличить значения средства проверки работоспособности elb, чтобы один медленный ответ не отвлекал сервер от elb. Лучше, если услуга недоступна для нескольких пользователей, чем для всех не работает сайт.
РЕДАКТИРОВАТЬ: мы можем обойтись без предварительного подогрева кеша, увеличив тайм-аут проверки работоспособности до 25 секунд ... через 1-2 минуты ... сайт чертовски отзывчив
РЕДАКТИРОВАТЬ :: просто запустите кучу по запросу, и когда ваши инструменты мониторинга покажут руководству, насколько быстро вы работаете, просто внесите предоплату RI amazon: P
EDIT: возможно, одного зарегистрированного экземпляра backend elb недостаточно. просто запустите еще несколько и зарегистрируйте их в elb, и это поможет вам сузить проблему
С опозданием на несколько лет, но, надеюсь, это кому-то поможет.
Я видел эту ошибку, когда экземпляру за ELB не был назначен надлежащий общедоступный IP-адрес. Мне нужно было вручную создать эластичный IP-адрес и связать его с экземпляром, после чего ELB практически мгновенно принял его.