Re: Процессная модель
On 01 Mar 2014, at 17:46, Михаил Монашёв postmas...@softsearch.ru wrote: Здравствуйте, Igor. Ввиду отсутствия fork()а на Windows, nginx/Windows запускает новые процессы. Вот там проблемы, так проблемы. Сигналы - это семечки. А есть желание эти проблемы преодолевать? Т.е. есть желание покорять венду с её вендо-админами? мне кажется, ROI достаточно низкий, да и ребята из Nginx не будут распыляться на все подряд -- С уважением, Михаил mailto:postmas...@softsearch.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Re[2]: Процессная модель
On Mar 1, 2014, at 21:46 , Михаил Монашёв wrote: Здравствуйте, Igor. Ввиду отсутствия fork()а на Windows, nginx/Windows запускает новые процессы. Вот там проблемы, так проблемы. Сигналы - это семечки. А есть желание эти проблемы преодолевать? Т.е. есть желание покорять венду с её вендо-админами? Конкретно эти проблемы - проблемы взаимодействия и передачи данных из мастера в воркеры - уже преодолены. Это к вопросу о том, что проще - делать fork() или fork()/exec() для родственных процессов. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Процессная модель
On Feb 27, 2014, at 22:22 , AlexyFrost wrote: Anton Yuzhaninov Wrote: --- On 02/26/14 03:17, AlexyFrost wrote: Мусора в том, что наследуется нет. listen socket нужен. других сокетов, открытых в мастере не должно быть. Обработчики сигналов AFAIK переопределяются, если нужно. Вот об этом я и говорил: с использованием fork() воркер попадает в сильную зависимость от того, что должно и не должно быть инициализировано в мастере, т.е., какие контр-действия придётся ему делать (закрытие чего то, отключение сигналов etc). Понятное дело, что для компилируемой программы этот аргумент не столь важен, но, тем не менее, для большого и сложного проекта, который пишет не один человек, такие сайд-эффекты вполне существенны, мне кажется. К тому же, если форки используются для разных типов воркеров (обработка соединений, какой то кеш, какие то сервисные штуки), то у них могут быть разные реакции на унаследованные от мастера данные - кому то надо сделать то, кому то это, и в случае внесения изменений в мастер (добавили новый сигнал?) придётся править код всех воркеров. То что worker-ы используют память мастера (через COW) очень даже полезно - большая геобаза загруженная мастером будет использоваться всеми процессами и не надо будет загружать её N раз в каждый worker отдельно. Для подобных данных можно использовать shared memory, что так же выглядит логичнее, чем копия данных мастера, да и в случе потребностей горячей замены таких данных сделать это будет проще в одном месте. Shared memory в неродственных процессах сочетании с ASRL превращается в ад. В адресное пространство воркеров попадает часть кода и данных, не нужных worker-ом, но ничего плохого в этом нет. Меня, в целом, не столько беспокоят левые данные мастера в воркере, сколько потенциальные проблемы, которые они могут привнести (выше перечислял). Ввиду отсутствия fork()а на Windows, nginx/Windows запускает новые процессы. Вот там проблемы, так проблемы. Сигналы - это семечки. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re[2]: Процессная модель
Здравствуйте, Igor. Ввиду отсутствия fork()а на Windows, nginx/Windows запускает новые процессы. Вот там проблемы, так проблемы. Сигналы - это семечки. А есть желание эти проблемы преодолевать? Т.е. есть желание покорять венду с её вендо-админами? -- С уважением, Михаил mailto:postmas...@softsearch.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Процессная модель
On 02/26/14 03:17, AlexyFrost wrote: Как известно, форк наследует кучу мусора из родительского процесса: обработчики сигналов, дескрипторы файлов\сокетов, переменные и т.п., словом, память стека и кучи. Мусора в том, что наследуется нет. listen socket нужен. других сокетов, открытых в мастере не должно быть. Обработчики сигналов AFAIK переопределяются, если нужно. То что worker-ы используют память мастера (через COW) очень даже полезно - большая геобаза загруженная мастером будет использоваться всеми процессами и не надо будет загружать её N раз в каждый worker отдельно. В адресное пространство воркеров попадает часть кода и данных, не нужных worker-ом, но ничего плохого в этом нет. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Процессная модель
Anton Yuzhaninov Wrote: --- On 02/26/14 03:17, AlexyFrost wrote: Мусора в том, что наследуется нет. listen socket нужен. других сокетов, открытых в мастере не должно быть. Обработчики сигналов AFAIK переопределяются, если нужно. Вот об этом я и говорил: с использованием fork() воркер попадает в сильную зависимость от того, что должно и не должно быть инициализировано в мастере, т.е., какие контр-действия придётся ему делать (закрытие чего то, отключение сигналов etc). Понятное дело, что для компилируемой программы этот аргумент не столь важен, но, тем не менее, для большого и сложного проекта, который пишет не один человек, такие сайд-эффекты вполне существенны, мне кажется. К тому же, если форки используются для разных типов воркеров (обработка соединений, какой то кеш, какие то сервисные штуки), то у них могут быть разные реакции на унаследованные от мастера данные - кому то надо сделать то, кому то это, и в случае внесения изменений в мастер (добавили новый сигнал?) придётся править код всех воркеров. То что worker-ы используют память мастера (через COW) очень даже полезно - большая геобаза загруженная мастером будет использоваться всеми процессами и не надо будет загружать её N раз в каждый worker отдельно. Для подобных данных можно использовать shared memory, что так же выглядит логичнее, чем копия данных мастера, да и в случе потребностей горячей замены таких данных сделать это будет проще в одном месте. В адресное пространство воркеров попадает часть кода и данных, не нужных worker-ом, но ничего плохого в этом нет. Меня, в целом, не столько беспокоят левые данные мастера в воркере, сколько потенциальные проблемы, которые они могут привнести (выше перечислял). Posted at Nginx Forum: http://forum.nginx.org/read.php?21,247942,247994#msg-247994 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Процессная модель
On Thursday 27 February 2014 13:22:39 AlexyFrost wrote: [..] Меня, в целом, не столько беспокоят левые данные мастера в воркере, сколько потенциальные проблемы, которые они могут привнести (выше перечислял). ИМХО все перечисленные проблемы надуманны. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Процессная модель
Привет. Предлагаю подискутировать о процессной модели nginx. Раскуривал недавно исходники, хотелось прояснить пару философских моментов, которые мучают меня уже не первый год, и вот натолкнулся на эти моменты со spawn`ом воркеров. Как известно, форк наследует кучу мусора из родительского процесса: обработчики сигналов, дескрипторы файлов\сокетов, переменные и т.п., словом, память стека и кучи. Так вот, как же избежать этого: почистить от родительской памяти форкнутый процесс нельзя, а юзать exec*() для запуска стороннего бинарника-воркера, который бы полностью заместил собой память форка - это значит делать второй, отдельный бинарник, что не так элегантно, как решение с одним исполняемым файлом nginx`а + fork(). Основной вопрос в том, что метод с fork() имеет сильную зависимость от родительского процесса. Например, если сначала добавить какие-нибудь обработчики сигналов в родителе, а потом форкнуть, nо дочерний процесс их унаследует, следовательно, форк подвержен значительным сайд-эффектам, и зависим даже от порядка кода в родительского процесса. Можно, конечно, условиться о порядке запуска, и о том, что делать ататат с копией чужой памяти нельзя, но это всё как то грустно выглядит, и вообще, нарушает принцип инкапсуляции. Короче, хотелось бы услышать мнения о том, как же правильно организовывать многопроцессное приложение: fork() или fork() + exec() (ну или system()), преимущества и недостатки тех или иных подходов, и почему в nginx используется именно fork(), а не что то другое из вышеописанного. Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,247942,247942#msg-247942 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
