Устранение сбоев в работе сайта на Nginx + Gunicorn + Django Stack - программирование
Подтвердить что ты не робот

Устранение сбоев в работе сайта на Nginx + Gunicorn + Django Stack

Проблема я имела

У меня была проблема, когда некоторые сайты занимали много времени для загрузки ( "Долгое время" я имею в виду до 16 секунд). Иногда они могут быть полностью исчерпаны, что вызвало ошибку Nginx 504. Обычно, когда время ожидания сайта, я снова мог перезагрузить сайт, и он быстро загрузится. Сайт, с которым у меня возникли проблемы, получает очень низкий объем трафика. Я тестирую сайт, загружая страницу индекса администратора Django, чтобы попытаться устранить любую медлительность, которая может быть вызвана из-за плохого кода. Следует также отметить, что этот конкретный сайт использует только администратор Django, потому что он является сайтом только для интрасети.

Настройка хостинга

Все сайты, на которых я размещаюсь, находятся на двух облачных серверах Rackspace. Первым сервером является мой сервер приложений, который имеет 1024 МБ ОЗУ, а мой второй сервер - мой сервер базы данных, который имеет 2048 МБ ОЗУ. Сервер приложений обслуживает каждый сайт с помощью Nginx, который обслуживает все статические файлы и прокси-серверы всем остальным сотрудникам Django Gunicorn для каждого сайта.

При взгляде на серверы баз данных ОЗУ и загрузке процессора кажется, что на сервере базы данных все нормально.

$ free -m
             total       used       free     shared    buffers     cached
Mem:          1999       1597        402          0        200       1007
-/+ buffers/cache:        389       1610
Swap:         4094          0       4094


Top shows a CPU load average of: 0.00, 0.01, 0.05

Чтобы попытаться устранить то, что происходит, я написал небольшую script, которая печатает использование памяти на сервере приложений.

Пример распечатки с анонимными доменами сайта:

Celery:     23 MB
Gunicorn:  566 MB
Nginx:       8 MB
Redis:     684 KB
Other:      73 MB

             total       used       free     shared    buffers     cached
Mem:           993        906         87          0         19         62
-/+ buffers/cache:        824        169
Swap:         2047        828       1218

Gunicorn memory usage by webste:
site01.example.com    31 MB
site02.example.com    19 MB
site03.example.com     7 MB
site04.example.com     9 MB
site05.example.com    47 MB
site06.example.com    25 MB
site07.example.com    14 MB
site08.example.com    18 MB
site09.example.com    27 MB
site10.example.com    15 MB
site11.example.com    14 MB
site12.example.com     7 MB
site13.example.com    18 MB
site14.example.com    18 MB
site15.example.com    10 MB
site16.example.com    25 MB
site17.example.com    13 MB
site18.example.com    18 MB
site19.example.com    37 MB
site20.example.com    30 MB
site21.example.com    23 MB
site22.example.com    28 MB
site23.example.com    80 MB
site24.example.com    15 MB
site25.example.com     5 MB

Пример файла конфигурации Gunicorn:

pidfile = '/var/run/gunicorn_example.com.pid'
proc_name = 'example.com'
workers = 1
bind = 'unix:/tmp/gunicorn_example.com.sock'

Пример конфигурации Nginx:

upstream example_app_server {
    server unix:/tmp/gunicorn_example.com.sock fail_timeout=0;
}

server {

    listen       80;
    server_name  example.com;
    access_log   /var/log/nginx/example.com.access.log;
    error_log    /var/log/nginx/example.com.error.log;

    location = /favicon.ico {
        return  404;
    }

    location  /static/ {
        root  /srv/sites/example/;
    }

    location  /media/ {
        root  /srv/sites/example/;
    }

    location  / {
        proxy_pass            http://example_app_server;
        proxy_redirect        off;
        proxy_set_header      Host             $host;
        proxy_set_header      X-Real-IP        $remote_addr;
        proxy_set_header      X-Forwarded-For  $proxy_add_x_forwarded_for;
        client_max_body_size  10m;
    }

}

Как вы можете видеть, есть большая часть памяти, которая меняет местами, поэтому, чтобы исправить мои проблемы, я обновил ram на сервере приложений, что полностью устранило медлительность сайтов. Несмотря на то, что я смог решить проблему, мне потребовалось гораздо больше времени, чем хотелось бы, и я все еще чувствую, что, по сути, я догадываюсь о том, что заставляет сайт медлительность. Все это приводит меня к моим вопросам...

Вопросы

  • Как вы можете сказать, что медленность сайта на сайте с низким трафиком не вызвана неактивностью сайта, которая приводит к тому, что сайт становится неактивным, что заставляет Gunicorn снова загружать сайт после того, как сайт неактивен? Есть ли параметр, запрещающий запуск сайта неактивным?
  • Кажется, у меня есть сайты, которые занимают слишком много памяти. Какие инструменты я могу использовать для уменьшения объема памяти, которую использует сайт? Должен ли я использовать некоторые инструменты профилирования Python?
  • Каковы некоторые инструменты и шаги для определения того, на каком уровне в стеке возникает узкое место?
  • Каков наилучший способ определить, будут ли выполняться ваши процессы Gunicorn, если они заменяются другими процессами?
  • Большинство сайтов, на которых я размещаю, не получают тонны трафика, поэтому я использую только одного сотрудника Gunicorn. Есть ли более научный способ определения и корректировки количества работников Gunicorn у вас на сайте?
  • При размещении нескольких сайтов на одном и том же сервере существуют ли способы настройки содержимого для использования меньше памяти?
4b9b3361

Ответ 1

Это много сайтов для размещения на сервере с 1 ГБ ОЗУ. Вы используете почти 100% использования памяти, а числа, которые у вас есть, вероятно, являются "резервными" номерами. Использование ОЗУ каждого процесса может и будет выполняться в процессе обслуживания запросов. С самого начала вам нужно добавить больше RAM в этот экземпляр и, лучше, перенести некоторые сайты на другой сервер.

Что касается ваших вопросов:

  • Откуда вы поняли, что сайты становятся "неактивными" и "Гуникорн", то нужно снова загрузить сайт? Это мусор. Пока работает процесс Gunicorn (т.е. Не завершается вручную или с ошибкой на сайте), он остается полностью инициализированным и готовым к работе, будь то час или месяц.

  • Вы взламываете листья, оставляя корень нетронутым. Там нет ничего необычного в использовании памяти каждого процесса Gunicorn. Для работы требуется RAM. Ваша проблема заключается в том, что вы слишком много работаете на сильно недостаточном сервере. Никакая оптимизация не спасет вас здесь. Вам нужно больше ОЗУ или больше серверов. Вероятно, оба.

  • Нет необходимости. Опять же, проблема уже определена. Довольно ясно, на самом деле, по указанным вами номерам.

  • Нет никакого способа достоверно узнать, какие процессы обмениваются. Он изменяется каждую секунду и зависит от того, какие из них активно работают и что требуется больше ОЗУ, а какие неактивны или просто неактивны. Когда ваш сервер привязан к ресурсам, он тратит половину времени, просто выясняя, какой процесс жонглировать следующим, особенно если они все активны и соперничают за ресурсы.

  • Да. Gunicorn рекомендует 2 * ядра + 1. Так что в двухъядерной системе это 5; на четырехъядерном процессоре, 9. Тем не менее, вы не можете запустить даже 5 работников для каждого из этих сайтов в этой системе. Вы не можете даже запустить 1 работника для каждого надежно.

  • Это зависит от "вещей". Но, когда несколько сайтов размещаются на одном сервере, эти серверы являются зверями. На небольшом, вероятно, экземпляре VPS, как у вас, особенно с 1 ГБ ОЗУ, один сайт в значительной степени ограничивает вас. Возможно, два.

Ответ 2

1) Не знаете, что вы подразумеваете под неактивным? Как и в, отключено nginx? Или слишком медленно работать?

2 и 3) django-debug-toolbar и django-debug-logging станут хорошим местом для начала. Если это не помогает, пришло время перейти к профилированию на уровне сервера, чтобы выяснить, какие процессы вызывают проблему.

4) Использовать верх: Как узнать, какие процессы перекодируются в Linux?

5) Да - бенчмаркинг. Выберите инструмент сравнения (например, apachebench) и запустите тесты против текущей конфигурации. Подстройте что-нибудь. Повторите тесты. Повторяйте, пока ваши проблемы с производительностью не исчезнут! Для достижения наилучших результатов используйте трафик, похожий на ваш прямой трафик (с точки зрения распределения URL, GET/POST и т.д.).

6) Да, на уровнях nginx и app. Вы, вероятно, получите большую выгоду, профилируя каждый сайт и улучшая использование памяти (см. 2).

Ответ 3

Относительно:

Что касается вашего ответа на 5, я считаю, что Гуникорн рекомендует излишество.

Недавно я провел несколько специальных тестов с количеством рабочих и обнаружил, что, если у вас достаточно ОЗУ, это правило 2 * core + 1 довольно точно. Я обнаружил, что запросы/сек увеличились почти линейно, пока я не приблизился к этому номеру, а затем отключился, когда ОС начала трэш.

Поскольку результаты сильно зависят от рабочей нагрузки, попробуйте разные значения и посмотрите, где ваши пики производительности.