Использование процессоров Unicorn во время нагрузочных тестов, способы оптимизации

Question

Меня интересуют способы оптимизации моей настройки Unicorn для моего приложения Ruby on Rails 3.1.3. В настоящее время я создаю 14 рабочих процессов в Экстра-Экстра большой Экземпляре, так как мое приложение, как представляется, связано с ЦП во время нагрузочных тестов. При 20 запросах в секунду повторных запросов на тесты загрузки симуляции все 8 ядер на моем экземпляре получают максимум, а загрузка ящика увеличивается до 7-8. Каждый экземпляр unicorn использует около 56-60% CPU.

Мне любопытно, какие способы я могу оптимизировать? Я бы хотел, чтобы у вас было больше запросов в секунду на экземпляр такого размера. Память полностью прекрасна, как и все другие операции ввода-вывода. Во время моих тестов процессор загружается.

Answer 1

Прежде всего, вы, вероятно, не хотите экземпляров со скоростью 45-60%. В этом случае, если вы получите всплеск трафика, все ваши экземпляры задохнутся.

Далее, 14 экземпляров единорога кажется большим. Единорог не использует потоки. Скорее, каждый процесс выполняется с помощью одного потока. Мастерский процесс Unicorn будет только select нитью, если он сможет ее обработать. Из-за этого количество ядер не является метрикой, которую вы должны использовать для измерения производительности с помощью Unicorn.

Более консервативная установка может использовать 4 или около того Unicorn-процессы для каждого экземпляра, отвечая на 5-8 запросов в секунду. Затем отрегулируйте количество экземпляров до тех пор, пока ваш процессор не будет около 35%. Это обеспечит стабильность при стрессовом сценарии «20 запросов в секунду».

Наконец, вы можете получить более крупную статистику и детали, используя God.

Answer 2

Если вы связаны с процессором, вы хотите использовать больше процессов единорога, чем у вас есть ядра, иначе вы перегрузите систему и замедлите планировщик. Вы можете проверить это в dev-блоке, используя ab. Вы заметите, что 2 единорога превзойдут 20 (число зависит от ядер, но концепция останется верной).

Исключение из этого правила - если ваш IO связан. В этом случае добавьте столько единорогов, сколько может удерживать память.

Хороший трюк с целью выполнения маршрутизации запросов, связанных с IO, на другой сервер приложений с множеством единорогов. Например, если у вас есть запрос, который использует медленный sql-запрос или ваше ожидание по внешнему запросу, например транзакцию с помощью кредитной карты. Если вы используете nginx, определите восходящий сервер для запросов с привязкой IO, переместите эти URL-адреса в поле с 40 единорогами. Записанные процессором или действительно быстрые запросы, перейдите в поле с 8 единорогами (вы сказали, что у вас есть 8 ядер, но на aws вы можете попробовать 4-6, поскольку их планировщики гипервизированы и уже очень заняты).

Кроме того, я не уверен, что вы можете рассчитывать на aws, давая вам надежное использование ЦП, так как вы получаете процент от неясного процента.

Answer 3

Для большого большого экземпляра процессора 20 запросов в секунду очень низкий. Вероятно, есть проблема с кодом. Проблема с единорогом кажется менее вероятной. Если у вас есть сомнения, вы можете попробовать другой сервер приложений и подтвердить, что это все еще происходит.

В этом сценарии, вопросы, которые я бы думать о ...

1 - Вы делаете что-то ресурсоемкие в коде - может быть что-то, что должно быть действительно в базе данных. Например, если вы возвращаете большой набор записей и зацикливаете на нем в ruby ​​/ rails для его сортировки или выполнения какой-либо другой операции, это объясняет узкое место процессора на этом уровне, а не в базе данных. Рекомендация в этом случае состоит в том, чтобы обновить запрос, чтобы сделать больше и снять нагрузку с рельсов.Например, если вы сортируете результирующий набор в своем контроллере, а не через sql, это вызовет такую ​​проблему.

2 - Вы делаете что-нибудь необычное по сравнению с приложением для ванильной крошки, например, для доступа к совместно используемому ресурсу или чего-нибудь еще, что может быть проблемой?

3 - У вас есть какие-либо петли, которые могли бы сжечь CPU, особенно если возникла проблема в отношении ресурса?

4 - Попробуйте отцепить различные части логики контроллера, о которой идет речь. Например, насколько хорошо он масштабируется, если вы взломаете свой код, чтобы вместо этого вернуть статический ответ hello world? Могу поспорить, вдруг единорог будет стремительно быстро. Затем повторите попытку добавления части кода, пока не обнаружите источник медлительности.