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

Ми запускаємо веб-додаток Ruby on Rails під Unicorn. Наш додаток не обмежений процесором (у нас є подвійна система Xeon E5645 з 12 ядрами, а середнє значення пікового навантаження становить близько 6). Ми почали з 40 працівників Unicorn спочатку, але слід пам’яті додатків збільшувався з часом. Отже, зараз нам доведеться знизити кількість робочих процесів. Я думав, що стандартна формула (кількість ядер CPU + 1) застосовується і для Unicorn, але мій колега намагався переконати мене, що ми повинні резервувати більше примірників Unicorn на процесор, і надав це посилання . Однак я не зовсім впевнений, навіщо нам витрачати стільки пам’яті на просторові процеси єдинорога.

Моє запитання: що є причиною наявності декількох екземплярів Unicorn на ядро ​​CPU? Це пов’язано з якоюсь архітектурною особливістю Єдинорога? Я знаю, що зайняті процеси Unicorn не можуть приймати нові підключення (ми використовуємо розетки домену UNIX для спілкування з прикладами Unicorn BTW), але я подумав, що саме для цього було введено відставання. Чи можливо подолати ці 2 - 8 екземплярів Unicorn за правило центрального процесора?

Гаразд, я знайшов відповідь нарешті. Оптимальна кількість працівників Unicorn безпосередньо не пов'язана з кількістю ядер процесора, це залежить від вашої навантаження та внутрішньої структури програми / чутливості. В основному ми використовуємо пробірник вибірки для визначення стану робітників, ми намагаємось утримувати працівників 70% в режимі холостого ходу та 30%, виконуючи фактичну роботу. Отже, 70% зразків повинні "чекати на виклик select (), щоб отримати запит від сервера frontend". Наше дослідження показало, що є лише 3 ефективні стани робітників: 0-30% проб простоюють, 30-50% проб становлять непрацюючі, а 50-70% проб простоюють (так, ми можемо отримати більше проб, але там немає жодного реального сенсу в цьому, оскільки чуйність програми не суттєво змінюється). Ми вважаємо 0-30% ситуації "червоною зоною", а 30-50% - "жовтою зоною".

Ви маєте рацію щодо N + 1 для завдань, пов'язаних з процесором.

З іншого боку, єдиноріг не використовує нитки, тому кожен IO op. блокує процес, а інший процес може запускати та аналізувати заголовки HTTP, об'єднувати рядки та виконувати всі необхідні для процесора завдання, необхідні для обслуговування користувача (робити це раніше, щоб зменшити затримку запиту).

І, можливо, ви хочете мати більше потоків / процесів, ніж ядер. Уявіть таку ситуацію: req. A займає в десять разів більше, ніж запит. B, у вас є декілька паралельних запитів A, і швидкий B запит просто зачеканий, коли A-req завершиться. Отже, якщо ви можете передбачити кількість важких запитів, ви можете використовувати це число як інший настанов для налаштування системи.