Оптимальное количество процессов единорога на процессор

Мы запускаем веб-приложение Ruby on Rails под Unicorn. Наше приложение не привязано строго к процессору (у нас двойная система Xeon E5645 с 12 ядрами, а среднее значение пиковой нагрузки составляет около 6). Сначала мы работали с 40 работниками Unicorn, но объем памяти приложений со временем увеличивался. Итак, теперь мы должны уменьшить количество рабочих процессов. Я думал, что стандартная формула (число ядер процессора + 1) применима и к Unicorn, но мой коллега пытался убедить меня, что нам следует резервировать больше экземпляров Unicorn на процессор, и предоставил эту ссылку . Тем не менее, я не совсем уверен, зачем нам тратить столько памяти на незанятые процессы Unicorn.

Мой вопрос: что является причиной наличия более одного экземпляра Unicorn на ядро ​​процессора? Это связано с какой-то архитектурной особенностью единорога? Я знаю, что занятые процессы Unicorn не могут принимать новые соединения (мы используем доменные сокеты UNIX для связи с экземплярами Unicorn, кстати), но я думал, что для решения этой проблемы было введено отставание. Можно ли как-то преодолеть это от 2 до 8 экземпляров Unicorn на правило ЦП?

Хорошо, я наконец нашел ответ. Оптимальное количество рабочих Unicorn напрямую не связано с количеством ядер ЦП, это зависит от вашей нагрузки и внутренней структуры приложения / отзывчивости. В основном мы используем профилировщик выборки для определения состояния работников, мы стараемся держать работников на 70% без дела и 30% при выполнении реальной работы. Таким образом, 70% выборок должны «ждать вызова select (), чтобы получить запрос от внешнего сервера». Наше исследование показало, что существует только 3 эффективных рабочих состояния: 0-30% выборок простаивают, 30-50% выборок простаивают и 50-70% выборок простаивают (да, мы можем получить больше свободных проб, но есть в этом нет никакого смысла, потому что отзывчивость приложений существенно не меняется). Мы рассматриваем ситуацию на 0-30% как "красную зону", а ситуацию на 30-50% - как "желтую зону".

Вы правы в отношении N + 1 для задач, связанных с процессором.

С другой стороны, единорог не использует потоки, поэтому каждый IO op. блокирует процесс, а другой процесс может включать и анализировать заголовки HTTP, объединять строки и выполнять все ресурсоемкие задачи, необходимые для обслуживания пользователя (делая это раньше, чтобы уменьшить задержку запросов).

И вы можете захотеть иметь больше потоков / процессов, чем ядер. Представьте себе следующую ситуацию: Треб. А занимает в десять раз больше, чем требование. B, у вас есть несколько одновременных запросов A, и быстрый запрос B только ставится в очередь, ожидая завершения A-req. Так что, если вы можете предсказать количество тяжелых запросов, вы можете использовать это число в качестве другого ориентира для настройки системы.