Я столкнулся с одной ошибкой в своем веб-приложении, которая работала более года назад, и когда я переключился на UWSGI на новом экземпляре, чтобы немного ускорить работу, я столкнулся с этим.
В моем приложении есть модальное окно «быстрое добавление», которое позволяет пользователю добавить нового клиента в базу данных и сразу же перейти в корзину для этого пользователя. Итак, модуль делает POST
запрос к /customers/quick_create/
, который выполняет перенаправление на /cart/10000
, где 10000
— идентификатор клиента. Затем начинается самое интересное.
Поскольку на этом /cart
есть проверка, есть ли покупатель с таким идентификатором или нет, я заметил, что проверка активируется, и когда этот запрос сделан, пользователь перенаправляется на резервную ссылку, в реальную корзину. Это код, который выполняет проверку:
q = Customer.query.filter_by(id=cust).first()
if q is None:
return redirect('/customers/')
Проверка существует, потому что кто-то может попасть на этот этап не только через этот модальный режим. И иногда пользователь попадает на резервный URL, иногда на /cart
. В во всех случаях клиент фактически создан, я могу перейти к нему позже и увидеть его в базе данных, поэтому по какой-то причине этот SQL-запрос не находит клиента с таким идентификатором.
Я проверил журналы USGI, и вот краткий отрывок:
/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py:324: Warning: Data truncated for column 'refill_date' at row 1
cursor.execute(statement, parameters)
[pid: 5197|app: 0|req: 1/1] 123.123.123.123 () {54 vars in 1285 bytes} [Tue Feb 3 14:34:59 2015] POST /customers/quick_create/ => generated 237 bytes in 43 msecs (HTTP/1.1 302) 4 headers in 421 bytes (2 switches on core 0)
Tue Feb 3 14:34:59 2015 - ...The work of process 5197 is done. Seeya!
[pid: 5200|app: 0|req: 1/2] 123.123.123.123 () {48 vars in 1118 bytes} [Tue Feb 3 14:35:00 2015] GET /cart/16198/ => generated 229 bytes in 42 msecs (HTTP/1.1 302) 4 headers in 417 bytes (1 switches on core 0)
Tue Feb 3 14:35:00 2015 - ...The work of process 5200 is done. Seeya!
Tue Feb 3 14:35:00 2015 - worker 1 killed successfully (pid: 5197)
Tue Feb 3 14:35:00 2015 - Respawned uWSGI worker 1 (new pid: 5218)
Tue Feb 3 14:35:00 2015 - worker 4 killed successfully (pid: 5200)
Tue Feb 3 14:35:00 2015 - Respawned uWSGI worker 4 (new pid: 5219)
Tue Feb 3 14:35:00 2015 - mapping worker 4 to CPUs: 0
Tue Feb 3 14:35:00 2015 - mapping worker 1 to CPUs: 0
Tue Feb 3 14:35:03 2015 - WSGI app 0 (mountpoint='') ready in 3 seconds on interpreter 0x1dd1630 pid: 5219 (default app)
Tue Feb 3 14:35:03 2015 - mounting uwsgi on /
Tue Feb 3 14:35:03 2015 - WSGI app 0 (mountpoint='') ready in 3 seconds on interpreter 0x1dd1630 pid: 5218 (default app)
Tue Feb 3 14:35:03 2015 - mounting uwsgi on /
[pid: 5199|app: 0|req: 1/3] 123.123.123.123 () {48 vars in 1110 bytes} [Tue Feb 3 14:35:00 2015] GET /customers/ => generated 3704543 bytes in 3402 msecs (HTTP/1.1 200) 3 headers in 370 bytes (18 switches on core 0)
Tue Feb 3 14:35:03 2015 - ...The work of process 5199 is done. Seeya!
Tue Feb 3 14:35:04 2015 - worker 3 killed successfully (pid: 5199)
Tue Feb 3 14:35:04 2015 - Respawned uWSGI worker 3 (new pid: 5226)
Tue Feb 3 14:35:04 2015 - mapping worker 3 to CPUs: 0
Tue Feb 3 14:35:05 2015 - WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0x1dd1630 pid: 5226 (default app)
Tue Feb 3 14:35:05 2015 - mounting uwsgi on /
Это моя конфигурация UWSGI:
<uwsgi>
<plugin>python</plugin>
<socket>/run/uwsgi/app/example.com/example.com.socket</socket>
<pythonpath>/srv/www/example.com/application/</pythonpath>
<app mountpoint="/">
<script>uwsgi</script>
</app>
<master/>
<callable>app</callable>
<module>app</module>
<processes>4</processes>
<harakiri>60</harakiri>
<reload-mercy>8</reload-mercy>
<cpu-affinity>1</cpu-affinity>
<stats>/tmp/stats.socket</stats>
<max-requests>2000</max-requests>
<limit-as>512</limit-as>
<reload-on-as>256</reload-on-as>
<reload-on-rss>192</reload-on-rss>
<no-orphans/>
<vacuum/>
<lazy-apps/>
</uwsgi>
Мне действительно кажется странным, что UWSGI убивает этого воркера сразу после запроса. Когда есть запрос на некоторые статические файлы, для каждого запроса есть новые PID.
Этого не происходит на mod_wsgi с экземпляром Apache. Время от времени процессор загружается до 100%, но средняя загрузка в порядке, 0.25, 0.22, 0.15
на момент написания, а использование ОЗУ составляет около 300 из 900 МБ.
Может ли кто-нибудь указать мне правильное направление? Спасибо