0

I'm seeing the following in the uWSGI logs, specifically ...The work of process 43017 is done. Seeya!:

[pid: 43017|app: 0|req: 103/114] 207.140.171.16 () {50 vars in 847 bytes} [Fri Oct 17 12:59:49 2014] POST /v1/us/notification => generated 320 bytes in 326 msecs (HTTP/1.1 200) 2 headers in 72 bytes (1 switches on core 0)
[pid: 43017|app: 0|req: 104/115] 207.140.171.16 () {50 vars in 847 bytes} [Fri Oct 17 12:59:53 2014] POST /v1/us/notification => generated 319 bytes in 409 msecs (HTTP/1.1 200) 2 headers in 72 bytes (1 switches on core 0)
[pid: 43017|app: 0|req: 105/116] 207.140.171.16 () {50 vars in 847 bytes} [Fri Oct 17 12:59:54 2014] POST /v1/us/notification => generated 318 bytes in 487 msecs (HTTP/1.1 200) 2 headers in 72 bytes (1 switches on core 0)
[pid: 43017|app: 0|req: 106/117] 207.140.171.16 () {50 vars in 847 bytes} [Fri Oct 17 12:59:55 2014] POST /v1/us/notification => generated 318 bytes in 746 msecs (HTTP/1.1 200) 2 headers in 72 bytes (1 switches on core 0)
[pid: 43017|app: 0|req: 107/118] 207.140.171.16 () {50 vars in 847 bytes} [Fri Oct 17 12:59:56 2014] POST /v1/us/notification => generated 319 bytes in 644 msecs (HTTP/1.1 200) 2 headers in 72 bytes (1 switches on core 0)
...The work of process 43017 is done. Seeya!
[pid: 43022|app: 0|req: 7/119] 207.140.171.16 () {50 vars in 846 bytes} [Fri Oct 17 12:59:57 2014] POST /v1/us/notification => generated 320 bytes in 445 msecs (HTTP/1.1 200) 2 headers in 72 bytes (1 switches on core 0)
worker 2 killed successfully (pid: 43017)
Respawned uWSGI worker 2 (new pid: 43158)
mapping worker 2 to CPUs: 1 0 1
WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0x20e99d0 pid: 43158 (default app)
[pid: 43018|app: 0|req: 1/120] 207.140.171.16 () {50 vars in 847 bytes} [Fri Oct 17 12:59:59 2014] POST /v1/us/notification => generated 320 bytes in 523 msecs (HTTP/1.1 200) 2 headers in 72 bytes (1 switches on core 0)
announcing my loyalty to the Emperor...

It appears that I'm losing requests when this happens. I'm at a loss as to where to look at this for a fix or if it is this that seems to cause the requests to drop. If I can include anything else please let me know.

I have uWSGI running with the following configs:

/etc/init/uwsgi.conf:

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

respawn

exec uwsgi --emperor /etc/uwsgi/apps-enabled --uid root --gid root --logto /var/log/uwsgi/uwsgi.log

/etc/uwsgi/apps-enabled/app.ini:

[uwsgi]
; define variables to use in this script
; process name for easy identification in top
project = agent
base_dir = /var/www/app/%(project)
chdir = %(base_dir)
plugins = python
virtualenv = %(base_dir)/env
uid = www-data
gid = www-data
procname = %(project)

; This value needs to be tuned
workers = 8
max-request = 4000
harakiri = 300
reload-mercy = 8
cpu-affinity = 3
limit-as = 1024
reload-on-as = 512
reload-on-rss = 192
no-orphans = True
master = True

; Create pid file for easier process management
pidfile = %(base_dir)/run/%(project).pid

; Specify your app here
wsgi-file = %(base_dir)/project/%(project)-wsgi.py
log-reopen = True
logto = %(base_dir)/logs/uwsgi.log
chmod-socket = 666
vacuum = True
enable-threads = True
lazy-apps = True

; unix socket
socket = /tmp/%(project)-server.sock
; Enable stats
stats = /tmp/%(project)-stats.sock
8
  • Is there any reason why you think it is losing requests ?
    – roberto
    Oct 17 '14 at 14:46
  • A large number of requests were sent into both the staging and production system at the same time. The staging system received them without any issue and created the data that was part of the post request and didn't have the above log entry where as the production system is missing the data of 4 of the requests that were sent in and has the above log entry.
    – Nalum
    Oct 17 '14 at 14:55
  • if you refer to the "seeya" entries, they are expected as you configured max-requests, but they happen after the request has been served (infact you see uWSGI logging it successfully). A part from this one, having limit-as (expecially on 64bit system) is a truly bad idea. Btw, check nginx logs, they will show for sure if some request failed.
    – roberto
    Oct 17 '14 at 16:08
  • Okay so I shouldn't be setting the limit-as?
    – Nalum
    Oct 17 '14 at 16:09
  • well, it limits the address space of the process, it may work on 32bit systems where the address space cannot raise over 2/4GB, but on 64bit systems it is very easy to use/abuse it for mmapping files or other advanced things
    – roberto
    Oct 17 '14 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.