LINUX.ORG.RU

[python2] как пинать демона?


0

1

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

Как это сделать наиболее Ъ? Сокет поднимать кажется толстоватым, под очереди сообщений я видел только puipc который в стандартную поставку не входит, но в приниципе юзабилитен.

И неск. смущает однопоточность демона - его задача собирать запикленные файлы в некое подобие индексов, и нужен он что бы писал в индексы кто то один. Операции относительно простые, но временами он может задумываться на десятки секунд, как бы при этом не потерять все накопившиеся задания...

★★★★★

dbus-python?

anonymous
()

Сокет - самое легковесное решенеие, если что. Не тащит с собой ничего, кроме стандартного рантайма.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Да, но тогда придется демона усложнять - как мин в один проток работа с сокетами, в другой обработка заданий, и то зная питоновскую многопоточность никаких гарантий. Скажем зависла обработка на дисковой операции, а клиент ждать коннекта не должен. Или я не прав?

А поверх чего dbus работает?

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

> зная питоновскую многопоточность никаких гарантий

На I/O питоновская многонитевость работает вполне нормально.

Скажем зависла обработка на дисковой операции, а клиент ждать коннекта не должен

У тебя много данных или жесткие требования по времени реакции?

А поверх чего dbus работает?

Unix сокет.

P.S. я бы вообще постарался не делать демона.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

А поверх чего dbus работает?

Unix сокет.

Те же яйца выходит...

Я б тоже не хотел делать демона, но тода придется мутить блокировки на файлы с результатом (а то получится что в один файл пишет неск процессов), и получится еще хуже.

AIv ★★★★★
() автор топика
Ответ на: комментарий от gadfly

> dbus не советую

Вечером расскажешь почему?;-)

А длина хвоста необработанных сообщений как то ограничена?

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

> Сокет поднимать кажется толстоватым,

нек-е операции связаны с перетасовкой десятков тысяч файлов.

Ммм, один я вижу тут странное сочетание «толстого сокета» и «десятка тысяч файлов?

ky-san
()
Ответ на: комментарий от tailgunner

Наверное я таки Вас послушаюсь, тем более что в один поток оно как то не оч ложится. Получается так:

главный поток демона сидит на сокете, выдергивает из него задания и распихивает по очередям (банальным спискам) потоков, отвечающих отдельным файлам с результатами. Те в свою очередь достают очередное задание и в простом случае обрабатывает его сами, в сложном запускают шелловский скрипт через os.system что бы увернутся от GIL.

Вот в последнем пассаже я не уверен - скажем мне надо независимо перетасовать неск толстых пачек файлов. Если все делать честно через питоновские шреды, будет ли это хозяйство параллелится, или лучше заюзать отдельные процессы? Вроде как основные накладные расходы связаны с железом... и вообще не факт, что параллелится в этом случае хорошо.

AIv ★★★★★
() автор топика

Я бы, пожалуй, сделал фифо. Клиенты пишут, с локом. Демон читает. Достаточно надёжно. От порванного соединения никто не зависит.

baverman ★★★
()
Ответ на: комментарий от AIv

> Да, но тогда придется демона усложнять - как мин в один проток работа с сокетами, в другой обработка заданий, и то зная питоновскую многопоточность никаких гарантий

Многопоточность именно для этого тут не нужна - есть асинхронный ввод-вывод (см. twisted). Вообще, я бы такой функционал именно на twisted делал, но это, как говорится, дело ваше.

Да, пока я не забыл - pickle тоже не нужен.

shylent
()
Ответ на: комментарий от shylent

А для чего, простите, pickle по Вашему не нужен?;-)

Про фифо думал... не понравилось.

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

> А для чего, простите, pickle по Вашему не нужен

Для сериализации объектов. Для этого нужны сериализационные форматы, такие, как, например, json, ну, или, yaml. Или даже XML. Или BSON. Но не pickle.

Что может быть проще, чем написать методы to_json / from_json для класса, объекты которого вы хотите сериализовать и забыть про pickle, с его несовместимостями и несекьюрностью, как про страшный сон, а?

)


Вы - лиспер в отставке?

shylent
()
Ответ на: комментарий от AIv

>Да, но тогда придется демона усложнять - как мин в один проток работа с сокетами, в другой обработка заданий, и то зная питоновскую многопоточность никаких гарантий.

А multiprocessing?

anonymous
()
Ответ на: комментарий от shylent

А что Вы можете сказать про время сериализации, размер полученных данных, поддержку циклических структур, поддержку пользовательских особых случаев и вхождение в стандартные комплекты поставки для всего Вами перечисленного по сравнению с pickle?

Что может быть проще, чем написать методы to_json / from_json...

Проще - вообще ничего не писать. Я еще не разу не натыкался на несовместимость и несекьюрность пикла. Кроме того, у меня и у коллег ... много, очень много данных в пикле. Нужны очень веские аргументы для перехода на что то другое, какие то просто нереальные бонусы. Пикл пока со своими задачи справляется.

Вы - лиспер в отставке?

Нет, просто улыбаюсь часто. А Вы нет?

AIv ★★★★★
() автор топика
Ответ на: комментарий от gadfly

> Можно и TCP/UDP, но целый TCP/IP мне тут кажется лишним. ИМХО UNIX-сокет полегче будет.

O_O

Эта «легкость» будет более чем скомпенсирована тяжестью разработки, когда понадобятся сообщения длиннее 64КБайт.

tailgunner ★★★★★
()
Ответ на: комментарий от AIv

> Те в свою очередь достают очередное задание и в простом случае обрабатывает его сами, в сложном запускают шелловский скрипт через os.system что бы увернутся от GIL.

У вас волчанка^WGILчанка.

I/O нормально параллелится - перед его началом GIL отдается.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Нет, скорее васкулит;-)

Я этот вопрос детально не копал, потому и справшиваю. Ок, спасибо.

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

Модуль json идет в стандартной поставке python. Время сериализации - ну, замерьте и скажите мне, заодно и посмотрим.

Что вы будете делать, интересно, если у вас какие-то данные из тех, которых «много, очень много» не распиклятся вдруг? Рвать волосы на голове? Я, лично, за явную сериализацию, т.е. для класса, объекты которого предполагается сериализовать, пишется serializer/deserializer (в большинстве случаев это - более, чем тривиально) - это дает хотя бы какую-то гарантию совместимости с собственным кодом.

Впрочем тут и выше по треду (про сериализацию, а не про async i/o!) - сугубо мое ИМХО. В конце концов, именно вам потом эти данные восстанавливать.

Но, да, «много, очень много» данных в pickle - это смело, очень смело. Безумству храбрых поем мы славу, как говорится.

Вы - лиспер в отставке?

Нет, просто улыбаюсь часто. А Вы нет?


Улыбаюсь достаточно, да, но не использую смайлики, как индульгенцию, позволяющую мне говорить потенциально неверные вещи.

shylent
()
Ответ на: комментарий от shylent

> Модуль json идет в стандартной поставке python. Время сериализации - ну, замерьте и скажите мне, заодно и посмотрим.

Как то не с руки... думал Вы этот вопрос изучали, судя по категоричности заявляения о нужности/ненужности.

Что вы будете делать, интересно, если у вас какие-то данные из тех, которых «много, очень много» не распиклятся вдруг?

За 10 лет такого не было.

Я, лично, за явную сериализацию, т.е. для класса, объекты которого предполагается сериализовать, пишется serializer/deserializer (в большинстве случаев это - более, чем тривиально) - это дает хотя бы какую-то гарантию совместимости с собственным кодом.

Да-да... потом Вы меняете свой код, и все что было сохранено раньше можно выкидывать. Или в коде написанном ранее высплывает ошибка, и выясняется что все что сохранялось сохранялось криво. Спасибо, это прооходили много раз.

Улыбаюсь достаточно, да, но не использую смайлики, как индульгенцию, позволяющую мне говорить потенциально неверные вещи.

Тот смайлик относился к вопросительному предлождению, не содержащему никаких утверждений, и должен был показать мое настроениею. Вы считаете, что в вопросах смайлики тоже недопустимы?

AIv ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Эта «легкость» будет более чем скомпенсирована тяжестью разработки, когда понадобятся сообщения длиннее 64КБайт.

А какие проблемы с порогом 64 кБ в UNIX-сокете?

pathfinder ★★★★
()
Ответ на: комментарий от tailgunner

в данном случае у ТС явно поставлена задача - пнуть демона сигналом DATA READY. надо только передать путь к файлу. напишите мне пожалуйста путь к файлу длиннее 64к, а также систему, которая способна с таким путем оперировать

marvin_yorke ★★★
()
Ответ на: комментарий от pathfinder

> А какие проблемы с порогом 64 кБ в UNIX-сокете?

Речь шла о UDP-сокете. Если же ты хочешь спросить «какие проблемы с Unix-сокетом», сначала ответь, какие у него преимущества перед TCP.

tailgunner ★★★★★
()
Ответ на: комментарий от marvin_yorke

> в данном случае у ТС явно поставлена задача

Задачи меняются со временем.

напишите мне пожалуйста путь к файлу длиннее 64к

Представь себе, что вместо файла будет список файлов.

А теперь напиши мне, пожалуйста, список преимуществ Unix-сокета перед TCP-сокетом (с пруфами, если есть).

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

* UNIX-сокеты отображаются на VFS, что дает разграничение доступа
* IP локально все равно протаскивается через весь стэк, как по сети, со всем оверхэдом
* UNIX-сокет же осознает свою локальность, что приводит к уменьшению количества переключений контекста, процесс-отправитель пишет напрямую в буфер сокета
http://lists.freebsd.org/pipermail/freebsd-performance/2005-February/001143.html

gadfly ★★
()
Ответ на: комментарий от tailgunner

Речь шла о UDP-сокете.

Теперь ясно. Я просто неправильно понял. Думал, что проблема порога 64 кБ относится к Unix-сокету.

pathfinder ★★★★
()
Ответ на: комментарий от tailgunner

Если же ты хочешь спросить «какие проблемы с Unix-сокетом», сначала ответь, какие у него преимущества перед TCP.

Точно не знаю, но вроде как у локальных TCP-сокетов оверхед выше, чем у Unix-сокетов.

pathfinder ★★★★
()
Ответ на: комментарий от gadfly

> * UNIX-сокеты отображаются на VFS, что дает разграничение доступа

Это плюс, но надо ли это ТС?

* IP локально все равно протаскивается через весь стэк, как по сети, со всем оверхэдом

Оверхэд, что характерно, не посчитан. Hint: MTU интерфейса lo - около 16К.

http://lists.freebsd.org/pipermail/freebsd-performance/2005-February/001143.html

Информация 5-летней давности, относящаяся к другой ОС.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Информация 5-летней давности,

Я думаю, что там со времен UNIX SystemV мало что изменилось

относящаяся к другой ОС.

man 7 unix

gadfly ★★
()
Ответ на: комментарий от gadfly

>> Информация 5-летней давности,

Я думаю, что там со времен UNIX SystemV мало что изменилось

Ты ошибаешься. Это не говоря о том, что ни Linux, ни FreeBSD не являются SystemV.

относящаяся к другой ОС.

man 7 unix

man interface, man implementation

tailgunner ★★★★★
()
Ответ на: комментарий от gadfly

>> Ты ошибаешься.

Пруф?

Погугли об отличиях SVR 4.0 от SVR 4.2, и их обоих от SVR5. Сразу могу сказать - как минимум отличие в SMP и вытеснимости ядра.

И как насчет того, что обсуждаемые системы не являются производными от SystemV? Сетевой стек в System V - STREAMS, такого нет ни в BSD, ни в Linux. Сетевые стеки BSD и Linux тоже имеют мало общего (только интерфейс с пользователем - те самые сокеты).

tailgunner ★★★★★
()

Если делаь нужно именно на файлах, то классический «inbox», т.е. демон мониторит средствами ОС указанную директорию с помощью inotify в линуксе, или другими аналогами, на предмет изменений. Клиент пишет свой файл во временной директории и потом перемещает его в инбокс или кидает симлинк на файл.

mashina ★★★★★
()

В рамках одного хоста [..]
Сокет поднимать кажется толстоватым [..]

надо понимать что сокет в рамках одного хоста - всего лишь заглушка, так что ничего не толсто, кроме того потом Вы сможете разнести своё решение на разные машины и оно будет работать

shty ★★★★★
()

Зачем пинать демона? Пусть клиенты сваливают свои пиклы в папочку, а демон периодически просыпается, и чекает наличие новых файлов. Старые можно просто удалять, либо перемещать в другое место.

redixin ★★★★
()
Ответ на: комментарий от redixin

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

AIv ★★★★★
() автор топика
Ответ на: комментарий от redixin

Есть некоторое кол-во клиентов, асинхронно что то пишущих на диск. Если для каждой записи надо будет делать еще одну запись в папку демона, нагрузка возрастает грубо говоря вдвое.

AIv ★★★★★
() автор топика
Ответ на: комментарий от redixin

Это не папка а много папок, и демон как раз и создается что б не читать все пиклы;-)

AIv ★★★★★
() автор топика
Ответ на: комментарий от redixin

А почему когда Вы на стол накрываете, то раскладываете еду по тарелкам, и к каждой тарелке прибор и рюмку? Ставьте все тарелки стопкой, приборы по кучкам и рюмки в один ящик - няхай гости оливье руками из салатницы гребут и из горла хлебают, зато потом демону уборки и мытья ну как хорошо... ;-)

Демон - часть другой куда более сложной задачи, и играет он весьма скромную вспомогательную роль.

AIv ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.