我的Django项目运行在gunicorn上 。 有时加载一个页面（和oracle程序调用相关）需要很多时间。 服务器在几分钟内保持非活动状态时，会发生90/100。 我怎样才能解决这个问题？ wsgi.py import os import site import sys from whitenoise.django import DjangoWhiteNoise # Add the site-packages of the chosen virtualenv to work with site.addsitedir('/new_esmart/esmart_env/lib/python2.7/site-packages') # Add the app's directory to the PYTHONPATH sys.path.append('/new_esmart/esmart2') sys.path.append('/new_esmart/esmart2/esmart2') os.environ.setdefault("DJANGO_SETTINGS_MODULE", "esmart2.settings") # Activate your virtual env activate_env = os.path.expanduser("/new_esmart/esmart_env/bin/activate_this.py") execfile(activate_env, dict(__file__=activate_env)) from django.core.wsgi import get_wsgi_application application […]
我试图在主pipe中运行一个gunicorn_django进程，但它总是立即退出，出现这个错误： INFO exited: my_app (exit status 1; not expected) INFO received SIGCLD indicating a child quit INFO gave up: my_app entered FATAL state, too many start retries too quickly 我的服务器脚本如下所示： #!/bin/bash set -e LOGFILE=/var/log/gunicorn/my_app.log LOGDIR=$(dirname $LOGFILE) NUM_WORKERS=3 USER=my-www-user GROUP=my-www-user cd /home/my-www-user/my_app source /home/my-www-user/.virtualenvs/my_app/bin/activate test -d $LOGDIR || mkdir -p $LOGDIR gunicorn_django -w $NUM_WORKERS –debug \ […]
我有一个使用mod_proxy在Apache后面的gunicorn服务器。 Gunicorn在http://localhost:8080/ 。 假设我的服务器位于http://example.com/ 有时，当我发布一个无效的链接到我的服务器（如忘记尾随），让我们说http://example.com/with-no-trailing-slash ，用户被redirect到http://localhost:8080/with-no-trailing-slash ，因为客户机上没有服务器，所以无效。 你知道为什么它的行为？ 如何解决这个问题？ 要启动gunicorn我这样做： sudo gunicorn -b localhost:8080 app:app <VirtualHost *:80> ServerName example.com ServerAlias example.com DocumentRoot /opt/example <Proxy *> AuthType basic AuthBasicAuthoritative Off SetEnv proxy-chain-auth On Order allow,deny Allow from all </Proxy> # Let apache serve static files ProxyPass /robots.txt ! ProxyPass /favicon.ico ! ProxyPass /static/ ! Alias /static/ […]
我们的应用程序的REST API由运行在具有典型自动缩放/负载平衡设置的AWS EC2实例上的Gunicorn（ 不在 Nginx后面）提供服务。 负载均衡器的空闲超时时间为60秒，Gunicorn的保持活动超时时间为2秒。 我们已经看到来自这个configuration的零星的504 Gateway Timeout响应。 根据亚马逊的文档 ，这可能是因为服务器的保持活动超时低于负载平衡器的空闲超时设置： 原因2：已注册的实例closures与Elastic Load Balancing的连接。 解决scheme2：在您的EC2实例上启用保持活动设置，并将保持活动超时设置为大于或等于负载平衡器的空闲超时设置。 使用Nginx，默认的keepalive_timeout是75秒，这与ELB的默认设置很相配。 但是， Gunicorn文档build议在1-5秒的范围内设置keepalive 。 把Gunicorn的keepalive碰到75秒是否有意义，或者有一个很好的理由让它保持在5秒以下，即使我们没有在它前面使用反向代理？
我希望在Nginx后面的Gunicorn运行Trac。 Nginx通过LDAP处理用户身份validation，但是我无法将REMOTE_USER传递给Trac。 对于uWSGI我会像这样configurationNginx（经过testing，工作正常）： uwsgi_param REMOTE_USER $remote_user; 对于Gunicorn，我找不到类似的configuration指令。 我试图设置标题，但它似乎并没有改变任何东西： proxy_set_header REMOTE_USER $remote_user; 在Trac wiki中有一个关于这个的条目 ，指出“wsgi入口点不处理authentication” ，以及一个用本地密码文件处理基本authentication的解决方法，这不是我所需要的。 我是否需要更改我的入口点以将此REMOTE_USER标头传递给正确的环境variables？ 目前只是这样的： import sys import os sys.stdout = sys.stderr os.environ['TRAC_ENV'] = '/path/to/my/trac' import trac.web.main application = trac.web.main.dispatch_request
我有一个dev服务器在nginx后面运行gunicorn / Django。 作为更广泛的服务器环境更新的一部分，我试图将gunicorn从18.0升级到19.2.1，但服务将不再启动。 （服务器正在运行Arch，因此使用systemctl。） gunicorn的configuration是由一个已经不在我们手中的人来完成的，并且不是真的知道gunicorn那么好，我无法修复，甚至找不到这个问题，所以我回到了18.0版本，现在它已经在运行了。 不过，我想最终升级它，并将其configuration成可以工作的形状。 我有一种感觉，目前的configuration是不是最理想的或多余的，但我无法肯定知道:-)。 在环境中没有任何变化（或者是运行在gunicorn的virtualenv），只有gunicorn本身被升级。 Systemctl在systemctl start gunicorn上产生这个错误： ● gunicorn.service – gunicorn daemon (production) Loaded: loaded (/usr/lib/systemd/system/gunicorn.service; enabled) Active: failed (Result: resources) since Tue 2015-02-17 20:55:41 UTC; 8s ago Process: 2837 ExecStop=/bin/kill -s QUIT $MAINPID (code=exited, status=0/SUCCESS) Process: 9608 ExecReload=/bin/kill -s HUP $MAINPID (code=exited, status=0/SUCCESS) Process: 5353 ExecStart=/home/django/gunicorn/run.sh (code=exited, status=0/SUCCESS) Main […]
在configuration了django，gunicorn，supervisor和nginx的服务器上运行非常高的stream量。 但很多时候，我倾向于看到502错误。 所以我检查了nginx日志，看看是什么错误，这是logging： [错误] 2388＃0：* 208027连接（）到unix：/tmp/gunicorn-ourapp.socket失败（11：资源暂时不可用），同时连接到上游 任何人都可以帮助debugging可能会导致这种情况发生？ 这是我们的nginxconfiguration： sendfile on; tcp_nopush on; tcp_nodelay off; listen 80 default_server; server_name imp.ourapp.com; access_log /mnt/ebs/nginx-log/ourapp-access.log; error_log /mnt/ebs/nginx-log/ourapp-error.log; charset utf-8; keepalive_timeout 60; client_max_body_size 8m; gzip_types text/plain text/xml text/css application/javascript application/x-javascript application/json; location / { proxy_pass http://unix:/tmp/gunicorn-ourapp.socket; proxy_pass_request_headers on; proxy_read_timeout 600s; proxy_connect_timeout 600s; proxy_redirect http://localhost/ http://imp.ourapp.com/; #proxy_set_header Host $host; #proxy_set_header X-Real-IP […]
我有一个安装了SSL证书的nginx服务器。 我想通过任何请求上游到我的运行在0.0.0.0:8000 Gunicorn服务器。 但是，每当我运行Gunicorn服务器，它给我一个错误，说有太多的redirect循环。 如果我通过https运行gunicorn，那么连接将变得安全，但它不会连接到gunicorn服务器，它只会说bad gateway 。 另外，这里是我尝试连接时运行gunicorn与https的错误： Traceback (most recent call last): File "/opt/bitnami/python/lib/python2.7/site-packages/gunicorn/arbiter.py", line 515, in spawn_worker worker.init_process() File "/opt/bitnami/python/lib/python2.7/site-packages/gunicorn/workers/base.py", line 126, in init_process self.run() File "/opt/bitnami/python/lib/python2.7/site-packages/gunicorn/workers/sync.py", line 119, in run self.run_for_one(timeout) File "/opt/bitnami/python/lib/python2.7/site-packages/gunicorn/workers/sync.py", line 66, in run_for_one self.accept(listener) File "/opt/bitnami/python/lib/python2.7/site-packages/gunicorn/workers/sync.py", line 30, in accept self.handle(listener, client, addr) File "/opt/bitnami/python/lib/python2.7/site-packages/gunicorn/workers/sync.py", line 141, in […]
我正在用DUNG（Django，Unix，Nginx和Gunicorn）环境运行Ubuntu 12.04 Precise，并且我的应用程序（以及各种configuration文件）存储在www-data用户有权访问的/srv内的python虚拟环境中至。 nginx和gunicorn进程都是以www-data运行的。 我的networking应用程序需要安全凭证，我将其存储在environment.sh文件中。 该文件包含各种导出，并在gunicorn进程执行之前使用source文件运行。 我关心的是environment.sh文件的位置，它的权限。 将这个文件存储在www-data有权访问的/srv文件夹中会好吗？ 或者它应该被其他地方的根存储和拥有，比如/var/myapp/environment.sh ？ 另外，对于www-data用户，如果我的任何web进程（以www-data运行）都受到攻击并且有人可以访问它们，这是否意味着用户可能会读取系统上的任何文件，即使他们不能写？ 包括我的安全密钥？
只有当gunicorn通过supervisord启动时，我的virtualenv + gunicorn设置有一个奇怪的问题。 我意识到，这可能是我的supervisord很好的问题，我会很感激任何反馈在一个更好的地方寻求帮助… 简而言之：当我从我的用户shell中运行gunicorn时，在我的virtualenv中，一切都在完美地运行。 我能够访问我的Django项目的所有视图。 supervisord在系统启动时启动gunicorn时，一切正常。 但是，如果我必须杀死gunicorn_django进程，或者如果我执行supervisord重新启动，那么一旦gunicorn_django重新启动，每个请求都会用一个奇怪的Traceback回答： (…) File "/home/hc/prod/venv/lib/python2.6/site-packages/Django-1.2.5-py2.6.egg/django/db/__init__.py", line 77, in connection = connections[DEFAULT_DB_ALIAS] File "/home/hc/prod/venv/lib/python2.6/site-packages/Django-1.2.5-py2.6.egg/django/db/utils.py", line 92, in __getitem__ backend = load_backend(db['ENGINE']) File "/home/hc/prod/venv/lib/python2.6/site-packages/Django-1.2.5-py2.6.egg/django/db/utils.py", line 50, in load_backend raise ImproperlyConfigured(error_msg) TemplateSyntaxError: Caught ImproperlyConfigured while rendering: 'django.db.backends.postgresql_psycopg2' isn't an available database backend. Try using django.db.backends.XXX, where XXX is one of: 'dummy', 'mysql', […]