DjangoBB LoFi version

Полная версия: Архитектура приложения. Отказоустойчивость.

Начало » Python для новичков » Архитектура приложения. Отказоустойчивость.

1 2 3

Budulianin

Авг. 21, 2014 18:03:00

s0rg
За него не скажу, но у flask есть специальный обработчик всех ошибок, типа финализатор запроса, возможно, что-то подобное есть в и пирамиде.

Мне кажется это не будет работать, потому что воркер убивается 9 сигналом и никто его ждать не будет.

DAMN ! worker 2 (pid: 4247) died, killed by signal 9 :( trying respawn ...
Respawned uWSGI worker 2 (new pid: 4457)

s0rg
типа финализатор запроса

Запрос не успевает закончиться.

Budulianin

Авг. 21, 2014 18:09:36

Я ещё думаю, что проблема может быть в time out uWSGI.
Главный процесс видит, что воркер тупит с запросом и убивает его.
Наверняка есть настройка time out uWSGI. Может если поставить его больше, то воркер не будут убивать.

Но это не исправит архитектуру приложения.

s0rg

Авг. 21, 2014 18:27:06

Budulianin
Наверняка есть настройка time out uWSGI

Настройка-то есть. Только это настройка именно uWsgi.
А есть еще сервер выше.
У меня был проект веб-интерфейса к хитрой службе, единственный канал взаимодействия с котрой был через thrift, само приложение работало штатно, но на крупных париях данных, thrift начинал тупить.
Я выкрутил все тайм-ауты на максимум (приложение для внутреннего использования) как у uWSGI так и у веб-сервера (nginx в моем случае) - но приложение все-равно дохло, если не успевало ответить за время
около минуты. Что именно его прибивало - я так и не смог понять.

s0rg

Авг. 21, 2014 18:32:03

Budulianin
Мне кажется это не будет работать, потому что воркер убивается 9 сигналом и никто его ждать не будет.

А как это произошло? Это проверка sleep-ом?

Budulianin

Авг. 21, 2014 19:24:12

s0rg
А как это произошло? Это проверка sleep-ом?

Нет, ты посоветовал “прибирать” БД в “финализаторе”, типо если воркер будет падать, то этот “финализатор” отработает и почистит БД.

А я говорю, что никто не даст этому “финализатору” отработать(не успеет), потому что главный процесс uWSGI убивает воркер 9 сигналом, когда делает вывод, что он “тупит”.

s0rg

Авг. 21, 2014 20:31:57

А! Теперь понял.
По поводу финализатора - это была мысль, касательно ‘отвалившихся’ клиентов и только о них.

Budulianin

Авг. 21, 2014 20:49:40

s0rg
А есть еще сервер выше.

У меня: клиент -> nginx -> uWSGI.

Так что можно подкрутить time out. В разумных пределах конечно, потому что долгие запросы никому не нужны, такие воркеры, пусть погибают(не знаю будут ли такие ситуации в реале на продакшене). Похоже действительно нужно об очередях подумать.

FishHook

Авг. 22, 2014 05:17:46

Мне кажется, или вы сейчас заново изобретаете транзакции?

Budulianin

Авг. 22, 2014 09:52:06

To Fishhook

У меня mongodb. Там нельзя объединять несколько запросов в одну транзакцию.

o7412369815963

Авг. 22, 2014 12:07:11

Budulianin
А я говорю, что никто не даст этому “финализатору” отработать(не успеет), потому что главный процесс uWSGI убивает воркер 9 сигналом,

В uWSGI есть фича перезапуска приложения при обновлении (файлов), дак вот там тоже рубит -9, никакие финализаторы не срабатывают.

Если запрос висит долго - плохо, так можно лекго заддосить, забить все потоки и т.п. Как выше упомянули - очереди.
У меня в одном из проектов формирование страницы (индикатора) занимает от 2 - 200 сек. За счет того что фоново происходит предрасчет всех кешей (правда не для всех задач такое подойдет) - все страницы открываются мгновенно.