Сколько процессов я должен указать в WSGIDaemonProcess при запуске Django через mod_wsgi?

Допустим, у меня есть 2 сайта (Superuser и Serverfault), запущенные с их собственного виртуального хоста Apache на одном компьютере. Эти 2 сайта работают на Django и работают на Apache с mod-wsgi. Типичный файл конфигурации для одного из сайтов будет выглядеть следующим образом:

WSGIDaemonProcess serverfault.com user=www-data group=www-data processes=5

Хост - это Linux-машина с 4 ГБ оперативной памяти под управлением Ubuntu. Может кто-нибудь предложить количество процессов, которые я должен указать выше для моих 2 сайтов? Давайте предположим, что у них такой же трафик, как и у сайтов Superuser и Serverfault.

Ну, сколько трафика сделать фактические сайты суперпользователя и Serverfault есть? Гипотетики не очень полезны, если у них недостаточно информации, чтобы облегчить ответ ...

Число процессов в худшем случае должно быть максимальным числом запросов в секунду, которое должен обрабатывать сайт, деленным на количество запросов в секунду, которое может обработать один процесс, если все эти запросы будут выполнены с вашим самым медленным действием (поэтому обратная величина времени обработки этого действия). Добавьте любой коэффициент помадки, который вы считаете подходящим, на основе доверительного интервала ваших требований / сек и временных измерений.

Среднее число наблюдений такое же, но вы делите req / sec на средневзвешенное значение числа запросов в секунду для каждого действия (вес - это процент запросов, которые вы ожидаете выполнить для данного конкретного действия). Опять же, факторы помадки полезны.

Фактическая верхняя граница количества процессов, которые вы можете запустить на машине, определяется верхним объемом памяти, который занимает каждый процесс; спулингировать один процесс, а затем выполнить множество действий, требующих памяти (те, которые обычно извлекают и обрабатывают много данных), с реалистичным набором данных (если вы просто используете игрушечный набор данных для тестирования, скажем, 50 или 100) строк, а затем, если одно из ваших действий извлекает и манипулирует каждой строкой в ​​таблице, это не будет хорошим измерением для того, когда эта таблица увеличится до 10000 строк), чтобы увидеть, к чему стремится использование памяти. Вы можете искусственно ограничить использование памяти каждым процессом с помощью сценария, который пожинает работникам, которые достигают определенного порога использования памяти, с риском возникновения неприятных проблем, если вы установите этот порог слишком низким.

Получив показатель использования памяти, вы вычитаете некоторый объем памяти для загрузки системы (мне самому нравится 512 МБ), вычитаете кучу больше, если у вас на том же компьютере запущены другие процессы (например, база данных), а затем еще немного, чтобы убедиться, что у вас не осталось свободного места в дисковом кеше (зависит от размера рабочего набора вашего диска, но опять-таки я бы выбрал не менее 512 МБ). Это количество памяти, которое вы делите на использование памяти для каждого процесса, чтобы получить максимальный уровень.

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

Вот вам и многолетний опыт масштабирования сайтов, превращенный в одну маленькую и простую статью SF.

Уомбл ответ «s является удивительным, хотя и немного трудно понять и применить для неопытный. Я хотел бы привести некоторые эмпирические цифры и сравнение приложения «простой контент» и «электронная коммерция».

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

A) Сайты и микросайты CMS

Мы работаем с несколькими веб-сайтами клиентов, большинство из которых в основном являются контент-сайтами или микро-сайтами, на которых размещается CMS django, некоторые пользовательские формы, а иногда и Celery для запланированных фоновых задач. Эти сайты не жаждут ресурсов, некоторые из них успешно работают параллельно на одном 4-ядерном Intel Xeon с 32 ГБ оперативной памяти. Вот конфигурация, которую мы используем для каждого из сайтов такого типа:

WSGIDaemonProcess example.com user=www-data processes=2 maximum-requests=100

Я говорю о примерно 40 сайтах на одном сервере, большинство из которых со своим промежуточным сайтом работают в режиме ожидания. С двумя процессами (по умолчанию с 15 потоками каждый) сайты обеспечены, хотя и ограничены в своих возможностях распределения ресурсов сервера. Почему эта настройка достаточна, может быть объяснено простой природой приложения (CMS): ни один запрос никогда не займет больше пары миллисекунд. Apache всегда будет оставаться расслабленным, как и нагрузка на процессор.

Б) Сайты электронной коммерции

Более сложные сайты, которые мы делаем, характеризуются все еще вычислительно недорогими локальными операциями, но внешними зависимостями (например, веб-сервисами, предоставляющими данные бронирования), которые дороги с точки зрения времени транзакции. Операции с внешними запросами занимают потоки гораздо дольше, поэтому вам нужно больше потоков для обслуживания того же числа пользователей (по сравнению с простым сайтом CMS сверху). Хуже того, потоки иногда блокируются, когда внешняя служба не может ответить на запрос немедленно, иногда в течение нескольких секунд. Это может привести к неприятному побочному эффекту, когда потоки, помещающие запросы в одну и ту же службу, встают в очередь, пока все доступные потоки mod_wsgi не будут израсходованы и не заблокированы в ожидании.

Для этих сценариев мы пытались использовать 6процессы, не видя большой разницы, и в итоге мы 12увидели несравненный прирост производительности и стабильности работы:

WSGIDaemonProcess example.com user=www-data processes=12 maximum-requests=100

Некоторые простые нагрузочные тесты с 150 и 250 параллельными пользователями легко обрабатываются сайтом, который остается хорошо реагирующим (в то время как с 2процессами сайт непригоден для обслуживания 50 пользователей параллельно). Двухпроцессорный 6-ядерный Intel Xeon с 32 ГБ ОЗУ работает под нагрузкой ЦП ниже 25% при этой нагрузке, при этом использование ОЗУ практически остается постоянным и составляет менее 25%. Обратите внимание, что мы используем выделенный компьютер только для одного сайта, поэтому мы не будем воровать ресурсы, которые могут понадобиться другим сайтам.

Вывод

Использование большего числа процессов - это компромисс между разрешением Apache использовать доступные системные ресурсы или нет. Если вы хотите сохранить стабильную серверную систему (не веб-сайт!) В условиях «атаки», оставьте это число низким. Если вы хотите, чтобы Apache помогал вам использовать системные ресурсы (ЦП, ОЗУ) при необходимости, выберите большее число. То, как высоко вы можете подняться, рассчитывается примерно так, как описано в принятом ответе выше, и в конечном итоге ограничено доступной мощностью процессора и оперативной памяти.

(PS: Я держу раздел ConfigurationDirectives вики проекта modwsgi под своей подушкой для Apache-подобного фонового чтения. Также не забудьте понять и контролировать открытые соединения вашего сервера Apache .)