Мы запускаем LAMP + memcached на инстансе Amazon EC2 Ubuntu 9.10 x64 xlarge. Этот сервер обрабатывает несколько сотен запросов в секунду, из которых около 60% являются статическими, а все остальные каким-то образом взаимодействуют с mysql и / или memcached. Этот сервер страдает от двух проблем с производительностью, которые, возможно, связаны и которые сложно диагностировать. Вся приведенная ниже статистика была собрана с помощью CloudWatch, munin или vmstat / iostat / top, если не указано иное.
Первая проблема - это повторяющиеся регулярные всплески высокого iowait каждые несколько минут, в течение которых большинство процессов apache одновременно iowait в течение примерно 10-30 секунд, прежде чем все отключаются. В течение этого времени не происходит увеличения нагрузки на диск или сеть, очередь на дисках остается низкой, подкачки не происходит и т. Д.
Что еще более серьезно, в периоды пиковой нагрузки сервер иногда внезапно испытывает резкую потерю производительности, снижая количество обслуживаемых запросов до ~ 1/3 от того, что было моментом ранее. После запуска это падение производительности может длиться от 2 до 8 часов, прежде чем снова внезапно вернуться к полной производительности. Когда это происходит, система словно перестает что-либо делать. Использование ЦП, нагрузка на диск и нагрузка на сеть (по данным CloudWatch) одновременно снижаются пропорционально, но конкуренции за диск нет. Дисковая очередь и пропускная способность постоянно падают и значительно ниже максимума, особенно во время этих спадов. РЕДАКТИРОВАТЬ: эта проблема была решена. В Apache заканчивались рабочие процессы, и по какой-то причине он решил, что это хорошая причина для полного падения производительности, даже для тех процессов, которые работали нормально.
Исключение составляют операции чтения по сети, которые остаются такими же высокими, как и раньше, что указывает на то, что к серверу по-прежнему осуществляется доступ в таком же большом объеме, как и раньше. Если мы попытаемся связаться с сервером сами, когда это произойдет, сервер будет работать очень медленно и часто просто разрывает соединение, прежде чем запрос сможет быть обработан. Следует отметить, что ни использование памяти, ни загрузка ЦП не являются особенно высокими в любое время, независимо от того, падает производительность в настоящее время: процент ЦП редко превышает 10%, диск не заполнен или перегружен. Мы еще не смогли собрать данные об эффективности свопинга во время этих падений, но пытаемся это сделать.
На самом деле у нас мало идей о том, что могло вызвать эти загадочные проблемы, и мы все больше обеспокоены тем, что это может быть проблемой (или недостатком) самого EC2. Тот факт, что массивные провалы всегда возникают, когда наш трафик достигает пика (хотя, опять же, это не означает, что сервер близок к максимальному исчерпанию доступных ресурсов), не может быть просто совпадением.
Все базы данных и журналы MySQL размещаются на томе EBS, а весь статический контент размещается на отдельном томе EBS. Apache обслуживает 160–240 запросов в секунду и MySQL 180–200 запросов в секунду, с ~ 0% медленными запросами и ~ 90% успешностью из memcached. Средняя нагрузка обычно колеблется в районе 3. Ведение журнала доступа Apache отключено, чтобы минимизировать доступ к диску.
Скорее всего (как было отмечено, вы нашли решение второй проблемы), эти проблемы связаны с конфигурацией или иным образом. EC2 / EBS / другие облачные технологии не являются причиной этого. Это проблемы, которые могут возникнуть в любой среде, что противоречит полученному ранее ответу.
Также - Amazon предоставляет SLA. Бывают второстепенные ситуации, хотя и крайне редко, когда некоторые ресурсы могут вступить в конфликт. ОДНАКО, это маловероятно, учитывая ваше текущее использование. Я бы продолжил диагностическое исследование различных спорных моментов, а также поговорил бы с техническими группами Amazon Web Services. Также загляните на их форумы, так как там обычно есть очень знающие люди. Возможно, вы знаете о форумах, но на всякий случай - проверьте их здесь: https://forums.aws.amazon.com/index.jspa
Кроме того, просто с точки зрения архитектуры, думали ли вы о распределении этой нагрузки между несколькими экземплярами EC2 и балансировке нагрузки? Это вариант, который должен решить некоторые из этих проблем. Кроме того, судя по архитектуре, которую вы обсуждаете, в целом может быть лучше, если вы разделите несколько менее мощных экземпляров и распределите работу. Другое преимущество заключается в том, что если ваш сайт / услуги продолжат расти, вы можете расширяться по горизонтали, а не по вертикали, причем последнее, конечно, будет ограничено.
Поскольку EC2 - это среда общего хостинга (ваш хост использует то же оборудование, что и другие хосты), вы можете увидеть существенные различия в операциях ввода-вывода. Тома EBS, по сути, являются NAS и используют одну и ту же сетевую карту с сетевым трафиком. Каждый физический хост имеет подключение к магистрали только 1 Гб. Таким образом, у вас возникают конфликты не только с сетевыми операциями других клиентов, но и с их и вашими дисками. На практике конкуренция в сети обычно не является проблемой, если только вы не используете устройство совместно со многими другими клиентами с высоким трафиком. Некоторые из них можно обойти, используя более крупные экземпляры (более крупные экземпляры занимают больший процент коробки и, следовательно, имеют меньше общих ресурсов).
Какие типы иопс вы испытываете на пике и в эти проблемные периоды? (столбец sar -d tps)
Какое у вас время кражи в эти периоды? (iostat -x 1 или sar -u).
Вы можете увеличить пропускную способность IOP, что должно помочь вашему времени ожидания, за счет программного RAID-массива нескольких томов EBS вместе. Звучит глупо, но на самом деле работает. Это не решит проблем с конфликтами в сети, но я очень сомневаюсь, что с вашим трафиком вы переполняете ссылку. Однако возможно, что это другой клиент, который причиняет вам некоторую боль.
Иногда, к сожалению, простое решение этой проблемы - просто повторно запустить экземпляр. Скорее всего, он появится на другом хосте с другими общими клиентами. Клиенты EC2 довольно часто запускают инстансы, запускают тесты и повторно запускают тесты, если они недовольны результатами.
Еще одна рекомендация - разделить уровни Интернета и базы данных на разные серверы. Один сервер с web / db обычно является плохой идеей по большому количеству причин, и в этом случае, вероятно, еще больше затрудняет диагностику узкого места.
в первую очередь извините, что у вас возникли серьезные проблемы с загрузкой вашего сайта, и, насколько мне известно, все это должно быть указано в политике SLA в отношении доступности и производительности приложений, вы должны иметь право на кредиты.
Использование общего общедоступного облака, как прокомментировал пользователь 37899, не является идеальной платформой для этого, если это критически важное приложение и интенсивная работа. История совместного использования заключается не только в том, что вы не знаете наверняка, где работают ваши процессы, но и в том, что на вашу производительность влияют другие клиенты в этой сети. хранилище, скорее всего, является общим ресурсом в этой конкретной сетке, что вызывает снижение производительности.
Развертывание Amazon x64 xLarge должно быть правильно определено, однако, как уже упоминалось, дисковые ресурсы, выделенные по их объему и конфигурации рейда, по-прежнему получают доступ из общего пула.
Мне было бы интересно узнать немного больше о том, что у вас есть, а также о некоторых других счетчиках производительности и архитектуре базы данных, чтобы помочь лучше всего предоставить соответствующий ответ для решения этой проблемы. и хотя мне кажется, что лучшим решением было бы иметь хотя бы уровень вашей базы данных на голом железе или в частном облаке с использованием собственного выделенного оборудования.
не стесняйтесь написать мне, я доступен для чата, удачи.