Heroku Широкоэкранного Время отклика Высокой

Question

Это очень специфическое, но я постараюсь быть краткими:

Мы работаем Django приложения на Heroku . Три сервера:

1. тест (1 сеть, 1 сельдерей дино)
2. обучение (1 сеть, 1 сельдерей дино)
3. прод (2 Интернет, 1 сельдерей дино).

Мы используем Gunicorn с gevents и 4 рабочих на каждом дино.

Мы являемся , испытывая спорадическое высокое время обслуживания. Вот пример из Logentries:

High Response Time: 
heroku router - - at=info 
method=GET 
path="/accounts/login/" 
dyno=web.1 
connect=1ms 
service=6880ms 
status=200 
bytes=3562 

Я уже несколько недель искал это в Интернете. Мы не можем воспроизвести по желанию, но испытываем эти оповещения от 0 до 5 раз в день. Известные точки:

• Происходит на все три приложений (все работает аналогично код)
• Происходит на разных страницах, в том числе простых страниц, такие как 404 и/администратор
• происходит в случайные моменты времени
• Происходит с переменной пропускной способностью. Один из наших экземпляров включает только 3 пользователя в день. Это не связано со спящими динамиками, потому что мы пингом с New Relic, и проблема может возникнуть в середине сессии
• Невозможно воспроизвести по желанию. Я лично столкнулся с этой проблемой. Нажатие на страницу, которая обычно выполняется в 500 мс, вызвала 30-секундную задержку и, наконец, экран ошибки приложения из таймаута 304 Heroku
• Высокое время отклика варьируется от 5000 мс до 30000 мс.
• Новая реликвия не указывает на конкретную проблему. Вот последние несколько сделок и раз:
  • RegexURLResolver.resolve 4,270ms
  • SessionMiddleware.process_request 2,750ms
  • Рендер логин.HTML 1,230ms
  • WSGIHandler 1,390ms
  • выше простые звонки и обычно не принимают близко то количество времени

То, что я сузили его до:

1. This article on Gunicorn and slow clients
   • Я видел, как эта проблема случается с медленными клиентами, но также и в нашем офисе, где у нас есть оптоволоконная связь.
2. GEvent и асинхронные рабочие не играют красиво
   • Мы перешли на gunicorn синхронизации рабочих и проблема все еще сохраняется.
3. Gunicorn рабочий тайм-аут
   • Вполне возможно, что рабочие как-то держится, живы в нулевом состоянии.
4. Недостаточные работники/динамометрические стенды
   • Нет признаков CPU/памяти/дб и чрезмерной нагрузки New Relic не показывает никаких признаков DB задержки
5. Шумные Соседи
   • Среди моих многочисленных писем с Heroku, представитель службы поддержки упомянул, по крайней мере, один из моих длительных запросов был вызван шумным соседом, но не был convi Это было проблемой.
6. Subdomain 301
   • Запросы идут через хорошо, но застрять в случайном порядке применения.
7. динамометрические стенды перезапуск
   • Если бы это было так, то многие пользователи будут затронуты. Кроме того, я вижу, что наши динамики не перезапускались недавно.
8. Heroku маршрутизации/выпуска услуг
   • Вполне возможно, что сервис Heroku меньше, чем рекламируемые, и это просто недостаток использования их службы.

Мы с этим вопросом в течение последних нескольких месяцев, но теперь, когда мы сворачиваем это должно быть исправлено.Любые идеи были бы очень благодарны, поскольку я исчерпал почти все ссылки SO или Google.

Answer 1

Я был в контакте с командой поддержки Heroku за последние 6 месяцев. Это был длительный период сужения проб/ошибок, но мы определили проблему.

Я в конце концов заметил, что эти высокие времена отклика соответствовали внезапному обмену памяти, и хотя я платил за стандартный Dyno (который не работал на холостом ходу), эти обмены памяти происходили, когда мое приложение не получало трафика в последнее время. Было также ясно, глядя на диаграммы показателей, что это не утечка памяти, потому что память будет плато. Например:

После многочисленных дискуссий с их службой поддержки, мне предоставили такое объяснение:

По существу, что происходит, некоторые Серверные автономной работы в конечном итоге с комбинацией приложений, которые в конечном итоге используя достаточное количество памяти, которое должно выполняться во время выполнения. Когда это случается, случайный набор контейнеров dyno в среде выполнения принудительно меняются произвольно по небольшим количествам (обратите внимание, что «случайные» здесь, скорее всего, контейнеры с памятью, к которой недавно не обращались, но все еще находятся в памяти). В то же время приложения, использующие большие объемы памяти, также сильно меняются, что приводит к увеличению количества событий в среде выполнения, чем обычно.

Мы не изменили, насколько сильно мы упаковываем время автономной работы, поскольку эта проблема стала более очевидной, поэтому наша нынешняя гипотеза заключается в том, что проблема может исходить от клиентов, перемещающихся с версий Ruby до 2.1 до 2.1+. Ruby составляет огромный процент приложений, которые работают на нашей платформе, а Ruby 2.1 вносит изменения в свой GC, который торгует использованием памяти для скорости (по сути, он GC реже, чтобы получить прирост скорости). Это приводит к заметному увеличению использования памяти для любого приложения, перемещающегося из более старых версий Ruby. Таким образом, такое же количество приложений Ruby, которые поддерживали определенный уровень использования памяти, теперь начнет требовать больше использования памяти.

Это явление в сочетании с неправильными приложениями, которые злоупотребляют ресурсами на платформе, попало в точку опроса, которая привела нас к ситуации, которую мы видим сейчас, когда динамики, которые не подлежат обмену, являются. У нас есть несколько способов атаки, которые мы изучаем, но пока многие из них все еще немного спекулятивны.Мы точно знаем, что некоторые из них вызваны приложениями, злоупотребляющими ресурсами, и поэтому переход к динамикам Performance-M или Performance-L (которые имеют выделенные временные промежутки времени) не должен вызывать проблемы. Единственное использование памяти на этих динамиках будет вашим приложением. Итак, если есть своп, это будет связано с тем, что ваше приложение вызывает его.

Я уверен, что это проблема, с которой я и другие сталкивались, поскольку она связана с самой архитектурой, а не с какой-либо комбинацией языка/рамки/конфигов.

Там, кажется, не является хорошим решением, кроме А) перетерпеть и переждать или B) переключатель в одном из своих специальных случаев

Я отдаю себе отчет в толпе, которая говорит: «Это почему вы должны использовать AWS », но я нахожу те преимущества, которые Heroku предлагает перевесить некоторые случайные высокие времена отклика, и их цены стали лучше с годами. Если вы страдаете от одной и той же проблемы, лучшим решением будет ваш выбор. Я обновлю этот ответ, когда услышу что-нибудь еще.

Удачи вам!

Answer 2

Не уверен, что это вообще поможет, но я перехожу к тому же самому с помощью приложения Rails прямо сейчас на Heroku - казалось бы, недетерминированным, слишком спорадически высоким запросом. Например, HEAD Новое время простоя Relic связывается с индексом моего сайта, который обычно занимает 2-5 мс, занимая 5 секунд, или рендеринг моего входа в сайт, который обычно занимает вторую секцию, занимая 12 секунд. Также иногда получайте случайные тайм-ауты 30 секунд. Вот то, что должно было оказать поддержка Хероку в моем случае (по крайней мере, для некоторых случаев):

Сегодняшний день выглядит как большой кусок очереди запросов после перезапуска. Если вы хотите этого избежать, вы можете взглянуть на наш Preboot feature. Это позволит вам загружать согласованный набор динамиков после развертывания, а затем обращать на них запросы вместо того, чтобы бить поверх существующих динамиков и заставлять очередь запросов.

Я должен отметить, что это была одна из стандартных перезагрузок Героку, а не развертывание моего или что-то еще. Несмотря на оговорки на странице preboot, я включил его несколько минут назад, поэтому мы посмотрим, имеет ли это значение в моем случае. Надеюсь, что это поможет, поскольку я тоже вытягиваю свои волосы!