uWSGI: Python concurrent.futures зависает на всех процессах uWSGI, кроме одного

Я использую модуль concurrent.futures Python (версия модуля 2.1.3, версия Python 2.7.3). У меня есть nginx, работающий с 4 рабочими процессами, и 4 запущенных uWSGI (в Ubuntu точно) в качестве демона выскочки со следующей конфигурацией uwsgi (обратите внимание, что enable-threads — это правда, поэтому GIL доступен, а lazy — это правда):

virtualenv=[ path to venv ]
chdir=[ path to python project ]
enable-threads=true
lazy=true
buffer-size=32768
post-buffering=true
processes=4
master=true
module=[ my app ].wsgi
callable=wsgi_app
logto=/var/log/uwsgi.log
pidfile=[ replaced ]
plugins=python27
socket=[ replaced, but works fine ]

Все приложение работает нормально, но кажется, что какой-то отсутствующий контекст недоступен для пула фьючерсов: когда я вызываю somefunc() без future(), все хорошо, но когда я вызываю somefunc() с future, HTTP-запрос ( Я использую Flask) зависает довольно долго, прежде чем сбой.

Единственные записи в файле журнала связаны с HTTP-запросами и общими элементами запуска wsgi, такими как:

WSGI application 0 (mountpoint='') ready on interpreter 0x11820a0 pid: 26980 (default app)

Как я могу получить некоторое представление о выполнении фьючерсов или выяснить, какой контекст может быть недоступен для пула фьючерсов?

Имеет ли это смысл?

Заранее спасибо.


person Zach    schedule 19.02.2013    source источник


Ответы (1)


Если вы используете ProcessPoolExecutor вместо потоков, обязательно добавьте close-on-exec в параметры uWSGI, иначе сокет соединения с клиентом/веб-сервером будет унаследован после fork()

person roberto    schedule 20.02.2013
comment
Спасибо, это отличное предложение, но мне не повезло. Я добавил: close-on-exec=true... в свою конфигурацию uWSGI и перезапустил nginx и uWSGI. Я понимаю, почему это может решить проблему, но я все еще получаю тайм-ауты. - person Zach; 20.02.2013
comment
На самом деле, может быть, я не понимаю. Чтобы уточнить ... в основном процесс, порождающий будущее, по умолчанию наследует файловые дескрипторы, открытые порождающим. Почему это может привести к тайм-ауту? - person Zach; 20.02.2013
comment
потому что, когда вы наследуете дескриптор файла, у вас есть две ссылки на него, и когда рабочий закрывает соединение, сокет остается открытым - person roberto; 20.02.2013
comment
Попался. Включил close-on-exec и перезапустил, но безрезультатно. Оказывается, тайм-ауты были связаны с тем, что пулы фьючерсов не запускались для некоторых дочерних процессов uWSGI. Итак, теперь проблема не в зависании, а в отсутствии понимания того, почему вызовы фьючерсов терпят неудачу. - person Zach; 20.02.2013
comment
ну, вы должны опубликовать какой-то код, возможно, что-то мешает работе нескольких рабочих (даже если ничего не всплывает в моей голове) - person roberto; 20.02.2013