Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
MicroInstance имеет сильно выраженный пониженный приоритет, что проявляется как временной подвисание виртуальной машины при большой нагрузке. Они это объясняют, что полностью всеми доступными ECU вы можете воспользоваться только временно. Т.е. в качестве временного ускорителя (они называют это burst).
Пруф:
«Micro Instance 613 MB of memory, up to 2 ECUs (for short periodic bursts), EBS storage only, 32-bit or 64-bit platform»
Пруф от пользователя
Пруф:
«Micro Instance 613 MB of memory, up to 2 ECUs (for short periodic bursts), EBS storage only, 32-bit or 64-bit platform»
Пруф от пользователя
Действительно, я часто наблюдал такой эффект на 32х битной Windows Server 2008 на Микро инстансе. Однако, там был и MS SQL и ASP.NET приложение.
Сервер гарантировано подвисал на примерно 10 минут после запуска loadimpact. Тестирование показывает, что в данной конфигурации сервер принципиально более живучий.
Ну а если таки подвиснет, load balancer его уже через 12 секунд объявит unhealthy и исключит.
Сервер гарантировано подвисал на примерно 10 минут после запуска loadimpact. Тестирование показывает, что в данной конфигурации сервер принципиально более живучий.
Ну а если таки подвиснет, load balancer его уже через 12 секунд объявит unhealthy и исключит.
А что станет с пользовательским запросом во время зависания?
Мы оба отлично знаем, что будет timeout.
Micro проработал в load balancing всю ночь, за это время зарегистрировано 17 страниц, которые рендерились дольше 7 секунд (в первую очередь по причине DB). Пока он не засыпал
Micro проработал в load balancing всю ночь, за это время зарегистрировано 17 страниц, которые рендерились дольше 7 секунд (в первую очередь по причине DB). Пока он не засыпал
Ну мы также оба знаем, что существуют техники это побороть, если пользовательский запрос настолько важен для системы.
Господа,
а что делать если
1) на кластере планируется обрабатывать транзакции и ни в коем случае нельзя терять транзакцию?
2) если транзакция не прошла за секунду (1000мс), то обработать её по бизнес-логике ещё хуже, чем потерять.
Какие техники существуют? Подскажите? Дайте ссылки, пож.
а что делать если
1) на кластере планируется обрабатывать транзакции и ни в коем случае нельзя терять транзакцию?
2) если транзакция не прошла за секунду (1000мс), то обработать её по бизнес-логике ещё хуже, чем потерять.
Какие техники существуют? Подскажите? Дайте ссылки, пож.
Наверное блин взять распределенный кластер по разным ДЦ?
Вы напоминаете товарища, который софт для слежения за сердечниками поставил на low availability amazon instance и когда EBS упал (или что-то там) вся эта система легла…
Нельзя HA ставить в одно место и тем более в клауды (клауды — технология не обкатанная, лет 10 еще пройдет прежде чем все нюансы будут ясны и баги исправлены).
Вы напоминаете товарища, который софт для слежения за сердечниками поставил на low availability amazon instance и когда EBS упал (или что-то там) вся эта система легла…
Нельзя HA ставить в одно место и тем более в клауды (клауды — технология не обкатанная, лет 10 еще пройдет прежде чем все нюансы будут ясны и баги исправлены).
Ну, а что делать то? Что делать?
Всё дело в цене на билет.
Конечно, когда мы станем фейсбуками — будет собственный датацентр, а пока не вижу альтернативы по возможности масштабирования производительности.
Ну, и по надёжности: покупка выделенного сервера по-моему хуже, чем два кластера в разных зонах.
(Не говоря уже, что он вообще не масштабируется.)
Всё дело в цене на билет.
Конечно, когда мы станем фейсбуками — будет собственный датацентр, а пока не вижу альтернативы по возможности масштабирования производительности.
Ну, и по надёжности: покупка выделенного сервера по-моему хуже, чем два кластера в разных зонах.
(Не говоря уже, что он вообще не масштабируется.)
Я не уверен, что я точно правильно понял вашу задачу.
Я бы сделал так:
Сервер, который получает запрос и ставит его в очередь, указывая время валидности. У амазона есть aws.amazon.com/sqs/ — Simple Queue Service, использую и полностью им счастлив.
Сервер(а) обрабатывающие запросы из очереди, которые проверяют, не истек ли срок годности запроса.
Я бы сделал так:
Сервер, который получает запрос и ставит его в очередь, указывая время валидности. У амазона есть aws.amazon.com/sqs/ — Simple Queue Service, использую и полностью им счастлив.
Сервер(а) обрабатывающие запросы из очереди, которые проверяют, не истек ли срок годности запроса.
Спасибо
Кажись вот это утверждение решает проблему:
Но хотелось бы уточнить.
Как из вашего опыта, возможно ли так сделать?
Что сообщение приходит в очередь, и лимит блокировки 500мс, если его не обработал один микро, то другой берёт с лимитом 500мс, если второй не обработал, то сообщение убивается.
(Через 1000мс придёт новое сообщение с обновлённой ситуацией)
Кажись вот это утверждение решает проблему:
When a message is received, it becomes “locked” while being processed. This keeps other computers from processing the message simultaneously. If the message processing fails, the lock will expire and the message will be available again.
Но хотелось бы уточнить.
Как из вашего опыта, возможно ли так сделать?
Что сообщение приходит в очередь, и лимит блокировки 500мс, если его не обработал один микро, то другой берёт с лимитом 500мс, если второй не обработал, то сообщение убивается.
(Через 1000мс придёт новое сообщение с обновлённой ситуацией)
Проект на анонсирован на хаббре habrahabr.ru/blogs/development/122168/ и успешно справляется с одноименным эффектом. «Потерь» среди микро инстансов не наблюдаю.
> То есть примерно 6 small instance можно смело заменить на 8 micro instance
А можно чуть подробнее как было получено такое соотношение?
А можно чуть подробнее как было получено такое соотношение?
По логгируемому моим кодом (от begin request до end request) времени выполнения страницы, micro тратит столько же времени, сколько и small.
Я накинул 33% чтобы снизить вероятность возможного подвисания, упомянутого miolini.
Я накинул 33% чтобы снизить вероятность возможного подвисания, упомянутого miolini.
Если Вы загрузите CPU запросами на 100%, то соотношение будет гораздо хуже, нежели 6:8. На 2-3 секунды бурста у них приходится 20-30 секунд тормозов. Когда требуется проц на постоянную нагрузку, 1 small инстанс сопоставим с 3-4 micro.
Говорю исходя из полугодового опыта использования связки ec2-micro/ec2-small и linux/tomcat.
И… это… 1-3 секунды на запрос это просто жесткий интерпрайз у вас?
Говорю исходя из полугодового опыта использования связки ec2-micro/ec2-small и linux/tomcat.
И… это… 1-3 секунды на запрос это просто жесткий интерпрайз у вас?
Во-первых, в этом и прелесть cloud, что если эта схема не сработает, то можно все быстро поменять ))
Откуда взялись 1-3 секунды на запрос? Если с графика Loadimpact, то они в Cтокгольме а сервер в Виржинии, так что тут попадает дополнительно пара пингов.
Мы целимся на рендеринг 80% (те типы запросов, что чаще всего запрашиваются) страниц до 0.2 s, но да, есть и более сложные запросы, надо которыми еще предстоит работать. Если сложный поиск будет выполняться за 3 секунды то это будет приемлимо.
Откуда взялись 1-3 секунды на запрос? Если с графика Loadimpact, то они в Cтокгольме а сервер в Виржинии, так что тут попадает дополнительно пара пингов.
Мы целимся на рендеринг 80% (те типы запросов, что чаще всего запрашиваются) страниц до 0.2 s, но да, есть и более сложные запросы, надо которыми еще предстоит работать. Если сложный поиск будет выполняться за 3 секунды то это будет приемлимо.
Скажите, пож, а у small и более крупных бывают подвисания?
нет, начиная с small всегда есть какой-то гарантированный вычислительный ресурс, который вам выделяется, и сервер хоть чуть чуть да продвинется в решении поставленной задачи.
Может будет интересно: small относительно легко ввести в ступор — например, архивация бакапа базы раром вводит его в состояние близкое к подвисанию — он не отвечал на запросы по http. Пришлось хранить бакапы базы в разархивированном виде
ПО более толстым инстанса у меня пока серьезного опыта нет.
Может будет интересно: small относительно легко ввести в ступор — например, архивация бакапа базы раром вводит его в состояние близкое к подвисанию — он не отвечал на запросы по http. Пришлось хранить бакапы базы в разархивированном виде
ПО более толстым инстанса у меня пока серьезного опыта нет.
Еще бы ссылку на сервис что там крутится, чтобы пощупать руками. А так даже профиль чист от ссылок. М?
Пока проект не открыт официально и посещаемость там небольшая «орда» микро инстансов пока не используется. Это была подготовка к релизу, который планируется в ближайшую неделю-две.
Если Вы используете Amazon могу поделиться AMI — вы скопируете туда собственное приложение и проверите, как оно живет.
Спасибо за напоминание о незаполненном профиле — я так обрадовался инвайту что забыл об этом… чуть заполнил, о себе напишу в течении нескольких дней
Если Вы используете Amazon могу поделиться AMI — вы скопируете туда собственное приложение и проверите, как оно живет.
Спасибо за напоминание о незаполненном профиле — я так обрадовался инвайту что забыл об этом… чуть заполнил, о себе напишу в течении нескольких дней
Если все еще интересно, то проект анонсирован на Хаббре — habrahabr.ru/blogs/development/122168/
SQL server — High CPU medium, и N micro instances
SQL server — High CPU medium, и N micro instances
Для Micro оптимальным решением будет только *nix платформа. Изначально использовал Win, но тормоза были жуткие… перешел на *nix все стало летать :)
Наверно, вы таки использовали Windows Server 2008 обычную, не R2? У меня тоже были жуткие тормоза и я был полностью разочарован в микро инстансах.
База данных стояла на этом же сервере?
Если будут дохнуть — я сделаю обновление этому посту, чтобы не вводит никого в заблуждение
PS: Вообще я очень рад что столько людей с хаббра использует Amazon Web Services
База данных стояла на этом же сервере?
Если будут дохнуть — я сделаю обновление этому посту, чтобы не вводит никого в заблуждение
PS: Вообще я очень рад что столько людей с хаббра использует Amazon Web Services
удовлетворяет ли вас скорость EBS? линейная скорость, кол-во операций IO в секунду? мы заметили, что со временем становится все хуже и все меньше у нас желания использовать их сетевой сторадж для кластеров.
Для хранению пользовательских файлов мы используем S3.
На EBS хранится только OS, Файлы приложения (~40MB), и MS SQL Server. Пока это не проблема.
Все что можно — CSS, картинки, пользовательские файлы — отдается через cloudfront; сервер отдает только сгенерированный html и JS (который на самом деле один и тот же и хранится в кэше).
Скорость копирования примерно 2MB/sec, 1.5MB/s когда мелкие файлы
Для теста, скопировал по сети с EBS одного инстанса на другой папку (8000 файлов, 350 мегабайт) — заняло ~2,5 минуты.
На EBS хранится только OS, Файлы приложения (~40MB), и MS SQL Server. Пока это не проблема.
Все что можно — CSS, картинки, пользовательские файлы — отдается через cloudfront; сервер отдает только сгенерированный html и JS (который на самом деле один и тот же и хранится в кэше).
Скорость копирования примерно 2MB/sec, 1.5MB/s когда мелкие файлы
Для теста, скопировал по сети с EBS одного инстанса на другой папку (8000 файлов, 350 мегабайт) — заняло ~2,5 минуты.
А вы Azure для этих задач не пробовали, все таки как то будет нативнее для Win Server'a + плюс там тоже есть микро инстансы
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Гигагерцы задешево — Win 2008R2 Core на Amazon