пушистые нити молча убивают - PullRequest
Новая
       7

пушистые нити молча убивают

0 голосов
/ 23 марта 2020

версия gunicorn 19.9.0

Получил следующую конфигурацию gunicorn: 

accesslog = "access.log"
worker_class = 'sync'
workers = 1
worker_connections = 1000
timeout = 300
graceful_timeout = 300
keepalive = 300
proc_name = 'server'
bind = '0.0.0.0:8080'
name = 'server.py'
preload = True
log_level = "info"

threads = 7
max_requests = 0
backlog = 100

Как видите, сервер настроен для работы 7 потоков.

сервер запускается с: 

gunicorn -c gunicorn_config.py server:app

Вот количество строк и идентификаторов потоков из нашего файла журнала в начале (последняя строка является потоком основного сервера): 

  10502 140625414080256
  10037 140624842843904
   9995 140624859629312
   9555 140625430865664
   9526 140624851236608
   9409 140625405687552
   2782 140625422472960
      6 140628359804736

Итак, 7 потоков обрабатывают запросы. (Мы уже видим, что поток 140625422472960 обрабатывает существенно меньше запросов, чем другие потоки.)

Но после рассмотренных выше строк поток 140625422472960 просто исчезает, а в файле журнала только: 

  19602 140624859629312
  18861 140625405687552
  18766 140624851236608
  18765 140624842843904
  12523 140625414080256
   2111 140625430865664
  (excluding the main thread here)

Из журналов сервера мы могли видеть, что поток получил запрос и начал его обрабатывать, но так и не закончил. Клиент также не получил ответа.

Нет ошибок или предупреждений ни в файле журнала, ни в stderr.

И если запустить приложение немного дольше, пропадут еще два потока: 

102 140624842843904
102 140624851236608
 68 140624859629312
 85 140625405687552

Как это отладить?

1 Ответ

0 голосов
/ 28 марта 2020

Продолжая копаться в журналах stderr, наконец-то нашел что-то вроде трассировки стека исключений: 

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/gunicorn/workers/sync.py", line 134, in handle
    req = six.next(parser)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/parser.py", line 41, in __next__
    self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 181, in __init__
    super(Request, self).__init__(cfg, unreader)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 54, in __init__
    unused = self.parse(self.unreader)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 230, in parse
    self.headers = self.parse_headers(data[:idx])
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 74, in parse_headers
    remote_addr = self.unreader.sock.getpeername()
OSError: [Errno 107] Transport endpoint is not connected
[2018-11-04 17:57:55 +0330] [31] [ERROR] Socket error processing request.
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/gunicorn/workers/sync.py", line 134, in handle
    req = six.next(parser)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/parser.py", line 41, in __next__
    self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 181, in __init__
    super(Request, self).__init__(cfg, unreader)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 54, in __init__
    unused = self.parse(self.unreader)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 230, in parse
    self.headers = self.parse_headers(data[:idx])
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 74, in parse_headers
    remote_addr = self.unreader.sock.getpeername()
OSError: [Errno 107] Transport endpoint is not connected

Это связано с ошибкой gunicorn .

Промежуточным Решение до тех пор, пока эта ошибка не будет исправлена, состоит в том, чтобы обезьяна исправила gunicorn, как сделано asantoni .

...