Проблема производительности EC2
Только что провел две недели на этой неделе, устраняя проблему с разработкой в EC2, зарегистрированную оффшорной командой.
уже несколько недель без проблем запускаю apache/tomcat версии 7.0.21 в нескольких экземплярах Dev в EC2.
затем основные проблемы с производительностью в D3 env. перезапустил сценарии на берегу без проблем в первый раз.
опять офшорные зарегистрированные дефекты в D3 env, на этот раз они запускали скрипты в клоне D2 не было проблем. Утром снова запускал сценарии в D3 на берегу, и на этот раз у него были серьезные проблемы.
было ощущение, что это была инфраструктура, но не было никакого способа доказать это.
настроенный контейнер сервлета, смотрящий на сборщик мусора, кучу, пул jdbc - в песочнице env, ничего страшного.
затем скрипты передаются в образе клона D3. все зарегистрированные дефекты пройдены. мы ничего не изменили.
это похоже на проблему EC2, либо на виртуальных машинах Xen, в сети или RDS. Понятия не имею, что это было.
Как вы можете изолировать ошибку в облаке, когда вы летите вслепую. Без видимости инфраструктуры, где вы начинаете?
У кого-нибудь есть похожие проблемы?
Можно ли отслеживать инфраструктуру EC2?
1 ответ
Перри, похоже, вы правильно диагностировали проблему (ложное / случайное / неожиданное поведение в EC2 почти всегда является побочным эффектом ухудшенного оборудования хоста) - единственный способ подтвердить это - это публиковать сообщения на форумах EC2 или открывать заявку в службу поддержки. и попросите их выяснить, в какой момент команда EC2 может подтвердить / отклонить неисправное оборудование.
Обходной путь, независимо от того, получили вы это подтверждение или нет, всегда заключается в выключении и повторном запуске вашей виртуальной машины, которая будет размещать ее на другом оборудовании. (Вы можете видеть это на форумах EC2 регулярно).
В будущем я бы сделал это ожидаемым первым шагом в устранении совершенно случайных проблем в EC2, чтобы сделать именно это; перезапустите экземпляр.
По-прежнему нет способа получать оповещения в реальном времени о состоянии базового оборудования в EC2, даже те немногие уведомления по электронной почте, которые проходят при сбое оборудования, кажутся случайными, поскольку аппаратное обеспечение все еще может выйти из строя, и вы никогда не получите одно из этих сообщений электронной почты монитора.,
Вы можете попробовать направить службу мониторинга на ваши отдельные экземпляры, такие как pingdom или wasitup, но это простые тесты ping, и я не знаю, сработают ли они для вас.
В качестве альтернативы, если вы можете сузить сбои, которые вы видели, до конкретных вещей, которые произвольно давали сбой (например, определенная операция, которая выходит из строя в EC2, когда аппаратное обеспечение начинает отказывать), вы могли бы написать системный скрипт / задание cron, которое просто запускает эту точную службу каждый раз. 1 мин или 10 мин и сообщает об ошибке.
Это подход канарейка в угольной шахте и ничего научного или точного, но он может немного помочь и позволит вам уловить проблему, прежде чем ваши пользователи.