2016-01-29 8 views
3

Доброе утро,Слишком много потоков uwsgi

Я новичок в инфраструктуре и администрировании веб-серверов. У меня есть проблема с веб-сервером, с которым я пытаюсь подключиться, используя nginx + uwsgi + django и python: при каждом обновлении или запросе веб-страницы, которую делает пользователь, uwsgi создает 2-3 новых потока, которые никогда не заканчиваются. Через несколько дней у меня закончилось более 30000 потоков, и мне нужно перезагрузить uwsgi, чтобы поддерживать производительность веб-страницы.

Для проверки количества потоков я использую следующую команду: ps - eLf | grep uwsgi (вы можете видеть, что результат прилагается).

Моя конфигурация uwsgi заключается в следующем:

[uwsgi] 

vhost = true 

socket = /tmp/mySocket.sock 

master = true 

processes = 4 

max_request = 300 

vacuum = true 

die-on-term = true 

close-on-exec = true 

harakiri = 30 

wsgi-file = /home/virtualEnv/server/wsgi.py 

virtualenv = /home/virtualEnv 

pythonpath = /home/virtualEnv/myServer 

chdir=/home/virtualEnv/myServer 

pidfile=/tmp/myFile.pid 

daemonize = /var/log/uwsgi/[email protected](exec://date +%%Y-%%m-%%d).log 

log-reopen = true 

chmod-socket = 664 

gid = www-data 

uid = www-data 

Мой uwsgi.py файл состоит в следующем:

import os 
import sys 

path = ‘/home/virtualEnv/myServer' 
if path not in sys.path: 
    sys.path.append(path) 

os.environ['DJANGO_SETTINGS_MODULE'] = 'myServer.settings' 

from django.core.wsgi import get_wsgi_application 
application = get_wsgi_application() 

И мой файл /etc/init/uwsgi.conf является:

description "uWSGI Emperor" 
start on runlevel [2345] 
stop on runlevel [!2345] 

respawn 
exec uwsgi --emperor /etc/uwsgi/vassals/ --wsgi-file /home/virtualEnv/server/wsgi.py 

Я пробовал использовать uwsgi с и без резьбы, с и без - thunder-lock, но ничего действительно не меняется.

EDIT:

После очистки uwsgi.ini файл я продолжаю с той же проблемой. Текущая конфигурация файлов:

uwsgi.ini:

[uwsgi] 
socket = /tmp/mySocket.sock 
master = true 
processes = 4 
max_request = 3 
vacuum = true 
die-on-term = true 
close-on-exec = true 
harakiri = 30 
wsgi-file = /home/virtualEnv/server/wsgi.py 
virtualenv = /home/virtualEnv 
pythonpath = /home/virtualEnv/myServer 
chdir=/home/virtualEnv/myServer 
pidfile=/tmp/myFile.pid 
logger = file:/var/log/uwsgi/[email protected](exec://date +%%Y-%%m-%%d).log 
log-reopen = true 
chmod-socket = 664 
gid = www-data 
uid = www-data 

uwsgi.conf

description "uWSGI Emperor" 
start on runlevel [2345] 
stop on runlevel [!2345] 

respawn 
exec uwsgi --emperor /etc/uwsgi/vassals/ 

nginx.conf:

user www-data; 
worker_processes auto; 
worker_rlimit_nofile 10000; 
pid /run/nginx.pid; 
events { 
worker_connections 10000; 
multi_accept on; 
use epoll; 
} 

http { 
server_tokens off; 
resolver 8.8.8.8; 
map $http_accept_language $lang { 
default en; 
~*en en; 
~*pt pt; 
~*fr fr; 
~*it it; 
~*es es; 
~*ru ru; 
~*ro ro;} 
client_body_buffer_size 10K; 
client_header_buffer_size 1k; 
client_max_body_size 10m; 
large_client_header_buffers 2 1k; 
client_body_timeout 12; 
client_header_timeout 12; 
keepalive_requests 100; 
send_timeout 10; 
open_file_cache max=2500 inactive=20s; 
open_file_cache_valid 30s; 
open_file_cache_min_uses 2; 
open_file_cache_errors on; 
sendfile off; 
tcp_nopush on; 
tcp_nodelay on; 
keepalive_timeout 5000; 
types_hash_max_size 2048; 
include /etc/nginx/mime.types; 
default_type application/octet-stream; 
access_log /var/log/nginx/access.log; 
error_log /var/log/nginx/error.log; 
charset UTF-8; 
gzip on; 
gzip_http_version 1.0; 
gzip_vary on; 
gzip_static on; 
gzip_disable ""msie6""; 
gzip_min_length 256; 
gzip_comp_level 1; 
gzip_buffers 4 32k; 
gzip_proxied any; 
gzip_types text/plain text/html text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript; 
include /etc/nginx/conf.d/*.conf; 
include /etc/nginx/sites-enabled/*; 
}" 
+0

У меня такая же проблема, смогли ли вы найти решение? – Prat

+0

Я не нашел решения, кроме изящной перезагрузки рабочих, когда это необходимо. – ALT

ответ

0

Вы начинаете uWSGI императора , поэтому вам не следует передавать wsgi-файл прямо на него. Удалите этот параметр из файла uwsgi.conf.

При использовании императора вы не должны демонтировать свои экземпляры uWSGI, потому что император потеряет связь с ним, что, вероятно, вызывает появление новых экземпляров по каждому запросу (император не знает, что есть некоторые случаи, потому что они demonized, поэтому он создает новую для обработки запросов). Вы должны удалить daemonize из конфигурации uWSGI.

Кроме того, использование vhost, когда явно указывать на файл wsgi, не должно быть сделано. Если вы не знаете, что этот параметр делает или не думает, что он вам нужен, удалите его.

После изменений, ваши файлы должны выглядеть следующим образом:

uwsgi.ini файла:

[uwsgi] 


socket = /tmp/mySocket.sock 
master = true 
processes = 4 
max_request = 300 
vacuum = true 
die-on-term = true 
close-on-exec = true 
harakiri = 30 
wsgi-file = /home/virtualEnv/server/wsgi.py 
virtualenv = /home/virtualEnv 
pythonpath = /home/virtualEnv/myServer 
chdir=/home/virtualEnv/myServer 
pidfile=/tmp/myFile.pid 
log-reopen = true 
chmod-socket = 664 

gid = www-data 
uid = www-data 

uwsgi.conf файл:

description "uWSGI Emperor" 
start on runlevel [2345] 
stop on runlevel [!2345] 

respawn 
exec uwsgi --emperor /etc/uwsgi/vassals/ 

wsgi.py файл не изменится.

Если вы хотите иметь логи с вашего uwsgi сервера используйте:

logger     = file:/var/log/uwsgi/[email protected](exec://date +%%Y-%%m-%%d).log 

вместо daemonize.

+0

Большое вам спасибо за ваш ответ. Я пробовал настройки, которые вы предлагали, но проблема, похоже, сохраняется. Рабочие никогда, похоже, не перезаряжаются. Например, если я устанавливаю значение max_request равным 5, не следует ли перезагружать рабочих после того, как они обслужили 5 запросов? – ALT

+0

Пожалуйста, покажите свою конфигурацию nginx и конфигурацию uWSGI после изменений, о которых я упоминал – GwynBleidD

Смежные вопросы