7

I have a webapp that is using an API built on nginx, uWSGI, and Django. Recently I have been seeing a lot of harakiris on a particular API call which does some quick processing and then spawns a few threads to handle some long-running functions. The main thread then returns and the worker threads store their results in a cache and exit. After the threads are spawned, there is no interaction between them.

My uWSGI is set to harakiri at 20 seconds. This should be ample time for the main thread to finish and return (it's average is about 2-3 seconds). Is it possible that uWSGI is harakiri-ing because my worker threads are taking too long to return? If so, could I fix this by using multiprocessing instead of multithreading in python?

Thanks!

jmetz
  • 181
  • 4

1 Answers1

0

These options will come in very handy to figure out what exactly is going on with the harakiri feature:

harakiri-verbose=true

enable verbose mode for harakiri

py-tracebacker=/path/to/socket

enable the uWSGI python tracebacker

Read from that socket to see the traceback (uWSGI conveniently ships a --connect-and-read=/path/to/socket option).

You can also investigate the post-request thread status and log diagnostics by setting uwsgi.after_req_hook = callback. Before this method is called the harakiri mode can explicitly disabled:

harakiri-no-arh=true

do not enable harakiri during after-request-hook

anx
  • 6,875
  • 4
  • 22
  • 45
  • The details are unrelated to this particular question, but until I write the Q&A for that: uWSGI is a bit funny with the order of the socket and touch-reload options, so an ongoing reload and indeed long-running threads mislead me into thinking the harakiri feature misbehaved. After adding various logging verbosity and diagnostic options such as these the situation became clear. – anx Sep 19 '21 at 21:41