Уведомления

Группа в Telegram: @pythonsu

#1 Май 12, 2009 10:40:19

ZAN
От:
Зарегистрирован: 2007-06-10
Сообщения: 403
Репутация: +  10  -
Профиль   Отправить e-mail  

Устойчивость демона при segmentation fault

У меня есть демон (на twisted), который ожидает POST запросы и пишет кое-какую информацию в PostrgreSQL базу, при чем постгресовский модуль сигфолтит (будем считать это за данное).
Собственно, какие будут рекоммендации, как сделать демон устойчивым?
У меня есть следующие идеи:
1. Пересобрать питон с возможностью перехвата segmentation fault (привел просто как вариант).
2. Запускать демон из башевского скрипта бесконечным циклом. Т.е. сразу по завершению дочернего процесса (процесса twisted, запущенного “twistd -ny server.tac”), он будет перезапущен заново. Минус - рутовый логгер по-умолчанию пишет в stdout, т.е. в никуда.
3. Разделить логику на “seg fault safe (1)” и “seg fault non-safe (2)” и запускать (2) из (1), взаимодействовать через perspective broker или через еще что-нибудь подобное. В этом случае - полное разделени ввода-вывода, что само по себе не так уж и плохо, но во-первых - дополнительные потери скорости, во-вторых усложнение архитектуры.
А кто как-то по-другому решал такую проблему?



Офлайн

#2 Май 12, 2009 10:53:41

slivlen
От:
Зарегистрирован: 2006-07-06
Сообщения: 764
Репутация: +  0  -
Профиль   Отправить e-mail  

Устойчивость демона при segmentation fault

ZAN
Минус - рутовый логгер по-умолчанию пишет в stdout, т.е. в никуда.
И что мешает перенаправить вывод?



Офлайн

#3 Май 12, 2009 11:02:49

ZAN
От:
Зарегистрирован: 2007-06-10
Сообщения: 403
Репутация: +  10  -
Профиль   Отправить e-mail  

Устойчивость демона при segmentation fault

Ничего не мешает :)
Но вообще говоря, если демон полностью конфигурируется из config файла, то это значит, что скрипт-запускатель его тоже должен парсить. С другой стороны, можно просто забить на этот логгер и использовать только свои, или попробовать его перенастроить.
Основной вопрос все-таки - как еще можно решить проблему?



Офлайн

#4 Май 13, 2009 18:53:31

Андрей Светлов
От:
Зарегистрирован: 2007-05-15
Сообщения: 3137
Репутация: +  14  -
Профиль   Адрес электронной почты  

Устойчивость демона при segmentation fault

У нас тоже регулярно крашится.
Сидит демон-мастер, следит за порожденными сервисами (их больше десятка, разные задачи у каждого типа и некоторые запускаются в 2-3 экземплярах).
Если кто-то помер - нужно запустить заново. Общаются через очередь сообщений.



Офлайн

#5 Май 14, 2009 10:17:13

ZAN
От:
Зарегистрирован: 2007-06-10
Сообщения: 403
Репутация: +  10  -
Профиль   Отправить e-mail  

Устойчивость демона при segmentation fault

А можно чуть по-подробнее про очередь сообщений? Это я так понимаю, паттерн посредник, где посредник - это демон мастер?



Офлайн

#6 Май 15, 2009 21:07:21

Андрей Светлов
От:
Зарегистрирован: 2007-05-15
Сообщения: 3137
Репутация: +  14  -
Профиль   Адрес электронной почты  

Устойчивость демона при segmentation fault

нет. У нас это Java JMS в проприентарной реализации Sonic. Apache ActiveMQ пятой версии сильно глюкава, а четвертая - слишком слаба.
Думаю, это - не лучшее решение.
Очень привлекательно выглядит AMQP. На PyCon общался с ребятами, которые применяют у себя RabbitMQ - были очень довольны.

В любом случае использование MQ позволяет легче распарралеливать задачи и при этом вполне доступно разработчикам с оносительно невысокой культурой программирования. Хоть и ценой некоторого снижения возможного предела быстродействия (несущественный на самом деле аргумент).



Офлайн

#7 Май 15, 2009 23:18:46

ZAN
От:
Зарегистрирован: 2007-06-10
Сообщения: 403
Репутация: +  10  -
Профиль   Отправить e-mail  

Устойчивость демона при segmentation fault

Спасибо. Есть над чем поразмыслить



Офлайн

Board footer

Модераторировать

Powered by DjangoBB

Lo-Fi Version