☰

Nginx + uWSGI + Django 성능이 100rq/s에서 멈춤

tag-icon • tag-icon nginx python django centos6 uwsgi
Nginx + uWSGI + Django 성능이 100rq/s에서 멈춤

CentOS 6 x64(3.06GHz i3 540, 4GB)에서 uWSGI 및 Django로 Nginx를 구성했는데 이는 2500rq/s를 쉽게 처리할 수 있지만 ab 테스트(ab -n 1000 -c 100)를 실행하면 성능이 92 - 100에서 중지됩니다. rq/s.

Nginx:
    user nginx;
    worker_processes 2;
    events {
        worker_connections 2048;
        use epoll;
    }

uWSGI:

    Emperor
    /usr/sbin/uwsgi --master --no-orphans --pythonpath /var/python --emperor /var/python/*/uwsgi.ini


[uwsgi]
socket = 127.0.0.2:3031
master = true
processes = 5

env = DJANGO_SETTINGS_MODULE=x.settings
env = HTTPS=on
module = django.core.handlers.wsgi:WSGIHandler()

disable-logging = true
catch-exceptions = false

post-buffering = 8192
harakiri = 30
harakiri-verbose = true

vacuum = true
listen = 500
optimize = 2

sysclt changes:
# Increase TCP max buffer size setable using setsockopt()
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608

net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_max_syn_backlog = 5000
net.ipv4.tcp_window_scaling = 1
net.core.somaxconn = 2048

# Avoid a smurf attack
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Optimization for port usefor LBs
# Increase system file descriptor limit
fs.file-max = 65535

sysctl -p변경 사항을 활성화했습니다 .

유휴 서버 정보:

top - 13:34:58 up 102 days, 18:35,  1 user,  load average: 0.00, 0.00, 0.00

Tasks: 118 total,   1 running, 117 sleeping,   0 stopped,   0 zombie

Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Mem:   3983068k total,  2125088k used,  1857980k free,   262528k buffers

Swap:  2104504k total,        0k used,  2104504k free,   606996k cached



free -m

 total       used       free     shared    buffers     cached

Mem:          3889       2075       1814          0        256        592

-/+ buffers/cache:       1226       2663

Swap:         2055          0       2055




**During the test:**

top - 13:45:21 up 102 days, 18:46,  1 user,  load average: 3.73, 1.51, 0.58

Tasks: 122 total,   8 running, 114 sleeping,   0 stopped,   0 zombie

Cpu(s): 93.5%us,  5.2%sy,  0.0%ni,  0.2%id,  0.0%wa,  0.1%hi,  1.1%si,  0.0%st

Mem:   3983068k total,  2127564k used,  1855504k free,   262580k buffers

Swap:  2104504k total,        0k used,  2104504k free,   608760k cached


free -m

total       used       free     shared    buffers     cached

Mem:          3889       2125       1763          0        256        595

-/+ buffers/cache:       1274       2615

Swap:         2055          0       2055


iotop

30141 be/4 nginx       0.00 B/s    7.78 K/s  0.00 %  0.00 % nginx: wo~er process

병목 현상은 어디에 있습니까? 아니면 내가 뭘 잘못하고 있는 걸까요?

답변1

분명히 어떤 작업을 사용하든 CPU에 바인딩되어 있습니다. 애플리케이션이 지연되는 위치를 찾기 위해 Django 앱을 프로파일링하는 것을 고려할 수 있습니다. Python WSGI 애플리케이션을 위한 여러 프로파일링 솔루션이 있습니다(Django는 특히 미들웨어의 경우 WSGI를 엄격하게 준수하지 않으므로 YMMV).

  1. 전열 보병(뻔뻔한 플러그, 이건 내 프로젝트야!)
  2. 케아스.프로필
  3. repoze.profile
  4. 도저(그러나 0.2 알파를 사용해야 합니다)

이를 통해 애플리케이션의 병목 현상을 식별할 수 있습니다. 즉, 애플리케이션이 대부분의 시간을 소비하는 기능은 무엇입니까?

확인해야 할 또 다른 사항은 uwsgi/nginx가 요청을 수신하는 데 시간이 얼마나 걸리는가입니다. 요청이 대기 중입니까? 평균 요청이 처음부터 끝까지 얼마나 걸리나요? 또한 더 중요한 것은 기준이 무엇입니까? 이를 알아보려면 동시 사용자 1명을 대상으로 동일한 테스트를 실행해 보세요. 그런 다음 사용자 수가 최고점에 도달하는 위치를 식별할 수 있을 때까지 점차적으로 사용자 수를 늘립니다.

이 정보를 사용하면 패턴 설정을 시작할 수 있으며 이것이 로드 테스트의 핵심입니다!

행운을 빌어요!

관련 정보