Назад | Перейти на главную страницу

Как определить, подключен ли экземпляр EC2 LAMP к сети?

Я много лет размещал веб-сайт на инстансе Amazon EC2. В последнее время пользователи жаловались на медленную работу и сбои соединения. Я проверил использование памяти и ЦП как на сервере EC2 LAMP, так и на сервере базы данных RDS, и оба значения находятся в пределах номинального диапазона.

Веб сервер

Сервер БД

Используя netstat, я вижу в любой момент времени около 1000 подключений к веб-серверу:

$ netstat -ant | wc -l 1089 Я видел это число до 1480 ранее в тот день, когда возникают проблемы.

Все это заставляет меня думать, что машина обнаружена в сети. Т.е., доступной пропускной способности сети недостаточно для обслуживания всех запрошенных данных. Я думаю, что эта нехватка полосы пропускания может быть бутылочным горлышком машины.

Может ли кто-нибудь подсказать, как определить, действительно ли эта машина ограничена пропускной способностью сети? Было бы чрезвычайно полезно, если бы я мог построить график использования сети, который указывает на проблему. Я не уверен, как это может выглядеть, но я представляю себе график, показывающий твердое плато в периоды низкой производительности.

Я попытался прикрепить сюда снимок экрана с графиками мониторинга AWS:

РЕДАКТИРОВАТЬ: Я наблюдал за сервером сегодня утром, когда начались медленные действия, и я не смог найти узкое место в ресурсах. Память веб-сервера и использование процессора кажутся нормальными. Память сервера db и загрузка процессора кажутся нормальными. Я не вижу чрезмерного использования пропускной способности сети и все же сервер очень медленно отвечает на запросы страницы. Затем проблема внезапно улетучивается.

Хотя проблема сохраняется, с точки зрения пользователя (при использовании Firefox) это выглядит так, как будто в рукопожатии TLS что-то медленное, что выглядит очень нравится эта проблема но на моем сервере Apache HostnameLookup установлено значение ВЫКЛ..

Узкое место, каким бы оно ни было, похоже, препятствует установлению сетевых подключений. Во время медлительности общее количество сетевых подключений было стабильным около 800:

netstat -n | wc -l

В то время как соединения с базой данных с веб-сервера были очень устойчивыми, около 200:

netstat -an | grep <db-server-ip-here> | wc -l

Как только проблема исчезнет (что кажется довольно нестабильным), эти числа Прыгать увеличив эти значения примерно вдвое, и сервер заработает молниеносно.

У нас была аналогичная проблема в одном из наших кластеров статистики более высокой скорости на Speedtest.net - и мы обнаружили, что решение в нашем случае не опубликовано в AWS; нам пришлось работать напрямую с командой Nitro, чтобы решить эту проблему.

У нас была низкая пропускная способность и машина с низким PPS (~ 10 000 пакетов в секунду), которая постоянно теряла пакеты. Мы не могли понять, почему мы теряем пакеты, поскольку полностью соответствовали общедоступным рекомендациям по производительности машины. Эта машина была агрегатором статистики, поэтому тысячи машин отправляли ей дейтаграммы UDP. Счетчик «потоков» является ключевым моментом.

Оказывается, если у вас есть какие-либо группы безопасности на прослушивающем порту, которые ограничивают отправку диапазонов IP-адресов, AWS налагает ограничение conntrack для этого данного порта. В случае превышения лимита количества подключений AWS автоматически отбрасывает пакеты. Статистических данных, подтверждающих это, нет, за исключением «обрезанных» пиков на сетевых графиках. Инстансы большего размера имеют большие квоты conntrack.

Решение состоит в том, чтобы установить для входящего разрешенного диапазона IP-адресов источника значение 0.0.0.0 для данного сервисного порта - это отключает отслеживание соединений на стороне AWS и снимает ограничение conntrack. В конечном итоге это означает, что вам придется самостоятельно управлять брандмауэром с помощью тщательного разделения на подсети и брандмауэра ядра машины.

Я не могу сказать, сталкиваетесь ли вы с той же проблемой, но мы столкнулись с этим, что вызвало необъяснимые проблемы с сетью в AWS.