веб-сервисы Amazon — приложение php неожиданно замедляется на AWS
Я использую старое приложение PHP (7.1) / NGINX (1.10.2) на AWS. Приложение работает на AWS более нескольких месяцев. Уже 2 дня мы испытываем проблемы с высокой задержкой. Но это не влияет на всю страницу. Только «интенсивные» процессы PHP, кажется, имеют проблемы с доставкой контента.
Я посмотрел так много других связанных тем сейчас, но ничто не указывало мне правильное направление.
Прежде всего: задержка не связана с сетью, так как я получаю эти задержки также при отправке запроса с сервера на localhost. Похоже, он не связан с базой данных (веб-сайт может подключаться к базе данных RDS в пределах <3 мс и ЦП БД ~ 20% и свободной памяти> 2 ГБ выглядит хорошо). Подключение к базе данных и выполнение некоторых запросов, сделанных веб-сервером, также работают нормально.
Сам веб-сервер не потребляет столько аппаратных ресурсов (процессор 10-25% и объем свободной памяти ~ 2 ГБ). Никакие cronjobs / запланированные задачи не установлены на этом сервере. Более 50% iNodes по-прежнему доступны на сервере. Сетевой шлюз получает / передает 8-25 МБ / с. Мы не отслеживаем никаких DoS вообще.
Я уже проверил и попытался настроить параметры PHP FPM (memory_limit, управление процессами, дочерние процессы и т. Д.). Здесь ничего не помогло. Деактивация / активация OPCache на самом деле не оказывает влияния.
Даже когда я использую AMI из предыдущей установки и запускаю новый сервер, такая же проблема задержки возникает снова. То же самое происходит при запуске приложения в нескольких зонах доступности.
Чтобы увидеть, где PHP тратит время, я использовал blackfire.io, и на самом деле он говорит мне, что он тратит большую часть времени на взаимодействия mysql (что неудивительно, поскольку приложение отправляет много грязных запросов с большим количеством объединений и т. Д. только производительность дорогая вещь здесь ..). Я также добавил некоторые отладочные данные в сам код. Обычно он завершается менее чем за 6 секунд (что, к сожалению, является нормальным средним значением, которое мы знаем из нашего поиска …)
Задержка в зависимости от целевой группы в среднем составляет 3-8 секунд, но мы также обнаруживаем много задержек, когда время ожидания запроса (30-60 секунд).
На данный момент я даже совершенно не уверен, что предоставить здесь. Я не хочу вставлять все связанные конфигурации и т.д. здесь. Поэтому, пожалуйста, скажите мне, что вам нужно, чтобы помочь здесь: /
Журнал php-fpm / nginx не регистрирует ничего, связанного с этой проблемой. То же самое с системным журналом. Единственное, что там можно найти, это Timed out waiting for reply from 91.189.89.199:123 (ntp.ubuntu.com) но даже date все еще синхронизируется .. PHP FPM slow-log (время ожидания установлено на 5 секунд) также пусто. Журналы ELB Access отслеживают только высокие значения «backend_processing_time».
На самом деле Nginx направляет запросы к корзине S3, и, кроме одного монтирования S3, у нас нет огромного количества временных файлов и прочего на сервере.
Запросы, отправленные в Интернет, выполняются, как и ожидалось. Похоже, DNS тоже не является проблемой (как обычно, может подключаться к БД и другим сервисам в интернете).
У кого-нибудь есть идеи, что может вызвать проблемы с задержкой? Что еще нужно /Можно быть исследованным ?? Я действительно ценю каждую помощь или вопрос, который может указать мне правильное направление.
С уважением.
Решение
Вы сказали это сами:
он говорит мне, что большую часть времени тратит на взаимодействия с MySQL (что неудивительно, поскольку приложение отправляет много грязных запросов с большим количеством объединений и т. д., и это единственная дорогостоящая вещь здесь …).
Это ваше приложение. Это вызывает засорение ваших «труб», поэтому некоторые люди будут испытывать это 30-60 ожидание. Теперь я бы также проверил наличие файла file_get_contents, для которого истекло время ожидания, поскольку это было неожиданно.
Кроме того, у меня была такая проблема прежде чем на сервере и я специально хочу указать мой комментарий:
Я больше не работаю в этой компании, и они потерпели неудачу — по юридическим причинам. Но! Когда я ушел, наш 30-секундный сайт загрузки упал до 3 секунд. и наш процессор линоды упал. решение было полностью — кеширование. Процесс инициализации нашего фреймворка был смехотворно дорогим с точки зрения производительности, и у внутреннего фреймворка не было встроенного кеширования. Все, что я могу сказать, это CACHE — кеш объектов, кеш страниц, используйте лак! Это исправит ваши проблемы (но у вас все равно будет дрянная структура, и когда вы не сможете кешировать, вам будет грустно .. вам придется исправлять плохо работающий код).
Я надеюсь, это поможет вам. Ах этот комментарий тоже:
Когда вы идете к врачу, и он говорит вам принять определенные лекарства — потому что он знает, что вы не будете слушать высказывания «перестаньте пить газировку и ешьте фастфуд» — именно поэтому для меня не было хорошего ответа — потому что правда Никаких настроек или быстрых исправлений на самом деле не применимо — только печальная истина в том, что мы должны резко изменить само наше веб-приложение.
Другие решения
Это явление вызвало комбинация роботов, несколько странных запросов от облачных серверов, запрашивающих только наш поиск (за несколько месяцев), кредиты RDS Cpu и в среднем слишком много запросов sql. Оказалось, что Cloudwatch Metrics для экземпляра среды t2 показывает среднее использование ЦП (20%) для каждого из 2 ядер (базовая производительность t2.medium + иногда более высокие значения 30-80%), и это постоянно убивает все кредиты ЦП один раз. Вы потеряли их всех, и тогда действительно трудно заработать новые кредиты (например, ночью).