From hell-for-yahoo at umail.ru Fri Mar 1 00:21:28 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Fri, 1 Mar 2013 04:21:28 +0400 Subject: counters In-Reply-To: <7d125e94bc1760640286f01cd7568184.NginxMailingListRussian@forum.nginx.org> References: <22349431.20130301003915@mtu-net.ru> <7d125e94bc1760640286f01cd7568184.NginxMailingListRussian@forum.nginx.org> Message-ID: <1444990097.20130301042128@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) theromis1! t> Модуль позволяет использовать именованные счетчики с механизмом управления t> ими. Спасибо, мне это сказало примерно столько же, сколько подсказка "Enable RPAF module" к чекбоксу, поименованному "Enable RPAF module". Для вас большая проблема излагать свои мысли связно и осмысленно? -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) пятница, 01.03.2013, <04:19> From postmaster at softsearch.ru Fri Mar 1 06:22:26 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 1 Mar 2013 10:22:26 +0400 Subject: counters In-Reply-To: <0546ceaa830e5c4525d8ca8035c6267e.NginxMailingListRussian@forum.nginx.org> References: <139986087.20130228233117@softsearch.ru> <0546ceaa830e5c4525d8ca8035c6267e.NginxMailingListRussian@forum.nginx.org> Message-ID: <384377327.20130301102226@softsearch.ru> Здравствуйте, theromis1. Вы писали 1 марта 2013 г., 1:23:43: > пример я обновил > location ~* /stats/get_counter/(?P.*)$ { > counter_get host_counter $counter $id; > return 200 $counter; > } > location ~* /stats/counter_get/(?P.*)$ { > counter_get host_counter $counter $id; > return 200 $counter; > } > location ~* /stats/counter_drop/(?P.*)$ { > counter_drop host_counter $id; > } А что counter_get и counter_drop делают? -- С уважением, Михаил mailto:postmaster at softsearch.ru From vbart at nginx.com Fri Mar 1 09:36:51 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 1 Mar 2013 13:36:51 +0400 Subject: IPv6 forward proxy In-Reply-To: References: <20130228094509.GA60167@lo0.su> Message-ID: <201303011336.51225.vbart@nginx.com> On Thursday 28 February 2013 13:52:23 Alexander Moskalenko wrote: > А обойти как-то можно? > Можно использовать системный резолвер, но хост в этом случае должен быть задан статически, а не переменной. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html > 2013/2/28 Ruslan Ermilov : > > On Thu, Feb 28, 2013 at 11:33:07AM +0200, Alexander Moskalenko wrote: > >> Пытаюсь сделать forward proxy для IPv4 & IPv6. > >> > >> Для 4 все работает отлично, для 6 пытается ходить по 4. > >> Если указать хост у которого только 6 адрес - не резолвит. > >> > >> В логе следующее: > >> 2013/02/28 12:24:09 [debug] 5397#0: resolver qs:ipv6.l.google.com > >> 2013/02/28 12:24:09 [error] 5397#0: *15 ipv6.l.google.com could not be > >> resolved (3: Host not found), client: 2607:f878:3:314::42b3:e975, > >> server: , request: "GET http://ipv6.google.com/ HTTP/1.0", host: > >> "ipv6.google.com" > >> > >> 2013/02/28 12:23:09 [debug] 5397#0: resolve: "www.google.com" > >> 2013/02/28 12:23:09 [debug] 5397#0: resolve cached > >> 2013/02/28 12:23:09 [debug] 5397#0: malloc: 08D883E8:20 > >> 2013/02/28 12:23:09 [debug] 5397#0: *13 name was resolved to > >> 74.125.239.17 2013/02/28 12:23:09 [debug] 5397#0: *13 name was resolved > >> to 74.125.239.16 2013/02/28 12:23:09 [debug] 5397#0: *13 name was > >> resolved to 74.125.239.18 2013/02/28 12:23:09 [debug] 5397#0: *13 name > >> was resolved to 74.125.239.19 2013/02/28 12:23:09 [debug] 5397#0: *13 > >> name was resolved to 74.125.239.20 2013/02/28 12:23:09 [debug] 5397#0: > >> resolve name done: 0 > >> 2013/02/28 12:23:09 [debug] 5397#0: resolver expire > >> 2013/02/28 12:23:09 [debug] 5397#0: *13 get rr peer, try: 5 > >> 2013/02/28 12:23:09 [debug] 5397#0: *13 get rr peer, current: 0 -4 > >> 2013/02/28 12:23:09 [debug] 5397#0: *13 socket 11 > >> 2013/02/28 12:23:09 [debug] 5397#0: *13 epoll add connection: fd:11 > >> ev:80000005 2013/02/28 12:23:09 [debug] 5397#0: *13 connect to > >> 74.125.239.17:80, fd:11 #14 2013/02/28 12:23:09 [debug] 5397#0: *13 > >> http upstream connect: -2 > >> > >> В обоих случаях коннект идет на сервер: > >> > >> server { > >> > >> listen [::]:8080 ipv6only=on default bind; > >> resolver [2001:4860:4860::8888]; > >> > >> location / { > >> > >> proxy_pass $scheme://$http_host$uri$is_args$args; > >> proxy_bind $server_addr; > >> > >> } > >> > >> } > >> > >> > >> Это баг или фича? > > > > В настоящий момент резолвер в nginx не умеет резолвить IPv6-адреса. > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From rush.zlo at gmail.com Fri Mar 1 09:46:48 2013 From: rush.zlo at gmail.com (=?UTF-8?B?0JXQstCz0LXQvdC40LkgJ1J1c2gnINCd0LXQv9C+0LzQvdGP0YnQuNC5?=) Date: Fri, 1 Mar 2013 13:46:48 +0400 Subject: counters In-Reply-To: <384377327.20130301102226@softsearch.ru> References: <139986087.20130228233117@softsearch.ru> <0546ceaa830e5c4525d8ca8035c6267e.NginxMailingListRussian@forum.nginx.org> <384377327.20130301102226@softsearch.ru> Message-ID: 1 марта 2013 г., 10:22 пользователь Михаил Монашёв написал: > А что counter_get и counter_drop делают? Судя по конфигу counter_get засовывает в указанную переменную значение указанного по $id счётчика, counter_drop таким же образом счётчик обнуляет. -- Cogito ergo sum From alexander.moskalenko at gmail.com Fri Mar 1 10:11:59 2013 From: alexander.moskalenko at gmail.com (Alexander Moskalenko) Date: Fri, 1 Mar 2013 12:11:59 +0200 Subject: IPv6 forward proxy In-Reply-To: <201303011336.51225.vbart@nginx.com> References: <20130228094509.GA60167@lo0.su> <201303011336.51225.vbart@nginx.com> Message-ID: Если хост задавать статически то особо смысла нет в резолвинге, можно просто на IP проксировать. У меня получилась отлично работающая схема из Nginx+Tinyproxy, к тому же мне нужно еще переброс client->IPv4->IPv6->destination делать. 2013/3/1 Валентин Бартенев : > On Thursday 28 February 2013 13:52:23 Alexander Moskalenko wrote: >> А обойти как-то можно? >> > > Можно использовать системный резолвер, но хост в этом случае должен быть задан > статически, а не переменной. > > -- > Валентин Бартенев > http://nginx.com/support.html > http://nginx.org/en/donation.html > > >> 2013/2/28 Ruslan Ermilov : >> > On Thu, Feb 28, 2013 at 11:33:07AM +0200, Alexander Moskalenko wrote: >> >> Пытаюсь сделать forward proxy для IPv4 & IPv6. >> >> >> >> Для 4 все работает отлично, для 6 пытается ходить по 4. >> >> Если указать хост у которого только 6 адрес - не резолвит. >> >> >> >> В логе следующее: >> >> 2013/02/28 12:24:09 [debug] 5397#0: resolver qs:ipv6.l.google.com >> >> 2013/02/28 12:24:09 [error] 5397#0: *15 ipv6.l.google.com could not be >> >> resolved (3: Host not found), client: 2607:f878:3:314::42b3:e975, >> >> server: , request: "GET http://ipv6.google.com/ HTTP/1.0", host: >> >> "ipv6.google.com" >> >> >> >> 2013/02/28 12:23:09 [debug] 5397#0: resolve: "www.google.com" >> >> 2013/02/28 12:23:09 [debug] 5397#0: resolve cached >> >> 2013/02/28 12:23:09 [debug] 5397#0: malloc: 08D883E8:20 >> >> 2013/02/28 12:23:09 [debug] 5397#0: *13 name was resolved to >> >> 74.125.239.17 2013/02/28 12:23:09 [debug] 5397#0: *13 name was resolved >> >> to 74.125.239.16 2013/02/28 12:23:09 [debug] 5397#0: *13 name was >> >> resolved to 74.125.239.18 2013/02/28 12:23:09 [debug] 5397#0: *13 name >> >> was resolved to 74.125.239.19 2013/02/28 12:23:09 [debug] 5397#0: *13 >> >> name was resolved to 74.125.239.20 2013/02/28 12:23:09 [debug] 5397#0: >> >> resolve name done: 0 >> >> 2013/02/28 12:23:09 [debug] 5397#0: resolver expire >> >> 2013/02/28 12:23:09 [debug] 5397#0: *13 get rr peer, try: 5 >> >> 2013/02/28 12:23:09 [debug] 5397#0: *13 get rr peer, current: 0 -4 >> >> 2013/02/28 12:23:09 [debug] 5397#0: *13 socket 11 >> >> 2013/02/28 12:23:09 [debug] 5397#0: *13 epoll add connection: fd:11 >> >> ev:80000005 2013/02/28 12:23:09 [debug] 5397#0: *13 connect to >> >> 74.125.239.17:80, fd:11 #14 2013/02/28 12:23:09 [debug] 5397#0: *13 >> >> http upstream connect: -2 >> >> >> >> В обоих случаях коннект идет на сервер: >> >> >> >> server { >> >> >> >> listen [::]:8080 ipv6only=on default bind; >> >> resolver [2001:4860:4860::8888]; >> >> >> >> location / { >> >> >> >> proxy_pass $scheme://$http_host$uri$is_args$args; >> >> proxy_bind $server_addr; >> >> >> >> } >> >> >> >> } >> >> >> >> >> >> Это баг или фича? >> > >> > В настоящий момент резолвер в nginx не умеет резолвить IPv6-адреса. >> > >> > _______________________________________________ >> > nginx-ru mailing list >> > nginx-ru at nginx.org >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Fri Mar 1 10:45:00 2013 From: nginx-forum at nginx.us (ShivaS) Date: Fri, 01 Mar 2013 05:45:00 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQutCwINC/0LXRgNC10LrRgNGL0YLRjCDQtNC+0YHRgtGD0L8g0Log?= =?UTF-8?B?0LvRjtCx0YvQvCDRhNCw0LnQu9Cw0Lwg0Lgg0LTQuNGA0LXQutGC0L7RgNC4?= =?UTF-8?B?0Y/QvCAoINGE0YDQtdC50LzQstC+0YDQuikg0L3QsCDQtNC40YHQutC1Pw==?= In-Reply-To: References: Message-ID: если реферер пустой, тогда блокировать запрос Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236729,236767#msg-236767 From nginx-forum at nginx.us Fri Mar 1 10:56:13 2013 From: nginx-forum at nginx.us (ShivaS) Date: Fri, 01 Mar 2013 05:56:13 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQutCwINC/0LXRgNC10LrRgNGL0YLRjCDQtNC+0YHRgtGD0L8g0Log?= =?UTF-8?B?0LvRjtCx0YvQvCDRhNCw0LnQu9Cw0Lwg0Lgg0LTQuNGA0LXQutGC0L7RgNC4?= =?UTF-8?B?0Y/QvCAoINGE0YDQtdC50LzQstC+0YDQuikg0L3QsCDQtNC40YHQutC1Pw==?= In-Reply-To: <1976362964.20130301003817@mtu-net.ru> References: <1976362964.20130301003817@mtu-net.ru> Message-ID: да, уже вынесли все наружу и оставили только index.php Андрей, а зачем redirect? Это вроде rewrite, который я не хочу использовать. try_files имхо отлично делает всю работу, да и везде в нете про него написано, когда речь о фреймворках. я прекрасно понимаю RTFM правило и не обратился бы сюда, если бы не зашел в некий тупик. Не могли бы Вы пожалуйста указать мне то место в документации, которое бы мне помогло понять как можно определять наличие файла на диске без if и request_filename? Буду очень признателен! Я реально в тупике... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236729,236768#msg-236768 From vbart at nginx.com Fri Mar 1 11:42:19 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 1 Mar 2013 15:42:19 +0400 Subject: =?UTF-8?B?UmU6ICDQmtCw0LrQsCDQv9C10YDQtdC60YDRi9GC0Ywg0LTQvtGB0YLRg9C/INC6?= =?UTF-8?B?INC70Y7QsdGL0Lwg0YTQsNC50LvQsNC8INC4INC00LjRgNC10LrRgtC+0YA=?= =?UTF-8?B?0LjRj9C8ICgg0YTRgNC10LnQvNCy0L7RgNC6KSAg0L3QsCDQtNC40YHQutC1?= =?UTF-8?B?Pw==?= In-Reply-To: References: <1976362964.20130301003817@mtu-net.ru> Message-ID: <201303011542.19670.vbart@nginx.com> On Friday 01 March 2013 14:56:13 ShivaS wrote: > да, уже вынесли все наружу и оставили только index.php > Зачем index.php оставили? > Андрей, а зачем redirect? Это вроде rewrite, который я не хочу > использовать. > try_files имхо отлично делает всю работу, да и везде в нете про него > написано, когда речь о фреймворках. > > я прекрасно понимаю RTFM правило и не обратился бы сюда, если бы не зашел > в некий тупик. > Не могли бы Вы пожалуйста указать мне то место в документации, которое бы > мне помогло понять как можно определять наличие файла на диске без if и > request_filename? Буду очень признателен! Я реально в тупике... > Положить всю статику в отдельную директорию. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From vbart at nginx.com Fri Mar 1 11:49:55 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 1 Mar 2013 15:49:55 +0400 Subject: IPv6 forward proxy In-Reply-To: References: <201303011336.51225.vbart@nginx.com> Message-ID: <201303011549.55268.vbart@nginx.com> On Friday 01 March 2013 14:11:59 Alexander Moskalenko wrote: > Если хост задавать статически то особо смысла нет в резолвинге, можно > просто на IP проксировать. > Смысл на самом деле есть. В отличии от одного прописанного ip, домен может резолвиться в несколько адресов, и в этом случае nginx будет балансировать между ними, а релоад конфигурации будет приводить к обновлению этого списка. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html > У меня получилась отлично работающая схема из Nginx+Tinyproxy, к тому > же мне нужно еще переброс client->IPv4->IPv6->destination делать. > > 2013/3/1 Валентин Бартенев : > > On Thursday 28 February 2013 13:52:23 Alexander Moskalenko wrote: > >> А обойти как-то можно? > > > > Можно использовать системный резолвер, но хост в этом случае должен быть > > задан статически, а не переменной. > > > > -- > > Валентин Бартенев > > http://nginx.com/support.html > > http://nginx.org/en/donation.html > > > >> 2013/2/28 Ruslan Ermilov : > >> > On Thu, Feb 28, 2013 at 11:33:07AM +0200, Alexander Moskalenko wrote: > >> >> Пытаюсь сделать forward proxy для IPv4 & IPv6. > >> >> > >> >> Для 4 все работает отлично, для 6 пытается ходить по 4. > >> >> Если указать хост у которого только 6 адрес - не резолвит. > >> >> > >> >> В логе следующее: > >> >> 2013/02/28 12:24:09 [debug] 5397#0: resolver qs:ipv6.l.google.com > >> >> 2013/02/28 12:24:09 [error] 5397#0: *15 ipv6.l.google.com could not > >> >> be resolved (3: Host not found), client: 2607:f878:3:314::42b3:e975, > >> >> server: , request: "GET http://ipv6.google.com/ HTTP/1.0", host: > >> >> "ipv6.google.com" > >> >> > >> >> 2013/02/28 12:23:09 [debug] 5397#0: resolve: "www.google.com" > >> >> 2013/02/28 12:23:09 [debug] 5397#0: resolve cached > >> >> 2013/02/28 12:23:09 [debug] 5397#0: malloc: 08D883E8:20 > >> >> 2013/02/28 12:23:09 [debug] 5397#0: *13 name was resolved to > >> >> 74.125.239.17 2013/02/28 12:23:09 [debug] 5397#0: *13 name was > >> >> resolved to 74.125.239.16 2013/02/28 12:23:09 [debug] 5397#0: *13 > >> >> name was resolved to 74.125.239.18 2013/02/28 12:23:09 [debug] > >> >> 5397#0: *13 name was resolved to 74.125.239.19 2013/02/28 12:23:09 > >> >> [debug] 5397#0: *13 name was resolved to 74.125.239.20 2013/02/28 > >> >> 12:23:09 [debug] 5397#0: resolve name done: 0 > >> >> 2013/02/28 12:23:09 [debug] 5397#0: resolver expire > >> >> 2013/02/28 12:23:09 [debug] 5397#0: *13 get rr peer, try: 5 > >> >> 2013/02/28 12:23:09 [debug] 5397#0: *13 get rr peer, current: 0 -4 > >> >> 2013/02/28 12:23:09 [debug] 5397#0: *13 socket 11 > >> >> 2013/02/28 12:23:09 [debug] 5397#0: *13 epoll add connection: fd:11 > >> >> ev:80000005 2013/02/28 12:23:09 [debug] 5397#0: *13 connect to > >> >> 74.125.239.17:80, fd:11 #14 2013/02/28 12:23:09 [debug] 5397#0: *13 > >> >> http upstream connect: -2 > >> >> > >> >> В обоих случаях коннект идет на сервер: > >> >> > >> >> server { > >> >> > >> >> listen [::]:8080 ipv6only=on default bind; > >> >> resolver [2001:4860:4860::8888]; > >> >> > >> >> location / { > >> >> > >> >> proxy_pass $scheme://$http_host$uri$is_args$args; > >> >> proxy_bind $server_addr; > >> >> > >> >> } > >> >> > >> >> } > >> >> > >> >> > >> >> Это баг или фича? > >> > > >> > В настоящий момент резолвер в nginx не умеет резолвить IPv6-адреса. > >> > > >> > _______________________________________________ > >> > nginx-ru mailing list > >> > nginx-ru at nginx.org > >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru > >> > >> _______________________________________________ > >> nginx-ru mailing list > >> nginx-ru at nginx.org > >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From panfilov at sports.ru Fri Mar 1 11:56:13 2013 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Fri, 1 Mar 2013 15:56:13 +0400 Subject: IPv6 forward proxy In-Reply-To: <201303011549.55268.vbart@nginx.com> References: <201303011336.51225.vbart@nginx.com> <201303011549.55268.vbart@nginx.com> Message-ID: Балансировку можно прописать в upstream секции. 1 марта 2013 г., 15:49 пользователь Валентин Бартенев написал: > On Friday 01 March 2013 14:11:59 Alexander Moskalenko wrote: > > Если хост задавать статически то особо смысла нет в резолвинге, можно > > просто на IP проксировать. > > > > Смысл на самом деле есть. В отличии от одного прописанного ip, домен может > резолвиться в несколько адресов, и в этом случае nginx будет балансировать > между ними, а релоад конфигурации будет приводить к обновлению этого > списка. > > -- > Валентин Бартенев > http://nginx.com/support.html > http://nginx.org/en/donation.html > > > У меня получилась отлично работающая схема из Nginx+Tinyproxy, к тому > > же мне нужно еще переброс client->IPv4->IPv6->destination делать. > > > > 2013/3/1 Валентин Бартенев : > > > On Thursday 28 February 2013 13:52:23 Alexander Moskalenko wrote: > > >> А обойти как-то можно? > > > > > > Можно использовать системный резолвер, но хост в этом случае должен > быть > > > задан статически, а не переменной. > > > > > > -- > > > Валентин Бартенев > > > http://nginx.com/support.html > > > http://nginx.org/en/donation.html > > > > > >> 2013/2/28 Ruslan Ermilov : > > >> > On Thu, Feb 28, 2013 at 11:33:07AM +0200, Alexander Moskalenko > wrote: > > >> >> Пытаюсь сделать forward proxy для IPv4 & IPv6. > > >> >> > > >> >> Для 4 все работает отлично, для 6 пытается ходить по 4. > > >> >> Если указать хост у которого только 6 адрес - не резолвит. > > >> >> > > >> >> В логе следующее: > > >> >> 2013/02/28 12:24:09 [debug] 5397#0: resolver qs:ipv6.l.google.com > > >> >> 2013/02/28 12:24:09 [error] 5397#0: *15 ipv6.l.google.com could > not > > >> >> be resolved (3: Host not found), client: > 2607:f878:3:314::42b3:e975, > > >> >> server: , request: "GET http://ipv6.google.com/ HTTP/1.0", host: > > >> >> "ipv6.google.com" > > >> >> > > >> >> 2013/02/28 12:23:09 [debug] 5397#0: resolve: "www.google.com" > > >> >> 2013/02/28 12:23:09 [debug] 5397#0: resolve cached > > >> >> 2013/02/28 12:23:09 [debug] 5397#0: malloc: 08D883E8:20 > > >> >> 2013/02/28 12:23:09 [debug] 5397#0: *13 name was resolved to > > >> >> 74.125.239.17 2013/02/28 12:23:09 [debug] 5397#0: *13 name was > > >> >> resolved to 74.125.239.16 2013/02/28 12:23:09 [debug] 5397#0: *13 > > >> >> name was resolved to 74.125.239.18 2013/02/28 12:23:09 [debug] > > >> >> 5397#0: *13 name was resolved to 74.125.239.19 2013/02/28 12:23:09 > > >> >> [debug] 5397#0: *13 name was resolved to 74.125.239.20 2013/02/28 > > >> >> 12:23:09 [debug] 5397#0: resolve name done: 0 > > >> >> 2013/02/28 12:23:09 [debug] 5397#0: resolver expire > > >> >> 2013/02/28 12:23:09 [debug] 5397#0: *13 get rr peer, try: 5 > > >> >> 2013/02/28 12:23:09 [debug] 5397#0: *13 get rr peer, current: 0 -4 > > >> >> 2013/02/28 12:23:09 [debug] 5397#0: *13 socket 11 > > >> >> 2013/02/28 12:23:09 [debug] 5397#0: *13 epoll add connection: fd:11 > > >> >> ev:80000005 2013/02/28 12:23:09 [debug] 5397#0: *13 connect to > > >> >> 74.125.239.17:80, fd:11 #14 2013/02/28 12:23:09 [debug] 5397#0: > *13 > > >> >> http upstream connect: -2 > > >> >> > > >> >> В обоих случаях коннект идет на сервер: > > >> >> > > >> >> server { > > >> >> > > >> >> listen [::]:8080 ipv6only=on default bind; > > >> >> resolver [2001:4860:4860::8888]; > > >> >> > > >> >> location / { > > >> >> > > >> >> proxy_pass $scheme://$http_host$uri$is_args$args; > > >> >> proxy_bind $server_addr; > > >> >> > > >> >> } > > >> >> > > >> >> } > > >> >> > > >> >> > > >> >> Это баг или фича? > > >> > > > >> > В настоящий момент резолвер в nginx не умеет резолвить IPv6-адреса. > > >> > > > >> > _______________________________________________ > > >> > nginx-ru mailing list > > >> > nginx-ru at nginx.org > > >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > >> > > >> _______________________________________________ > > >> nginx-ru mailing list > > >> nginx-ru at nginx.org > > >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Панфилов Михаил -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri Mar 1 12:30:09 2013 From: nginx-forum at nginx.us (ShivaS) Date: Fri, 01 Mar 2013 07:30:09 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQutCwINC/0LXRgNC10LrRgNGL0YLRjCDQtNC+0YHRgtGD0L8g0Log?= =?UTF-8?B?0LvRjtCx0YvQvCDRhNCw0LnQu9Cw0Lwg0Lgg0LTQuNGA0LXQutGC0L7RgNC4?= =?UTF-8?B?0Y/QvCAoINGE0YDQtdC50LzQstC+0YDQuikg0L3QsCDQtNC40YHQutC1Pw==?= In-Reply-To: <201303011542.19670.vbart@nginx.com> References: <201303011542.19670.vbart@nginx.com> Message-ID: <2ede8f806fb7e61c037b54603c51939e.NginxMailingListRussian@forum.nginx.org> Да, в принципе его не стоит оставлять. Статику в отдельную директорию конечно самое логичное, но меня подключили к проекту после того как все написано было. Сейчас что-либо менять будет достаточно сложно, но я скажу проггерам. Если рассматривать идеальный вариант, может ли данный конфиг сойти за таковой? Ну или считать близким ;-) #тут поставил пустую директорию, или надо вообще не указывать root ? root /var/www/directory1; index index.php; #возможно index тоже необязателен. поставил для галочки. location / { try_files "" /index.php; } location = /index.php { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME /var/www/framework/index.php; include fastcgi_params; } # статика общая для нескольких проектов под одним фреймворком, поэтому вынесена в другую директорию location ~ /(js|css|img)/ { root /var/www/directory2; access_log off; } Спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236729,236774#msg-236774 From vbart at nginx.com Fri Mar 1 12:37:54 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 1 Mar 2013 16:37:54 +0400 Subject: =?UTF-8?B?UmU6ICDQmtCw0LrQsCDQv9C10YDQtdC60YDRi9GC0Ywg0LTQvtGB0YLRg9C/INC6?= =?UTF-8?B?INC70Y7QsdGL0Lwg0YTQsNC50LvQsNC8INC4INC00LjRgNC10LrRgtC+0YA=?= =?UTF-8?B?0LjRj9C8ICgg0YTRgNC10LnQvNCy0L7RgNC6KSAg0L3QsCDQtNC40YHQutC1?= =?UTF-8?B?Pw==?= In-Reply-To: <2ede8f806fb7e61c037b54603c51939e.NginxMailingListRussian@forum.nginx.org> References: <201303011542.19670.vbart@nginx.com> <2ede8f806fb7e61c037b54603c51939e.NginxMailingListRussian@forum.nginx.org> Message-ID: <201303011637.54568.vbart@nginx.com> On Friday 01 March 2013 16:30:09 ShivaS wrote: > Да, в принципе его не стоит оставлять. > Статику в отдельную директорию конечно самое логичное, но меня подключили к > проекту после того как все написано было. > Сейчас что-либо менять будет достаточно сложно, но я скажу проггерам. > > Если рассматривать идеальный вариант, может ли данный конфиг сойти за > таковой? Ну или считать близким ;-) > Нет. См. ниже. > #тут поставил пустую директорию, или надо вообще не указывать root ? > root /var/www/directory1; > index index.php; #возможно index тоже необязателен. поставил для > галочки. > > location / { > try_files "" /index.php; > } > > > location = /index.php { > fastcgi_pass 127.0.0.1:9000; > fastcgi_param SCRIPT_FILENAME /var/www/framework/index.php; > include fastcgi_params; > } > Это какой-то "надмозг". Эти два блока заменяются одним, без лишнего вызова stat(): location / { fastcgi_pass 127.0.0.1:9000; include fastcgi_params; fastcgi_param SCRIPT_FILENAME /var/www/framework/index.php; } > # статика общая для нескольких проектов под одним фреймворком, поэтому > вынесена в другую директорию > location ~ /(js|css|img)/ { > root /var/www/directory2; > access_log off; > } > location /js/ { root /var/www/directory2; access_log off; } location /css/ { root /var/www/directory2; access_log off; } location /img/ { root /var/www/directory2; access_log off; } -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri Mar 1 12:50:38 2013 From: nginx-forum at nginx.us (ShivaS) Date: Fri, 01 Mar 2013 07:50:38 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQutCwINC/0LXRgNC10LrRgNGL0YLRjCDQtNC+0YHRgtGD0L8g0Log?= =?UTF-8?B?0LvRjtCx0YvQvCDRhNCw0LnQu9Cw0Lwg0Lgg0LTQuNGA0LXQutGC0L7RgNC4?= =?UTF-8?B?0Y/QvCAoINGE0YDQtdC50LzQstC+0YDQuikg0L3QsCDQtNC40YHQutC1Pw==?= In-Reply-To: <201303011637.54568.vbart@nginx.com> References: <201303011637.54568.vbart@nginx.com> Message-ID: Валентин, огромное спасибо! Понял "надмозг" и разделение статических фолдеров! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236729,236776#msg-236776 From nginx-forum at nginx.us Fri Mar 1 13:08:38 2013 From: nginx-forum at nginx.us (ShivaS) Date: Fri, 01 Mar 2013 08:08:38 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQutCwINC/0LXRgNC10LrRgNGL0YLRjCDQtNC+0YHRgtGD0L8g0Log?= =?UTF-8?B?0LvRjtCx0YvQvCDRhNCw0LnQu9Cw0Lwg0Lgg0LTQuNGA0LXQutGC0L7RgNC4?= =?UTF-8?B?0Y/QvCAoINGE0YDQtdC50LzQstC+0YDQuikg0L3QsCDQtNC40YHQutC1Pw==?= In-Reply-To: <201303011637.54568.vbart@nginx.com> References: <201303011637.54568.vbart@nginx.com> Message-ID: <96dc2ebe1be38f2252c00fbb980abc43.NginxMailingListRussian@forum.nginx.org> Валентин, в прошлой конфигурации с регексом на статику, эти фолдеры ловились раньше чем expiration, который следовал позже. Каюсь, что не указал его изначально, но сейчас пытаюсь понять как тогда правильно дать expiration location ~* \.(?:ico|css|js|gif|jpe?g|png)$ { expires 30d; add_header Pragma public; add_header Cache-Control "public"; } вот это теперь перехватывает все статические фолдеры. Единственный вариант - это отдельно под каждый фолдер выдать свой expiration? А если понадобится разделять expiration для разных файлов (например картинок) в одном и том же фолдере, тогда использовать вложенные location? Посоветуйте пожалуйста Спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236729,236779#msg-236779 From nginx-forum at nginx.us Fri Mar 1 13:12:07 2013 From: nginx-forum at nginx.us (gatesat) Date: Fri, 01 Mar 2013 08:12:07 -0500 Subject: =?UTF-8?B?UmU6IG1vZCB6aXAgLSDQvdC10LLQtdGA0L3Ri9C1INC00LDRgtGLINGE0LDQudC7?= =?UTF-8?B?0L7Qsi4=?= In-Reply-To: References: Message-ID: <672fe18e91bc0eabc133d02201825584.NginxMailingListRussian@forum.nginx.org> Нашел баг в реализации mod_zip-а. Исправил. Исправление и описание отправил разработчикам. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236712,236780#msg-236780 From vbart at nginx.com Fri Mar 1 14:09:30 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 1 Mar 2013 18:09:30 +0400 Subject: =?UTF-8?B?UmU6ICDQmtCw0LrQsCDQv9C10YDQtdC60YDRi9GC0Ywg0LTQvtGB0YLRg9C/INC6?= =?UTF-8?B?INC70Y7QsdGL0Lwg0YTQsNC50LvQsNC8INC4INC00LjRgNC10LrRgtC+0YA=?= =?UTF-8?B?0LjRj9C8ICgg0YTRgNC10LnQvNCy0L7RgNC6KSAg0L3QsCDQtNC40YHQutC1?= =?UTF-8?B?Pw==?= In-Reply-To: <96dc2ebe1be38f2252c00fbb980abc43.NginxMailingListRussian@forum.nginx.org> References: <201303011637.54568.vbart@nginx.com> <96dc2ebe1be38f2252c00fbb980abc43.NginxMailingListRussian@forum.nginx.org> Message-ID: <201303011809.30967.vbart@nginx.com> On Friday 01 March 2013 17:08:38 ShivaS wrote: > Валентин, в прошлой конфигурации с регексом на статику, эти фолдеры > ловились раньше чем expiration, который следовал позже. > Каюсь, что не указал его изначально, но сейчас пытаюсь понять как тогда > правильно дать expiration > > location ~* \.(?:ico|css|js|gif|jpe?g|png)$ { > expires 30d; > add_header Pragma public; > add_header Cache-Control "public"; > } > > вот это теперь перехватывает все статические фолдеры. > Единственный вариант - это отдельно под каждый фолдер выдать свой > expiration? Да. > А если понадобится разделять expiration для разных файлов (например > картинок) в одном и том же фолдере, тогда использовать вложенные location? > Да, всё верно. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From vbart at nginx.com Fri Mar 1 14:17:18 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 1 Mar 2013 18:17:18 +0400 Subject: =?UTF-8?B?UmU6ICDQmtCw0LrQsCDQv9C10YDQtdC60YDRi9GC0Ywg0LTQvtGB0YLRg9C/INC6?= =?UTF-8?B?INC70Y7QsdGL0Lwg0YTQsNC50LvQsNC8INC4INC00LjRgNC10LrRgtC+0YA=?= =?UTF-8?B?0LjRj9C8ICgg0YTRgNC10LnQvNCy0L7RgNC6KSAg0L3QsCDQtNC40YHQutC1?= =?UTF-8?B?Pw==?= In-Reply-To: <96dc2ebe1be38f2252c00fbb980abc43.NginxMailingListRussian@forum.nginx.org> References: <201303011637.54568.vbart@nginx.com> <96dc2ebe1be38f2252c00fbb980abc43.NginxMailingListRussian@forum.nginx.org> Message-ID: <201303011817.18476.vbart@nginx.com> On Friday 01 March 2013 17:08:38 ShivaS wrote: > Валентин, в прошлой конфигурации с регексом на статику, эти фолдеры > ловились раньше чем expiration, который следовал позже. > Каюсь, что не указал его изначально, но сейчас пытаюсь понять как тогда > правильно дать expiration > > location ~* \.(?:ico|css|js|gif|jpe?g|png)$ { > expires 30d; > add_header Pragma public; > add_header Cache-Control "public"; > } > > вот это теперь перехватывает все статические фолдеры. > Единственный вариант - это отдельно под каждый фолдер выдать свой > expiration? > А если понадобится разделять expiration для разных файлов (например > картинок) в одном и том же фолдере, тогда использовать вложенные location? > Но вообще, самый правильный подход, это ставить на всю статику большой expires, и включать в ссылки ревизию: http://example.com/madia/images/some.jpeg?42 где 42 последовательно увеличивают при каждом обновлении файла. Если эти файлы храняться в VCS, то можно брать ревизию из неё же при развертывании. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri Mar 1 14:44:37 2013 From: nginx-forum at nginx.us (anon) Date: Fri, 01 Mar 2013 09:44:37 -0500 Subject: =?UTF-8?B?0KHQvdC+0LLQsCDQviA0MDA=?= Message-ID: <033caf8572e0e4036d34513e67a45860.NginxMailingListRussian@forum.nginx.org> Всем привет. Стало очень много в логах ошибок типа IP - - [01/Mar/2013:14:37:29 +0000] "-" 400 - 0 "-" "-" upstream_response_time - msec 1362148649.996 request_time 5.343 -->- Доходит до 300-400 в секунду. Сервер довольно нагруженный, но все же. Выставил дебаг увидел следующее: 2013/03/01 14:36:19 [info] 21180#0: *676861779 client closed prematurely connection while SSL handshaking, client: 112.175.6.2, server: example.com Это только в логе для сервера с SSL. Также добавил в конфиг: server { listen *:80 default; server_name _ ""; return 444; } Количество 400-х не уменьшилось. Как можно отловить что генерирует эти реквесты, возможно это баг в нашем приложении(читал о слишком больших кукис). Сертификат проверял различными внешними чекерами, пишут проблем нет. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236787,236787#msg-236787 From andrey at kopeyko.ru Fri Mar 1 15:01:55 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Fri, 01 Mar 2013 19:01:55 +0400 Subject: =?UTF-8?B?UmU6INCh0L3QvtCy0LAg0L4gNDAw?= In-Reply-To: <033caf8572e0e4036d34513e67a45860.NginxMailingListRussian@forum.nginx.org> References: <033caf8572e0e4036d34513e67a45860.NginxMailingListRussian@forum.nginx.org> Message-ID: <5130C2E3.5030500@kopeyko.ru> 01.03.2013 18:44, anon пишет: > Всем привет. > > Стало очень много в логах ошибок типа > > IP - - [01/Mar/2013:14:37:29 +0000] "-" 400 - 0 "-" "-" > upstream_response_time - msec 1362148649.996 request_time 5.343 -->- > > Доходит до 300-400 в секунду. Сервер довольно нагруженный, но все же. > > Выставил дебаг увидел следующее: > > 2013/03/01 14:36:19 [info] 21180#0: *676861779 client closed prematurely > connection while SSL handshaking, client: 112.175.6.2, server: example.com > > Это только в логе для сервера с SSL. Также добавил в конфиг: > > server { > listen *:80 default; > server_name _ ""; > return 444; > } > > Количество 400-х не уменьшилось. > > Как можно отловить что генерирует эти реквесты, возможно это баг в нашем > приложении(читал о слишком больших кукис). Вероятнее всего, это Хром. За ним замечено такое поведение - он открывает порядка 30 соединений к сайту, но пользуется только малой частью, остальные держит "про запас". Они-то при закрытии и дают такую картину. Добавьте в лог "$http_user_agent" - если я прав, вы увидите запросы от Хрома, в это же время, с этого же IP. -- Best regards, Andrey Kopeyko From hell-for-yahoo at umail.ru Fri Mar 1 15:04:49 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Fri, 1 Mar 2013 19:04:49 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQutCwINC/0LXRgNC10LrRgNGL0YLRjCDQtNC+0YHRgtGD0L8g0Log?= =?UTF-8?B?0LvRjtCx0YvQvCDRhNCw0LnQu9Cw0Lwg0Lgg0LTQuNGA0LXQutGC0L7RgNC4?= =?UTF-8?B?0Y/QvCAoINGE0YDQtdC50LzQstC+0YDQuikg0L3QsCDQtNC40YHQutC1Pw==?= In-Reply-To: References: <1976362964.20130301003817@mtu-net.ru> Message-ID: <22108294.20130301190449@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) ShivaS! S> да, уже вынесли все наружу и оставили только index.php S> Андрей, а зачем redirect? Это вроде rewrite, который я не хочу При чём тут ваше хотение или нехотение? S> использовать. S> try_files имхо отлично делает всю работу, да и везде в нете про него S> написано, когда речь о фреймворках. Миллион леммингов не может ошибаться? S> я прекрасно понимаю RTFM правило и не обратился бы сюда, если бы не зашел в S> некий тупик. Вы гораздо быстрее можете выбраться из тупика, если объясните свою задачу, не используя терминов и примеров, которые вы не понимаете. То есть вообще не используя. Поверьте, вас поймут гораздо лучше, если вы сами будете понимать, что пишете. S> Не могли бы Вы пожалуйста указать мне то место в документации, которое бы S> мне помогло понять как можно определять наличие файла на диске без if и S> request_filename? Буду очень признателен! Я реально в тупике... А вам надо определять это наличие? :) Судя по постановке задачи - нет. Ну так зачем делать дурную работу? -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) пятница, 01.03.2013, <19:02> From nginx-forum at nginx.us Fri Mar 1 15:51:36 2013 From: nginx-forum at nginx.us (theromis1) Date: Fri, 01 Mar 2013 10:51:36 -0500 Subject: counters In-Reply-To: References: Message-ID: <8ea3d0ba755d7a924fad9cadf1c5bc7a.NginxMailingListRussian@forum.nginx.org> Да, совершенно, за той лишь поправкой что он просто удаляет узел счетчика из RBtree, в дальшнейшем если идет обращение к счетчику на изменение такой узел добаавляется (но это внутренние особенности), наверное может быть полезным иметь counter_set но для той задачи оно мне не потребовалось. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236733,236795#msg-236795 From nginx-forum at nginx.us Fri Mar 1 16:34:05 2013 From: nginx-forum at nginx.us (ShivaS) Date: Fri, 01 Mar 2013 11:34:05 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQutCwINC/0LXRgNC10LrRgNGL0YLRjCDQtNC+0YHRgtGD0L8g0Log?= =?UTF-8?B?0LvRjtCx0YvQvCDRhNCw0LnQu9Cw0Lwg0Lgg0LTQuNGA0LXQutGC0L7RgNC4?= =?UTF-8?B?0Y/QvCAoINGE0YDQtdC50LzQstC+0YDQuikg0L3QsCDQtNC40YHQutC1Pw==?= In-Reply-To: <201303011809.30967.vbart@nginx.com> References: <201303011809.30967.vbart@nginx.com> Message-ID: <643c6608c2ced47e04d80707ad1c1a32.NginxMailingListRussian@forum.nginx.org> Валентин, Спасибо еще раз! С ревизией да, там проггеры так и хотели ;-) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236729,236797#msg-236797 From meganuke at meganuke.ru Fri Mar 1 17:24:52 2013 From: meganuke at meganuke.ru (Nikita Stupin) Date: Fri, 01 Mar 2013 21:24:52 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQutCwINC/0LXRgNC10LrRgNGL0YLRjCDQtNC+0YHRgtGD0L8g0Log?= =?UTF-8?B?0LvRjtCx0YvQvCDRhNCw0LnQu9Cw0Lwg0Lgg0LTQuNGA0LXQutGC0L7RgNC4?= =?UTF-8?B?0Y/QvCAoINGE0YDQtdC50LzQstC+0YDQuikg0L3QsCDQtNC40YHQutC1Pw==?= In-Reply-To: References: Message-ID: <5130E464.5000402@meganuke.ru> Шикарная логика :) On 3/1/13 2:45 PM, ShivaS wrote: > если реферер пустой, тогда блокировать запрос > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236729,236767#msg-236767 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From zloykaban at gmail.com Fri Mar 1 20:02:59 2013 From: zloykaban at gmail.com (zloykaban at gmail.com) Date: Fri, 1 Mar 2013 20:02:59 +0000 Subject: =?UTF-8?B?UmU6INCa0LDQutCwINC/0LXRgNC10LrRgNGL0YLRjCDQtNC+0YHRgtGD0L8g0Log?= =?UTF-8?B?0LvRjtCx0YvQvCDRhNCw0LnQu9Cw0Lwg0Lgg0LTQuNGA0LXQutGC0L7RgNC4?= =?UTF-8?B?0Y/QvCAoINGE0YDQtdC50LzQstC+0YDQuikg0L3QsCDQtNC40YHQutC1Pw==?= In-Reply-To: <5130E464.5000402@meganuke.ru> References: <5130E464.5000402@meganuke.ru> Message-ID: <942111870-1362168181-cardhu_decombobulator_blackberry.rim.net-85463280-@b3.c15.bise7.blackberry> Никитос, ёпта, ты знал Sent from my BlackBerry? wireless device -----Original Message----- From: Nikita Stupin Sender: nginx-ru-bounces at nginx.orgDate: Fri, 01 Mar 2013 21:24:52 To: Reply-To: nginx-ru at nginx.org Subject: Re: Кака перекрыть доступ к любым файлам и директориям ( фреймворк) на диске? Шикарная логика :) On 3/1/13 2:45 PM, ShivaS wrote: > если реферер пустой, тогда блокировать запрос > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236729,236767#msg-236767 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ nginx-ru mailing list nginx-ru at nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Fri Mar 1 22:38:37 2013 From: nginx-forum at nginx.us (Namaste) Date: Fri, 01 Mar 2013 17:38:37 -0500 Subject: if_modified_since In-Reply-To: <20130228103920.GC81985@mdounin.ru> References: <20130228103920.GC81985@mdounin.ru> Message-ID: <25adbdf78c0f4a1f7c658da7f998d8b2.NginxMailingListRussian@forum.nginx.org> Привет! А как оно в реальном мире происходит? Браузер грузит страницу первый раз - оставляет ее у себя в хэше и дату из Last-Modified. Запрашивая второй раз, говорит If-modified-since: подставляет дату из Last-Modified первого запроса. Или так: Браузер грузит страницу первый раз - оставляет ее у себя в хэше. Запрашивая второй раз, говорит If-modified-since: сюда подставляет текущую дату. ? Нашел в нете пару сайтов, которые проверяют настройки для 304 ответа. Оба тестера пишут, что не настроено, если в if_modified_since стоит exact. Если поставить before, то пишут, что все ок... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236698,236805#msg-236805 From nginx-forum at nginx.us Fri Mar 1 22:45:49 2013 From: nginx-forum at nginx.us (Namaste) Date: Fri, 01 Mar 2013 17:45:49 -0500 Subject: =?UTF-8?B?ZmFzdGNnaSBjYWNoZSB2YWxpZCDQtNC70Y8g0YDQsNC30L3Ri9GFIGxvY2F0aW9u?= =?UTF-8?B?J9C+0LI=?= Message-ID: <95974d9643fe78b7c0d5fdd90fa300d1.NginxMailingListRussian@forum.nginx.org> Привет! Есть примерно такой вот конфиг: location /aaa/ { rewrite ^/aaa/([0-9]+)\.html$ /test.php?p1=$1 last; } location /bbb/ { rewrite ^/bbb/([0-9]+)\.html$ /test2.php?p1=$1 last; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; fastcgi_cache mycache; fastcgi_cache_key $scheme$host$request_uri$request_method; fastcgi_cache_valid 200 301 302 60m; } Хотелось бы сделать чтоб если срабатывал aaa location, то выдача хэшировалась скажем 5 минут, location bbb - 10 минут. Остальное час. Как такое сделать? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236806,236806#msg-236806 From nginx-forum at nginx.us Fri Mar 1 23:01:01 2013 From: nginx-forum at nginx.us (Namaste) Date: Fri, 01 Mar 2013 18:01:01 -0500 Subject: if_modified_since In-Reply-To: <9e3255ae71ee8de05c0178f0deda4bfd.NginxMailingListRussian@forum.nginx.org> References: <9e3255ae71ee8de05c0178f0deda4bfd.NginxMailingListRussian@forum.nginx.org> Message-ID: <8ad17ed7dd002ccd3e536e41e7a5ef48.NginxMailingListRussian@forum.nginx.org> Кстати, в мобильной версии форума не указан charset. Сафари айфоновская русские символы не показывает. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236698,236807#msg-236807 From hell-for-yahoo at umail.ru Sat Mar 2 00:34:46 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Sat, 2 Mar 2013 04:34:46 +0400 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgdmFsaWQg0LTQu9GPINGA0LDQt9C90YvRhSBsb2Nh?= =?UTF-8?B?dGlvbifQvtCy?= In-Reply-To: <95974d9643fe78b7c0d5fdd90fa300d1.NginxMailingListRussian@forum.nginx.org> References: <95974d9643fe78b7c0d5fdd90fa300d1.NginxMailingListRussian@forum.nginx.org> Message-ID: <174122756.20130302043446@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Namaste! N> Есть примерно такой вот конфиг: N> location /aaa/ { N> rewrite ^/aaa/([0-9]+)\.html$ /test.php?p1=$1 last; N> } N> location /bbb/ { N> rewrite ^/bbb/([0-9]+)\.html$ /test2.php?p1=$1 last; N> } N> location ~ \.php$ { N> fastcgi_pass 127.0.0.1:9000; N> fastcgi_index index.php; N> fastcgi_param SCRIPT_FILENAME N> $document_root$fastcgi_script_name; N> include fastcgi_params; N> fastcgi_cache mycache; N> fastcgi_cache_key $scheme$host$request_uri$request_method; N> fastcgi_cache_valid 200 301 302 60m; N> } N> Хотелось бы сделать чтоб если срабатывал aaa location, то выдача N> хэшировалась скажем 5 минут, location bbb - 10 минут. Остальное час. N> Как такое сделать? Попробуйте прописать fastcgi_cache_valid там, где он вам нужен. По идее, параметры наследуются. Без идеи проще будет проверить. Если не заработает - будем искать другие способы. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) суббота, 02.03.2013, <04:33> From nginx-forum at nginx.us Sat Mar 2 08:58:00 2013 From: nginx-forum at nginx.us (Namaste) Date: Sat, 02 Mar 2013 03:58:00 -0500 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgdmFsaWQg0LTQu9GPINGA0LDQt9C90YvRhSBsb2Nh?= =?UTF-8?B?dGlvbifQvtCy?= In-Reply-To: <174122756.20130302043446@mtu-net.ru> References: <174122756.20130302043446@mtu-net.ru> Message-ID: <085f7d7afb5abd35f08936aca9abe047.NginxMailingListRussian@forum.nginx.org> В том то и дело, что так просто оно не работает. например: server { fastcgi_cache_valid 200 301 302 10s; location /aaa/ { rewrite ^/aaa/([0-9]+)\.html$ /test.php?p1=$1 last; } location /bbb/ { rewrite ^/bbb/([0-9]+)\.html$ /test2.php?p1=$1 last; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; fastcgi_cache mycache; fastcgi_cache_key $scheme$host$request_uri$request_method; #fastcgi_cache_valid 200 301 302 60m; } } Так кэш вообще не включается. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236809,236814#msg-236814 From wanderermg at gmail.com Sat Mar 2 09:10:21 2013 From: wanderermg at gmail.com (Pavel Mironov) Date: Sat, 02 Mar 2013 13:10:21 +0400 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgdmFsaWQg0LTQu9GPINGA0LDQt9C90YvRhSBsb2Nh?= =?UTF-8?B?dGlvbifQvtCy?= In-Reply-To: <085f7d7afb5abd35f08936aca9abe047.NginxMailingListRussian@forum.nginx.org> References: <174122756.20130302043446@mtu-net.ru> <085f7d7afb5abd35f08936aca9abe047.NginxMailingListRussian@forum.nginx.org> Message-ID: <5131C1FD.2080504@gmail.com> Как минимум, в вашем случае определение сроков кеширования надо делать внутри location, а зоны кеширования внутри server: server { fastcgi_cache mycache; fastcgi_cache_key $scheme$host$request_uri$request_method; location/aaa/ { fastcgi_cache_valid 200 301 302 5m; rewrite ^/aaa/([0-9]+)\.html$ /test.php?p1=$1 last; } location/bbb/ { fastcgi_cache_valid 200 301 302 10m; rewrite ^/bbb/([0-9]+)\.html$ /test2.php?p1=$1 last; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } } 02.03.13 12:58, Namaste пишет: > В том то и дело, что так просто оно не работает. > > например: > > server { > > fastcgi_cache_valid 200 301 302 10s; > > location /aaa/ { > rewrite ^/aaa/([0-9]+)\.html$ /test.php?p1=$1 last; > } > > location /bbb/ { > rewrite ^/bbb/([0-9]+)\.html$ /test2.php?p1=$1 last; > } > > location ~ \.php$ { > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; > include fastcgi_params; > fastcgi_cache mycache; > fastcgi_cache_key $scheme$host$request_uri$request_method; > #fastcgi_cache_valid 200 301 302 60m; > } > } > > Так кэш вообще не включается. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236809,236814#msg-236814 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Pavel Mironov -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Mar 2 09:44:10 2013 From: nginx-forum at nginx.us (Namaste) Date: Sat, 02 Mar 2013 04:44:10 -0500 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgdmFsaWQg0LTQu9GPINGA0LDQt9C90YvRhSBsb2Nh?= =?UTF-8?B?dGlvbifQvtCy?= In-Reply-To: <5131C1FD.2080504@gmail.com> References: <5131C1FD.2080504@gmail.com> Message-ID: <0958d5bbf60b91a93f5695978978d195.NginxMailingListRussian@forum.nginx.org> Так кэш не включается. Если в server добавить еще fastcgi_cache_valid, то кэш работает, но время кэширования будет то, которое описано в server, а не в location почему-то. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236809,236816#msg-236816 From igor at sysoev.ru Sat Mar 2 09:58:24 2013 From: igor at sysoev.ru (Igor Sysoev) Date: Sat, 2 Mar 2013 13:58:24 +0400 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgdmFsaWQg0LTQu9GPINGA0LDQt9C90YvRhSBsb2Nh?= =?UTF-8?B?dGlvbifQvtCy?= In-Reply-To: <95974d9643fe78b7c0d5fdd90fa300d1.NginxMailingListRussian@forum.nginx.org> References: <95974d9643fe78b7c0d5fdd90fa300d1.NginxMailingListRussian@forum.nginx.org> Message-ID: On Mar 2, 2013, at 2:45 , Namaste wrote: > Привет! > > Есть примерно такой вот конфиг: > > location /aaa/ { > rewrite ^/aaa/([0-9]+)\.html$ /test.php?p1=$1 last; > } > > location /bbb/ { > rewrite ^/bbb/([0-9]+)\.html$ /test2.php?p1=$1 last; > } > > location ~ \.php$ { > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > fastcgi_param SCRIPT_FILENAME > $document_root$fastcgi_script_name; > include fastcgi_params; > fastcgi_cache mycache; > fastcgi_cache_key $scheme$host$request_uri$request_method; > fastcgi_cache_valid 200 301 302 60m; > } > > Хотелось бы сделать чтоб если срабатывал aaa location, то выдача > хэшировалась скажем 5 минут, location bbb - 10 минут. Остальное час. > Как такое сделать? location /aaa/ { location ~ ^/aaa/([0-9]+)\.html$ { fastcgi_pass 127.0.0.1:9000; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root/test1.php; fastcgi_param QUERY_STRING p1=$page; fastcgi_cache mycache; fastcgi_cache_key $scheme$host$request_uri$request_method; fastcgi_cache_valid 200 301 302 5m; } } и так далее. -- Igor Sysoev http://nginx.com/support.html From nginx-forum at nginx.us Sat Mar 2 10:29:18 2013 From: nginx-forum at nginx.us (Namaste) Date: Sat, 02 Mar 2013 05:29:18 -0500 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgdmFsaWQg0LTQu9GPINGA0LDQt9C90YvRhSBsb2Nh?= =?UTF-8?B?dGlvbifQvtCy?= In-Reply-To: References: Message-ID: <15fb0c22aa1774b3058374ed064c71e3.NginxMailingListRussian@forum.nginx.org> Ясно, спасибо. Длиннющий же правда конфиг получится.. :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236817,236818#msg-236818 From igor at sysoev.ru Sat Mar 2 10:35:59 2013 From: igor at sysoev.ru (Igor Sysoev) Date: Sat, 2 Mar 2013 14:35:59 +0400 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgdmFsaWQg0LTQu9GPINGA0LDQt9C90YvRhSBsb2Nh?= =?UTF-8?B?dGlvbifQvtCy?= In-Reply-To: <15fb0c22aa1774b3058374ed064c71e3.NginxMailingListRussian@forum.nginx.org> References: <15fb0c22aa1774b3058374ed064c71e3.NginxMailingListRussian@forum.nginx.org> Message-ID: <9A5A931D-456F-4968-A94B-FF40AC855C79@sysoev.ru> On Mar 2, 2013, at 14:29 , Namaste wrote: > Ясно, спасибо. > Длиннющий же правда конфиг получится.. :) Нужно выбирать - или мы быстро лабаем короткий конфиг из реврайтов, а потом проклинаем их при каждом изменении конфигурации (но переделывать реврайты всё равно не хотим), или же описываем в каждом location'е всё необходимую функциональность, а потом при изменении конфигурации быстро добавляем/изменяем нужное с помощью любимого редактора. -- Igor Sysoev http://nginx.com/support.html From nginx-forum at nginx.us Sat Mar 2 13:15:18 2013 From: nginx-forum at nginx.us (anon) Date: Sat, 02 Mar 2013 08:15:18 -0500 Subject: =?UTF-8?B?UmU6INCh0L3QvtCy0LAg0L4gNDAw?= In-Reply-To: <5130C2E3.5030500@kopeyko.ru> References: <5130C2E3.5030500@kopeyko.ru> Message-ID: <6c6dfa2d0bc476041733cb5dc3e37f95.NginxMailingListRussian@forum.nginx.org> в log_format есть UA, но к сожалению эти реквесты без него. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236787,236821#msg-236821 From nginx-forum at nginx.us Sat Mar 2 13:48:56 2013 From: nginx-forum at nginx.us (Namaste) Date: Sat, 02 Mar 2013 08:48:56 -0500 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgdmFsaWQg0LTQu9GPINGA0LDQt9C90YvRhSBsb2Nh?= =?UTF-8?B?dGlvbifQvtCy?= In-Reply-To: <9A5A931D-456F-4968-A94B-FF40AC855C79@sysoev.ru> References: <9A5A931D-456F-4968-A94B-FF40AC855C79@sysoev.ru> Message-ID: <6881d37bfe82d4cf9a266bdec65f09a7.NginxMailingListRussian@forum.nginx.org> Ну, мой выбор - не наспех написанных конфиг. Конечно мне хочется, чтоб он был адекватным для понимания сервером. И чтоб самому в нем не путаться и легко производить изменения. Но я совершенно не понимаю, что Вы имеете в виду, когда говорите о том, что придется проклинать короткий конфиг из реврайтов и что гораздо удобнее создать конфиг в виде рулончика однотипных параметров и потом этот рулончик быстро изменять при необходимости... Если в location 2 реврайта, типа: location /aaa/ { rewrite ^/aaa/(.*)-([0-9]+)\.html$ /test.php?p1=$1&p2=$2 last; rewrite ^/aaa/(.*)\.html$ /test.php?p1=$1 last; } нужно будет его оформить в виде таких вот длинных вложенных локейшена как Вы предложили? и если еще локейшенов типа "aaa" несколько, то довольно длинный конфиг получается, причем из однотипных параметров в основном.. с моей точки зрения первоначально предложенный вариант конфига выглядит и удобней и логичней, вот только не работает так как козалось бы должно работать. Я думаю подобные трудности не только у меня возникают. Если человек, который только начинает знакомство с nginx, пишет неправильный с точки зрения этого сервера конфиг, то он делает ведь это не от упрямства - просто для человека такой конфиг выглядит вполне логичным. А в доках как-то не особо все эти нюансы описаны.. :( Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236817,236822#msg-236822 From alexey.bobok at gmail.com Sat Mar 2 16:25:06 2013 From: alexey.bobok at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JHQvtCx0L7Qug==?=) Date: Sat, 2 Mar 2013 18:25:06 +0200 Subject: reload vs restart nginx Message-ID: Igor Sysoev writes: > > > Вот интересует в частности при обновление баз MaxMind > для geoip модуля требуется рестарт или нет? > > Не надо. Приветствую. kill -HUP же нужно в этом случае делать? -- Think before you print. Best regards, Alexey Bobok. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Mar 2 16:27:04 2013 From: nginx-forum at nginx.us (anon) Date: Sat, 02 Mar 2013 11:27:04 -0500 Subject: =?UTF-8?B?UmU6INCh0L3QvtCy0LAg0L4gNDAw?= In-Reply-To: <5130C2E3.5030500@kopeyko.ru> References: <5130C2E3.5030500@kopeyko.ru> Message-ID: в LOG_format есть это, но к сожалению у них нет ua. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236787,236803#msg-236803 From nginx-forum at nginx.us Sat Mar 2 16:27:16 2013 From: nginx-forum at nginx.us (anon) Date: Sat, 02 Mar 2013 11:27:16 -0500 Subject: =?UTF-8?B?UmU6INCh0L3QvtCy0LAg0L4gNDAw?= In-Reply-To: <5130C2E3.5030500@kopeyko.ru> References: <5130C2E3.5030500@kopeyko.ru> Message-ID: <0cc5145cafbf80afdcab6092036f436f.NginxMailingListRussian@forum.nginx.org> в log_format есть ua, но эти реквесты, к сожалению без них. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236787,236820#msg-236820 From nginx-forum at nginx.us Sat Mar 2 16:27:16 2013 From: nginx-forum at nginx.us (anon) Date: Sat, 02 Mar 2013 11:27:16 -0500 Subject: =?UTF-8?B?UmU6INCh0L3QvtCy0LAg0L4gNDAw?= In-Reply-To: <5130C2E3.5030500@kopeyko.ru> References: <5130C2E3.5030500@kopeyko.ru> Message-ID: <0cc5145cafbf80afdcab6092036f436f.NginxMailingListRussian@forum.nginx.org> в log_format есть ua, но эти реквесты, к сожалению без них. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236787,236820#msg-236820 From hell-for-yahoo at umail.ru Sat Mar 2 16:31:03 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Sat, 2 Mar 2013 20:31:03 +0400 Subject: =?UTF-8?B?UmU6INCh0L3QvtCy0LAg0L4gNDAw?= In-Reply-To: <6c6dfa2d0bc476041733cb5dc3e37f95.NginxMailingListRussian@forum.nginx.org> References: <5130C2E3.5030500@kopeyko.ru> <6c6dfa2d0bc476041733cb5dc3e37f95.NginxMailingListRussian@forum.nginx.org> Message-ID: <1559754624.20130302203103@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) anon! a> в log_format есть UA, но к сожалению эти реквесты без него. Сказали "в то же время, с тех же адресов", а не "эти реквесты"... -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) суббота, 02.03.2013, <20:30> From onokonem at gmail.com Sat Mar 2 17:25:11 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Sat, 2 Mar 2013 20:25:11 +0300 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgdmFsaWQg0LTQu9GPINGA0LDQt9C90YvRhSBsb2Nh?= =?UTF-8?B?dGlvbifQvtCy?= In-Reply-To: <6881d37bfe82d4cf9a266bdec65f09a7.NginxMailingListRussian@forum.nginx.org> References: <9A5A931D-456F-4968-A94B-FF40AC855C79@sysoev.ru> <6881d37bfe82d4cf9a266bdec65f09a7.NginxMailingListRussian@forum.nginx.org> Message-ID: > Если человек, который > только начинает знакомство с nginx, пишет неправильный с точки зрения этого > сервера конфиг, то он делает ведь это не от упрямства - просто для человека > такой конфиг выглядит вполне логичным. А если человек уже продолжает такое знакомство, но все равно хочет писать "на рерайтах" - это от упрямства? From nginx-forum at nginx.us Sat Mar 2 18:36:49 2013 From: nginx-forum at nginx.us (Namaste) Date: Sat, 02 Mar 2013 13:36:49 -0500 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgdmFsaWQg0LTQu9GPINGA0LDQt9C90YvRhSBsb2Nh?= =?UTF-8?B?dGlvbifQvtCy?= In-Reply-To: References: Message-ID: <0f92a418675f210dcf2e3151cfecb4c9.NginxMailingListRussian@forum.nginx.org> Знакомиться и продолжать знакомство - почти одно и тоже :) Вот когда человек познакомится хорошенько... :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236817,236827#msg-236827 From nginx-forum at nginx.us Sat Mar 2 20:11:14 2013 From: nginx-forum at nginx.us (Namaste) Date: Sat, 02 Mar 2013 15:11:14 -0500 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgdmFsaWQg0LTQu9GPINGA0LDQt9C90YvRhSBsb2Nh?= =?UTF-8?B?dGlvbifQvtCy?= In-Reply-To: References: Message-ID: <2baf0194748bcf5a9dc4026de5a764b0.NginxMailingListRussian@forum.nginx.org> Переделываю конфиг. Будет значит допустим так: location /aaa/ { location ~ ^/aaa/([0-9]+)\.html$ { fastcgi_pass 127.0.0.1:9000; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root/test1.php; fastcgi_param QUERY_STRING p1=$1; fastcgi_cache mycache; fastcgi_cache_key $scheme$host$request_uri$request_method; fastcgi_cache_valid 200 301 302 5m; } location ~ ^/aaa/(.*)-([0-9]+)\.html$ { fastcgi_pass 127.0.0.1:9000; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root/test1.php; fastcgi_param QUERY_STRING p1=$1&p2=$2; fastcgi_cache mycache; fastcgi_cache_key $scheme$host$request_uri$request_method; fastcgi_cache_valid 200 301 302 5m; } } И таких локейшенов типа aaa будет например с десяток. Итого 20 локейшенов... Ок. Теперь я хочу, например отключить кэш для всех. Я так понимаю, что мне нужно всего лишь быстро закомментировать ненужное с помощью любимого редактора? :) Может можно как-то поудобней все это устроить? include можно здесь сделать? Например эти строки будут одинаковы почти для всех локейшенов: fastcgi_cache mycache; fastcgi_cache_key $scheme$host$request_uri$request_method; fastcgi_cache_valid 200 301 302 5m; Можно их заинклудить, а в некоторых локейшенах продублировать fastcgi_cache_valid с другим временем? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236817,236830#msg-236830 From panfilov at sports.ru Sat Mar 2 20:16:13 2013 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Sun, 3 Mar 2013 00:16:13 +0400 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgdmFsaWQg0LTQu9GPINGA0LDQt9C90YvRhSBsb2Nh?= =?UTF-8?B?dGlvbifQvtCy?= In-Reply-To: <2baf0194748bcf5a9dc4026de5a764b0.NginxMailingListRussian@forum.nginx.org> References: <2baf0194748bcf5a9dc4026de5a764b0.NginxMailingListRussian@forum.nginx.org> Message-ID: include будет работать 3 марта 2013 г., 0:11 пользователь Namaste написал: > Переделываю конфиг. Будет значит допустим так: > > location /aaa/ { > location ~ ^/aaa/([0-9]+)\.html$ { > fastcgi_pass 127.0.0.1:9000; > include fastcgi_params; > fastcgi_param SCRIPT_FILENAME $document_root/test1.php; > fastcgi_param QUERY_STRING p1=$1; > fastcgi_cache mycache; > fastcgi_cache_key $scheme$host$request_uri$request_method; > fastcgi_cache_valid 200 301 302 5m; > } > location ~ ^/aaa/(.*)-([0-9]+)\.html$ { > fastcgi_pass 127.0.0.1:9000; > include fastcgi_params; > fastcgi_param SCRIPT_FILENAME $document_root/test1.php; > fastcgi_param QUERY_STRING p1=$1&p2=$2; > fastcgi_cache mycache; > fastcgi_cache_key $scheme$host$request_uri$request_method; > fastcgi_cache_valid 200 301 302 5m; > } > } > > И таких локейшенов типа aaa будет например с десяток. Итого 20 > локейшенов... > Ок. Теперь я хочу, например отключить кэш для всех. > Я так понимаю, что мне нужно всего лишь быстро закомментировать ненужное с > помощью любимого редактора? :) > Может можно как-то поудобней все это устроить? include можно здесь сделать? > > Например эти строки будут одинаковы почти для всех локейшенов: > fastcgi_cache mycache; > fastcgi_cache_key $scheme$host$request_uri$request_method; > fastcgi_cache_valid 200 301 302 5m; > > Можно их заинклудить, а в некоторых локейшенах продублировать > fastcgi_cache_valid с другим временем? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,236817,236830#msg-236830 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Панфилов Михаил -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Mar 2 20:57:09 2013 From: nginx-forum at nginx.us (Namaste) Date: Sat, 02 Mar 2013 15:57:09 -0500 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgdmFsaWQg0LTQu9GPINGA0LDQt9C90YvRhSBsb2Nh?= =?UTF-8?B?dGlvbifQvtCy?= In-Reply-To: References: Message-ID: <8f92b23be4280a48651bad66bf503841.NginxMailingListRussian@forum.nginx.org> Да, заработало. Правда как-то странно. Я спрашивал не можно ли заинклудить, а можно ли заинклудить И продублировать один из параметров. Сделал файл mycache_params с таким содержимым: fastcgi_cache mycache; fastcgi_cache_key $scheme$host$request_uri$request_method; fastcgi_cache_valid 200 301 302 5m; сделал инклуд этого файла во все локейшены. и в одном из локейшенов продублировал параметр fastcgi_cache_valid. т.е. в этом локейшене получилось так: include mycache_params; fastcgi_cache_valid 200 301 302 5s; В моем понимании в конечном итоге конфиг в этом локейшене был бы такой: fastcgi_cache mycache; fastcgi_cache_key $scheme$host$request_uri$request_method; fastcgi_cache_valid 200 301 302 5m; fastcgi_cache_valid 200 301 302 5s; т.е. время кэша должно быть 5 секунд. Но не тут-то было! :) чтоб было 5 секунд, почему-то нужно делать так: fastcgi_cache_valid 200 301 302 5s; include mycache_params; Так оно вроде бы работает как мне нужно, только не знаю, по фэн-шую ли такой конфиг? :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236817,236832#msg-236832 From mdounin at mdounin.ru Sat Mar 2 20:57:42 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 3 Mar 2013 00:57:42 +0400 Subject: if_modified_since In-Reply-To: <25adbdf78c0f4a1f7c658da7f998d8b2.NginxMailingListRussian@forum.nginx.org> References: <20130228103920.GC81985@mdounin.ru> <25adbdf78c0f4a1f7c658da7f998d8b2.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130302205742.GA15378@mdounin.ru> Hello! On Fri, Mar 01, 2013 at 05:38:37PM -0500, Namaste wrote: > Привет! > > А как оно в реальном мире происходит? > > Браузер грузит страницу первый раз - оставляет ее у себя в хэше и дату из > Last-Modified. > Запрашивая второй раз, говорит If-modified-since: подставляет дату из > Last-Modified первого запроса. > > Или так: > Браузер грузит страницу первый раз - оставляет ее у себя в хэше. > Запрашивая второй раз, говорит If-modified-since: сюда подставляет текущую > дату. > > ? В реальном мире - используется Last-Modified из имеющегося в кеше ответа. > Нашел в нете пару сайтов, которые проверяют настройки для 304 ответа. > Оба тестера пишут, что не настроено, если в if_modified_since стоит exact. > Если поставить before, то пишут, что все ок... http://xkcd.com/386 -- Maxim Dounin http://nginx.org/en/donation.html From tvword at gmail.com Sat Mar 2 21:12:50 2013 From: tvword at gmail.com (Vladislav) Date: Sat, 02 Mar 2013 23:12:50 +0200 Subject: URL -> execute C-program Message-ID: <51326B52.6070609@gmail.com> Подскажите, плиз, можно ли сделать так, чтобы: 1. при обращении к определенному url срабатывала программа на сервере, написанная на С? 2. вывод программы выдавался в клиентский браузер? Спасибо! From wanderermg at gmail.com Sat Mar 2 21:21:35 2013 From: wanderermg at gmail.com (Pavel Mironov) Date: Sun, 03 Mar 2013 01:21:35 +0400 Subject: URL -> execute C-program In-Reply-To: <51326B52.6070609@gmail.com> References: <51326B52.6070609@gmail.com> Message-ID: <51326D5F.2030504@gmail.com> Добрый день, Владислав! http://ru.wikipedia.org/wiki/CGI http://ru.wikipedia.org/wiki/FastCGI http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html 03.03.13 1:12, Vladislav пишет: > Подскажите, плиз, можно ли сделать так, чтобы: > > 1. при обращении к определенному url срабатывала программа на сервере, > написанная на С? > 2. вывод программы выдавался в клиентский браузер? > > Спасибо! > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Pavel Mironov From mdounin at mdounin.ru Sat Mar 2 22:24:51 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 3 Mar 2013 02:24:51 +0400 Subject: if_modified_since In-Reply-To: <8ad17ed7dd002ccd3e536e41e7a5ef48.NginxMailingListRussian@forum.nginx.org> References: <9e3255ae71ee8de05c0178f0deda4bfd.NginxMailingListRussian@forum.nginx.org> <8ad17ed7dd002ccd3e536e41e7a5ef48.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130302222451.GC15378@mdounin.ru> Hello! On Fri, Mar 01, 2013 at 06:01:01PM -0500, Namaste wrote: > Кстати, в мобильной версии форума не указан charset. Сафари айфоновская > русские символы не показывает. Спасибо, поправим (ну или закроем уже этот форум в конце-то концов, одни проблемы от него). -- Maxim Dounin http://nginx.org/en/donation.html From karamba66 at ukr.net Sun Mar 3 09:28:33 2013 From: karamba66 at ukr.net (ZZZ) Date: Sun, 03 Mar 2013 10:28:33 +0100 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0LHQvtGC0LDQtdGCINGB0LLRj9C30LrQsCBpcCBoYXNo?= =?UTF-8?B?INC4IHdlaWdodCA/?= In-Reply-To: <20130207105846.GC66348@mdounin.ru> References: <17626554fac7aa3bc0b467d99294f2cf.NginxMailingListRussian@forum.nginx.org> <20130207105846.GC66348@mdounin.ru> Message-ID: <513317C1.6020506@ukr.net> 07.02.2013 11:58, Maxim Dounin wrote: > Hello! > > On Thu, Feb 07, 2013 at 01:47:30AM -0500, gintonic wrote: > >> Всем привет. >> Объясните пожалуйста как работает данная связка. Версия nginx 1.2.6 >> Сейчас в логе есть такие записи: >> 2013/02/07 07:06:19 [error] 32106#0: *6369192 upstream timed out (110: >> Connection timed out) while reading response header from upstream, client: >> 195.72.228.242, server: *.ru, request: "GET /App_Shared/Handlers/Grid.ashx >> HTTP/1.1", upstream: "http://192.168.1.41:80/App_Shared/Handlers/Grid.ashx", >> host: "www.site.ru", referrer: "http://www.site.ru/home/home.aspx" >> 2013/02/07 07:08:19 [error] 32106#0: *6369192 upstream timed out (110: >> Connection timed out) while reading response header from upstream, client: >> 195.72.228.242, server: *.ru, request: "GET /App_Shared/Handlers/Grid.ashx >> HTTP/1.1", upstream: "http://192.168.1.51:80/App_Shared/Handlers/Grid.ashx", >> host: "www.site.ru", referrer: "http://www.site.ru/home/home.aspx" >> --------------- >> Только, пожалуйста, не надо обращать внимание на таймауты бэкенда и то что >> это aspx! Вопрос не в этом. >> Почему запросы с одного IP попадают в разные бэкенды? >> Конфиг такой: >> upstream backend_web_servers { >> ip_hash; >> server 192.168.1.41:80 weight=4 max_fails=3 fail_timeout=30s; >> server 192.168.1.51:80 weight=6 max_fails=3 fail_timeout=30s; >> } > Если бекенд не отвечает на запрос (как в данном случае) - запрос > отправляется (или не отправляется) на другой бекенд в соответствии > с proxy_next_upstream. > > http://nginx.org/r/proxy_next_upstream/ru > > Если бекенд уже мёртв в соответствии с max_fails/fail_timeout - > запрос сразу отправляется на какой-то другой бекенд. > > http://nginx.org/r/ip_hash/ru > Тоже наблюдаю картину когда запросы с одного ip попадают на разные бекенды. Если убрать weight то всё ок. Нигде не могу найти описание алгоритма работы ip_hash совместно в weight. From vovansystems at gmail.com Sun Mar 3 09:36:18 2013 From: vovansystems at gmail.com (VovansystemS) Date: Sun, 3 Mar 2013 12:36:18 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0LHQvtGC0LDQtdGCINGB0LLRj9C30LrQsCBpcCBoYXNo?= =?UTF-8?B?INC4IHdlaWdodCA/?= In-Reply-To: <513317C1.6020506@ukr.net> References: <17626554fac7aa3bc0b467d99294f2cf.NginxMailingListRussian@forum.nginx.org> <20130207105846.GC66348@mdounin.ru> <513317C1.6020506@ukr.net> Message-ID: > Тоже наблюдаю картину когда запросы с одного ip попадают на разные бекенды. > Если убрать weight то всё ок. Нигде не могу найти описание алгоритма работы > ip_hash совместно в weight. "Метод гарантирует, что запросы одного и того же клиента будут всегда передаваться на один и тот же сервер. Если же этот сервер будет считаться неработающим, то запросы этого клиента будут передаваться на другой сервер. С большой долей вероятности это также будет один и тот же сервер." http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#ip_hash И так работает всегда. Weight в данном случае ни на что не влияет. Если конфиг верный, возможно периодически "пропадают" сервера (нужно копать в сторону fail_timeout и max_fails и тестировать стабильность связи). Выше Максим всё это расписал подробно. From nginx-forum at nginx.us Sun Mar 3 11:11:38 2013 From: nginx-forum at nginx.us (Namaste) Date: Sun, 03 Mar 2013 06:11:38 -0500 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgdmFsaWQg0LTQu9GPINGA0LDQt9C90YvRhSBsb2Nh?= =?UTF-8?B?dGlvbifQvtCy?= In-Reply-To: <8f92b23be4280a48651bad66bf503841.NginxMailingListRussian@forum.nginx.org> References: <8f92b23be4280a48651bad66bf503841.NginxMailingListRussian@forum.nginx.org> Message-ID: <4cec43d5ede187d08af60adae6eff98a.NginxMailingListRussian@forum.nginx.org> Namaste Wrote: ------------------------------------------------------- > Да, заработало. Правда как-то странно. Я спрашивал не можно ли > заинклудить, а можно ли заинклудить И продублировать один из > параметров. > > Сделал файл mycache_params с таким содержимым: > > fastcgi_cache mycache; > fastcgi_cache_key $scheme$host$request_uri$request_method; > fastcgi_cache_valid 200 301 302 5m; > > сделал инклуд этого файла во все локейшены. и в одном из локейшенов > продублировал параметр fastcgi_cache_valid. > т.е. в этом локейшене получилось так: > include mycache_params; > fastcgi_cache_valid 200 301 302 5s; > > В моем понимании в конечном итоге конфиг в этом локейшене был бы > такой: > fastcgi_cache mycache; > fastcgi_cache_key $scheme$host$request_uri$request_method; > fastcgi_cache_valid 200 301 302 5m; > fastcgi_cache_valid 200 301 302 5s; > > т.е. время кэша должно быть 5 секунд. Но не тут-то было! :) > чтоб было 5 секунд, почему-то нужно делать так: > > fastcgi_cache_valid 200 301 302 5s; > include mycache_params; > > Так оно вроде бы работает как мне нужно, только не знаю, по фэн-шую ли > такой конфиг? :) Объясните пожалуйста такое поведение nginx'а? Не сглючит он у меня потом из-за такого конфига? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236817,236848#msg-236848 From karamba66 at ukr.net Sun Mar 3 11:54:31 2013 From: karamba66 at ukr.net (ZZZ) Date: Sun, 03 Mar 2013 12:54:31 +0100 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0LHQvtGC0LDQtdGCINGB0LLRj9C30LrQsCBpcCBoYXNo?= =?UTF-8?B?INC4IHdlaWdodCA/?= In-Reply-To: References: <17626554fac7aa3bc0b467d99294f2cf.NginxMailingListRussian@forum.nginx.org> <20130207105846.GC66348@mdounin.ru> <513317C1.6020506@ukr.net> Message-ID: <513339F7.70204@ukr.net> 03.03.2013 10:36, VovansystemS wrote: > И так работает всегда. Weight в данном случае ни на что не влияет. > Если конфиг верный, возможно периодически "пропадают" сервера (нужно > копать в сторону fail_timeout и max_fails и тестировать стабильность > связи). Выше Максим всё это расписал подробно. Да, я читал, что писал Максим, но результаты вполне повторяемы: есть weight - скачим по нодам, убираем weight - всё ок. "Пропадающие" сервера пропадали бы и с weight. Поэтому хотелось бы всё-таки узнать алгоритм. weight влияет только на распределение новых IP, которых ещё нет в хеше ? From vovansystems at gmail.com Sun Mar 3 12:21:24 2013 From: vovansystems at gmail.com (VovansystemS) Date: Sun, 3 Mar 2013 15:21:24 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0LHQvtGC0LDQtdGCINGB0LLRj9C30LrQsCBpcCBoYXNo?= =?UTF-8?B?INC4IHdlaWdodCA/?= In-Reply-To: <513339F7.70204@ukr.net> References: <17626554fac7aa3bc0b467d99294f2cf.NginxMailingListRussian@forum.nginx.org> <20130207105846.GC66348@mdounin.ru> <513317C1.6020506@ukr.net> <513339F7.70204@ukr.net> Message-ID: >> И так работает всегда. Weight в данном случае ни на что не влияет. >> Если конфиг верный, возможно периодически "пропадают" сервера (нужно >> копать в сторону fail_timeout и max_fails и тестировать стабильность >> связи). Выше Максим всё это расписал подробно. > > Да, я читал, что писал Максим, но результаты вполне повторяемы: есть weight > - скачим по нодам, убираем weight - всё ок. "Пропадающие" сервера пропадали > бы и с weight. Поэтому хотелось бы всё-таки узнать алгоритм. weight влияет > только на распределение новых IP, которых ещё нет в хеше ? nginx version: nginx/1.2.7 - не получилось воспроизвести Ваш глюк. при включённом ip_hash мне всегда выдаёт один и тот же сервер из upstream - как с включёными весами, так и с отключенными (я протестировал множество разных конфигураций, разные веса, например). Проверял через юникс-сокеты и переменную $upstream_addr. Вот кусочки конфигов: upstream backend { ip_hash; server unix:/var/run/fpm1.sock weight=2;. server unix:/var/run/fpm2.sock weight=5; } location /z/ { try_files $fastcgi_script_name =404; include fastcgi_params; fastcgi_pass backend; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; add_header X-Upstream-addr $upstream_addr; } Возможно, у Вас размер таблицы для хешей маловат и не все туда помещаются. Кто не влазит - будет "прыгать", судя по всему. Но об этом должны быть сообщения в логе ошибок. Наверное, стоит таже показать Ваши конфиги. From mdounin at mdounin.ru Sun Mar 3 12:39:52 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 3 Mar 2013 16:39:52 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0LHQvtGC0LDQtdGCINGB0LLRj9C30LrQsCBpcCBoYXNo?= =?UTF-8?B?INC4IHdlaWdodCA/?= In-Reply-To: <513339F7.70204@ukr.net> References: <17626554fac7aa3bc0b467d99294f2cf.NginxMailingListRussian@forum.nginx.org> <20130207105846.GC66348@mdounin.ru> <513317C1.6020506@ukr.net> <513339F7.70204@ukr.net> Message-ID: <20130303123952.GF15378@mdounin.ru> Hello! On Sun, Mar 03, 2013 at 12:54:31PM +0100, ZZZ wrote: > 03.03.2013 10:36, VovansystemS wrote: > >И так работает всегда. Weight в данном случае ни на что не влияет. > >Если конфиг верный, возможно периодически "пропадают" сервера (нужно > >копать в сторону fail_timeout и max_fails и тестировать стабильность > >связи). Выше Максим всё это расписал подробно. > Да, я читал, что писал Максим, но результаты вполне повторяемы: есть > weight - скачим по нодам, убираем weight - всё ок. "Пропадающие" > сервера пропадали бы и с weight. Поэтому хотелось бы всё-таки узнать > алгоритм. Указание weight - эквивалентно указанию одного и того же сервера несколько раз подряд (но при этом с точки зрения nginx'а это один сервер, и счётчик ошибок - единый). > weight влияет только на распределение новых IP, которых > ещё нет в хеше ? Балансировка ip_hash не предусматривает хранение чего либо "в хеше", для выбора бекенда используется результат вычисления хеш-функции от (части) ip-адреса. -- Maxim Dounin http://nginx.org/en/donation.html From denis at webmaster.spb.ru Sun Mar 3 22:57:49 2013 From: denis at webmaster.spb.ru (denis) Date: Mon, 04 Mar 2013 02:57:49 +0400 Subject: =?UTF-8?B?0J3QtSDRgdGA0LDQsdCw0YLRi9Cy0LDQtdGCIGxpbWl0X2Nvbm4g0LggbGltaXRf?= =?UTF-8?B?cmVxPw==?= Message-ID: <5133D56D.2070402@webmaster.spb.ru> debian 6, nginx 1.2.7 ... http { limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn_zone $server_name zone=perserver:10m; limit_req_zone $server_name zone=lreq:10m rate=1r/m; server { .... location = /redir.php { #limit_conn perserver 1; #(1) limit_req zone=lreq burst=1; #(2) #error_page 503 =302 /redir-503.php; error_page 503 =302 https://ext-site.ru/under_construction.html; limit_conn_log_level info; return http://ext-site.ru/content; } }} Сама секция работает, редирект всегда на ext-site.ru/content работает, а вот ограничение не срабатывает. Также с вариантом, когда раскомментирован (1) и закомментирован (2). Что не так? From szh.subs at gmail.com Mon Mar 4 04:29:00 2013 From: szh.subs at gmail.com (Sergey Zhemzhitsky) Date: Mon, 4 Mar 2013 08:29:00 +0400 Subject: =?UTF-8?B?0JPQtNC1INC70YPRh9GI0LUg0LLRgdC10LPQviDRhdGA0LDQvdC40YLRjCDRgdC+?= =?UTF-8?B?0YHRgtC+0Y/QvdC40LUg0LzQvtC00YPQu9GPPw==?= Message-ID: <1114475269.20130304082900@gmail.com> Привет, Nginx Гуру Модули к nginx никогда не разрабатывал, поэтому не пинайте сильно. Я пытаюсь написать nginx http-модуль к сторонней системе у которой есть С API. Под этим API лежит в том чесле и установка TCP/IP соединения. Насколько я понял, правильным способом подключения к сторонней системе была бы разработка unstream http модуля. Проблема в том, что протокол довольно сложный и в условиях ограниченного времени разбираться с ним некогда, поэтому хотелось бы попользовать API, которое предоставляет система. Посоветуйте, плиз, по следующим вопросам 1. Где лучше всего хранить объекты, которые должны быть созданы и инициализированы только один раз для куска конфигурации server или http? 2. Где лучше всего создавать объекты, которые должны присутствовать единожды для конфигурации server или http (например, устанавливать соединение со сторонней системой)? 3. Насколько я понял под upstream-ами *всегда* лежит асинхронное сокетное api. Верно? 4. Насколько плохо работать напрямую со своими TPC/IP соединениями прямо из request handler-ов? С уважением, Сергей From ru at nginx.com Mon Mar 4 07:24:21 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Mon, 4 Mar 2013 11:24:21 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgNCw0LHQsNGC0YvQstCw0LXRgiBsaW1pdF9jb25uINC4IGxp?= =?UTF-8?B?bWl0X3JlcT8=?= In-Reply-To: <5133D56D.2070402@webmaster.spb.ru> References: <5133D56D.2070402@webmaster.spb.ru> Message-ID: <20130304072421.GA77589@lo0.su> On Mon, Mar 04, 2013 at 02:57:49AM +0400, denis wrote: > debian 6, nginx 1.2.7 > ... > http { > limit_conn_zone $binary_remote_addr zone=perip:10m; > limit_conn_zone $server_name zone=perserver:10m; > > limit_req_zone $server_name zone=lreq:10m rate=1r/m; > > server { .... > location = /redir.php { > #limit_conn perserver 1; #(1) > limit_req zone=lreq burst=1; #(2) > #error_page 503 =302 /redir-503.php; > error_page 503 =302 https://ext-site.ru/under_construction.html; > > limit_conn_log_level info; > > return http://ext-site.ru/content; > } > }} > > Сама секция работает, редирект всегда на ext-site.ru/content работает, а > вот ограничение не срабатывает. Также с вариантом, когда > раскомментирован (1) и закомментирован (2). > Что не так? Обработка запросов в nginx происходит в разных фазах. Директивы модуля ngx_http_rewrite_module (директива return в т.ч.) срабатывают на более ранних фазах, чем модули ngx_http_limit_*. Описанное выше поведение ожидаемо. From denis at webmaster.spb.ru Mon Mar 4 09:24:34 2013 From: denis at webmaster.spb.ru (denis) Date: Mon, 04 Mar 2013 13:24:34 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgNCw0LHQsNGC0YvQstCw0LXRgiBsaW1pdF9jb25uINC4IGxp?= =?UTF-8?B?bWl0X3JlcT8=?= In-Reply-To: <20130304072421.GA77589@lo0.su> References: <5133D56D.2070402@webmaster.spb.ru> <20130304072421.GA77589@lo0.su> Message-ID: <51346852.1040400@webmaster.spb.ru> 04.03.2013 11:24, Ruslan Ermilov пишет: > Обработка запросов в nginx происходит в разных фазах. > Директивы модуля ngx_http_rewrite_module (директива return в т.ч.) > срабатывают на более ранних фазах, чем модули ngx_http_limit_*. > > Описанное выше поведение ожидаемо. А как тогда быть? try_files? From ru at nginx.com Mon Mar 4 10:45:08 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Mon, 4 Mar 2013 14:45:08 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgNCw0LHQsNGC0YvQstCw0LXRgiBsaW1pdF9jb25uINC4IGxp?= =?UTF-8?B?bWl0X3JlcT8=?= In-Reply-To: <51346852.1040400@webmaster.spb.ru> References: <5133D56D.2070402@webmaster.spb.ru> <20130304072421.GA77589@lo0.su> <51346852.1040400@webmaster.spb.ru> Message-ID: <20130304104508.GC77589@lo0.su> On Mon, Mar 04, 2013 at 01:24:34PM +0400, denis wrote: > 04.03.2013 11:24, Ruslan Ermilov пишет: > > Обработка запросов в nginx происходит в разных фазах. > > Директивы модуля ngx_http_rewrite_module (директива return в т.ч.) > > срабатывают на более ранних фазах, чем модули ngx_http_limit_*. > > > > Описанное выше поведение ожидаемо. > А как тогда быть? try_files? Как вариант, можно определить отдельный URI для 302, который будет представлен статическим файлом, и задать желаемое ограничение там: http { limit_req_zone $server_name zone=lreq:10m rate=1r/m; server { server_name test; location = /redir.php { error_page 302 /302.html; return http://ext-site.ru/content; } location = /302.html { internal; limit_req zone=lreq burst=1; } } } (Что положить внутрь файла 302.html - дело вкуса.) From denis at webmaster.spb.ru Mon Mar 4 12:00:53 2013 From: denis at webmaster.spb.ru (denis) Date: Mon, 04 Mar 2013 16:00:53 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgNCw0LHQsNGC0YvQstCw0LXRgiBsaW1pdF9jb25uINC4IGxp?= =?UTF-8?B?bWl0X3JlcT8=?= In-Reply-To: <20130304104508.GC77589@lo0.su> References: <5133D56D.2070402@webmaster.spb.ru> <20130304072421.GA77589@lo0.su> <51346852.1040400@webmaster.spb.ru> <20130304104508.GC77589@lo0.su> Message-ID: <51348CF5.3000605@webmaster.spb.ru> 04.03.2013 14:45, Ruslan Ermilov пишет: > Как вариант, можно определить отдельный URI для 302, который > будет представлен статическим файлом, и задать желаемое ограничение > там: > > http { > limit_req_zone $server_name zone=lreq:10m rate=1r/m; > > server { > server_name test; > > location = /redir.php { > error_page 302 /302.html; > return http://ext-site.ru/content; > } > > location = /302.html { > internal; > limit_req zone=lreq burst=1; > } > } > } > > (Что положить внутрь файла 302.html - дело вкуса.) Не совсем понимаю логику. Пришел запрос, получил новый URI, при этом попал в секцию 302, где... Как будет перехватываться тогда 503 при превышении лимита и что происходит с URI в этой секции? Как-то не очевидно всё ( From mdounin at mdounin.ru Mon Mar 4 12:04:27 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 4 Mar 2013 16:04:27 +0400 Subject: =?UTF-8?B?UmU6INCT0LTQtSDQu9GD0YfRiNC1INCy0YHQtdCz0L4g0YXRgNCw0L3QuNGC0Ywg?= =?UTF-8?B?0YHQvtGB0YLQvtGP0L3QuNC1INC80L7QtNGD0LvRjz8=?= In-Reply-To: <1114475269.20130304082900@gmail.com> References: <1114475269.20130304082900@gmail.com> Message-ID: <20130304120427.GK15378@mdounin.ru> Hello! On Mon, Mar 04, 2013 at 08:29:00AM +0400, Sergey Zhemzhitsky wrote: > Привет, Nginx Гуру > > Модули к nginx никогда не разрабатывал, поэтому не пинайте сильно. > > Я пытаюсь написать nginx http-модуль к сторонней системе у которой есть С API. > Под этим API лежит в том чесле и установка TCP/IP соединения. > > Насколько я понял, правильным способом подключения к сторонней системе была бы разработка unstream http модуля. > Проблема в том, что протокол довольно сложный и в условиях ограниченного времени разбираться с ним некогда, > поэтому хотелось бы попользовать API, которое предоставляет система. > > Посоветуйте, плиз, по следующим вопросам > > 1. Где лучше всего хранить объекты, которые должны быть созданы и инициализированы только один раз для куска конфигурации > server или http? > 2. Где лучше всего создавать объекты, которые должны присутствовать единожды для конфигурации server или http (например, > устанавливать соединение со сторонней системой)? > 3. Насколько я понял под upstream-ами *всегда* лежит асинхронное сокетное api. Верно? > 4. Насколько плохо работать напрямую со своими TPC/IP соединениями прямо из request handler-ов? In no particular order: 1. Конфигурацию модуля, а также глобальные сущности с ней связанные - правильнее всего хранить в, как это ни странно, конфиге модуля. Надо, однако, иметь ввиду, что конфиг создаётся в master-процессе, а потом при fork()'е наследуется в worker'ов. Так что если вы там, e.g., хотите создавать постоянные соединения с бекендом - то делать это надо уже после старта рабочих процессов в них самих, а не при чтении конфига. 2. Таки да, nginx - event-based сервер, и для работы со всем чем можно - используются event-based API. 3. Upstream - это точно такой же модуль, как и все остальные. Если вы хотите написать свой модуль, аналогичный upstream'у, я бы рекомендовал для начала посмотреть на upstream. 4. Работать с сокетами из request handler'ов - не плохо. Работать с ними в блокирующемся режиме - плохая идея. -- Maxim Dounin http://nginx.org/en/donation.html From denis at webmaster.spb.ru Mon Mar 4 12:55:44 2013 From: denis at webmaster.spb.ru (denis) Date: Mon, 04 Mar 2013 16:55:44 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgNCw0LHQsNGC0YvQstCw0LXRgiBsaW1pdF9jb25uINC4IGxp?= =?UTF-8?B?bWl0X3JlcT8=?= In-Reply-To: <20130304104508.GC77589@lo0.su> References: <5133D56D.2070402@webmaster.spb.ru> <20130304072421.GA77589@lo0.su> <51346852.1040400@webmaster.spb.ru> <20130304104508.GC77589@lo0.su> Message-ID: <513499D0.3020202@webmaster.spb.ru> 04.03.2013 14:45, Ruslan Ermilov пишет: > Как вариант, можно определить отдельный URI для 302, который > будет представлен статическим файлом, и задать желаемое ограничение > там: В Вашем варианте на php файл почему-то отдавало его содержание вместо выполнения. Что получилось в итоге: limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn_zone $server_name zone=perserver:10m; limit_req_zone $server_name zone=lreq:10m rate=1r/s; location = /redir.php { error_page 302 /error.php; recursive_error_pages on; return http://ext-site.ru/content; } location = /error.php { internal; limit_req zone=lreq burst=1; error_page 503 =302 https://ext-site.ru/sorry.php; } хотя странно, что хотело наличие этого error.php на диске, но в таком варианте редирект и наружу работает. Проверка через ab -k -v 2 -c 10 -n 100 site.ru/redir.php|grep Location|sort|uniq -c показало, что всё норм. Спасибо за помощь! From vinny13 at land.ru Mon Mar 4 13:06:08 2013 From: vinny13 at land.ru (vinny13 at land.ru) Date: Mon, 04 Mar 2013 17:06:08 +0400 Subject: =?UTF-8?B?0LvQvtCz0LjQutCwIGZhaWxfdGltZW91dCDQsiDQsNC/0YHRgtGA0LjQvNC1Lg==?= Message-ID: <8b5f08f291b5afec080c44a3f7775ba6a7333f5d@mail.qip.ru> Здравствуйте. Имеется слудующий апстрим: upstream web1 { server 10.10.10.1 fail_timeout=180; server 10.10.10.2; }Т.е. насколько я понимаю, при возникновении хотя бы одного таймаута за 180 секунд, сервер должен "выбывать" из апстрима на те же 180 секунд. Но, судя по tcpdump'у на бекенде, этого не происходит - запросы идут с той же интенсивностью. Собственно либо я неправильно понимаю логику работы fail_timeout,либо что-то не так делаю - проясните ситуацию пожалуйста. в nginx.conf во все location с proxy_pass инклудится proxy.conf в котором: proxy_connect_timeout 1;proxy_send_timeout 3;proxy_read_timeout 3; proxy_next_upstream error timeout invalid_header http_500 http_503; -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Mon Mar 4 13:15:19 2013 From: nginx-forum at nginx.us (anon) Date: Mon, 04 Mar 2013 08:15:19 -0500 Subject: =?UTF-8?B?UmU6INCh0L3QvtCy0LAg0L4gNDAw?= In-Reply-To: <1559754624.20130302203103@mtu-net.ru> References: <1559754624.20130302203103@mtu-net.ru> Message-ID: <91978239a746986ab1d09644d02a3f49.NginxMailingListRussian@forum.nginx.org> В это же время с этих IP только реквесты с 400 и 408 кодами. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236787,236907#msg-236907 From andrei.seredenko at gmail.com Mon Mar 4 13:30:50 2013 From: andrei.seredenko at gmail.com (=?KOI8-R?B?4c7E0sXKIPPF0sXExc7Lzw==?=) Date: Mon, 4 Mar 2013 16:30:50 +0300 Subject: upstream && if Message-ID: Доброго времени суток всем подписчикам! Подскажите, возможно ли нечто этакое: Использую proxy_pass, для примера: upstream some_proxy { server SERV_NAME_1:8080; server SERV_NAME_2:8080 backup; } в локейшене анализирую урел на предмет наличия определенного параметра: /some/url/.....?param=SERV_NAME_x Задача в том, чтобы отдавать запрашиваемый файлик (имя передается в том же в урле) при встрече такого параметра с машины SERV_NAME_x, и не проксировался на вторую машину. Хотел попробовать в upstream вписать if проверки, а-ля: if ($args ~* (.*) param=SERV_NAME_1 (.+)) { * server SERV_NAME_1:8080;* } аналогично для serv_name_2. Но в upstream, насколько я понял, нельзя использовать директиву if. Подскажите, есть ли какое-то более-менее стандартное решение этого вопроса, или же надо искать в другой степи? Спасибо. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Mon Mar 4 13:37:28 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 4 Mar 2013 17:37:28 +0400 Subject: =?UTF-8?B?UmU6INC70L7Qs9C40LrQsCBmYWlsX3RpbWVvdXQg0LIg0LDQv9GB0YLRgNC40Lw=?= =?UTF-8?B?0LUu?= In-Reply-To: <8b5f08f291b5afec080c44a3f7775ba6a7333f5d@mail.qip.ru> References: <8b5f08f291b5afec080c44a3f7775ba6a7333f5d@mail.qip.ru> Message-ID: <20130304133728.GN15378@mdounin.ru> Hello! On Mon, Mar 04, 2013 at 05:06:08PM +0400, vinny13 at land.ru wrote: > Здравствуйте. > > Имеется слудующий апстрим: > upstream web1 { server 10.10.10.1 fail_timeout=180; server 10.10.10.2; }Т.е. насколько я понимаю, при возникновении хотя бы одного таймаута за 180 секунд, сервер должен "выбывать" из апстрима на те же 180 секунд. Но, судя по tcpdump'у на бекенде, этого не происходит - запросы идут с той же интенсивностью. Собственно либо я неправильно понимаю логику работы fail_timeout,либо что-то не так делаю - проясните ситуацию пожалуйста. > в nginx.conf во все location с proxy_pass инклудится proxy.conf в котором: > proxy_connect_timeout 1;proxy_send_timeout 3;proxy_read_timeout 3; proxy_next_upstream error timeout invalid_header http_500 http_503; (Во первых строках попрошу - отключите, пожалуйста, html в вашем почтовом клиенте. То, что он пытается выдавать за plain text вариант - текстом можно считать только с очень большой натяжкой, и читать можно с трудом.) Подозреваю, что в логе nginx'а должны быть регулярные сообщения "no live upstreams". Это означает, что все сервера в соответствии с max_fails/fail_timeout оказались признаны неработающими. В этом случае счётчики ошибок сбрасываются, и дальше nginx пытается ходить на то, что есть - в надежде, что кто-то из бекендов поднялся. -- Maxim Dounin http://nginx.org/en/donation.html From andrey at kopeyko.ru Mon Mar 4 16:49:33 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Mon, 04 Mar 2013 20:49:33 +0400 Subject: =?UTF-8?B?UmU6INCh0L3QvtCy0LAg0L4gNDAw?= In-Reply-To: <6c6dfa2d0bc476041733cb5dc3e37f95.NginxMailingListRussian@forum.nginx.org> References: <5130C2E3.5030500@kopeyko.ru> <6c6dfa2d0bc476041733cb5dc3e37f95.NginxMailingListRussian@forum.nginx.org> Message-ID: <5134D09D.9070904@kopeyko.ru> 02.03.2013 17:15, anon пишет: > в log_format есть UA, но к сожалению эти реквесты без него. Ну, разумеется - запроса же не было задано никакого, откуда ж полю User-Agent взяться? -- Best regards, Andrey Kopeyko From andrey at kopeyko.ru Mon Mar 4 16:51:34 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Mon, 04 Mar 2013 20:51:34 +0400 Subject: =?UTF-8?B?UmU6INCh0L3QvtCy0LAg0L4gNDAw?= In-Reply-To: <91978239a746986ab1d09644d02a3f49.NginxMailingListRussian@forum.nginx.org> References: <1559754624.20130302203103@mtu-net.ru> <91978239a746986ab1d09644d02a3f49.NginxMailingListRussian@forum.nginx.org> Message-ID: <5134D116.5010307@kopeyko.ru> 04.03.2013 17:15, anon пишет: > В это же время с этих IP только реквесты с 400 и 408 кодами. Я начинаю подозревать, что ваш проблемый server - описан как "default", и потому собирает в свои логи весь мусор со всех прочих виртуальных серверов. > -- Best regards, Andrey Kopeyko From nginx-forum at nginx.us Mon Mar 4 17:44:23 2013 From: nginx-forum at nginx.us (anon) Date: Mon, 04 Mar 2013 12:44:23 -0500 Subject: =?UTF-8?B?UmU6INCh0L3QvtCy0LAg0L4gNDAw?= In-Reply-To: <5134D09D.9070904@kopeyko.ru> References: <5134D09D.9070904@kopeyko.ru> Message-ID: <2e1b31f600adaee50978250b09caa126.NginxMailingListRussian@forum.nginx.org> Andrey Kopeyko Wrote: ------------------------------------------------------- > 04.03.2013 17:15, anon пишет: > > В это же время с этих IP только реквесты с 400 и 408 кодами. > > Я начинаю подозревать, что ваш проблемый server - описан как > "default", > и потому собирает в свои логи весь мусор со всех прочих виртуальных > серверов. > > > > > > -- > Best regards, > Andrey Kopeyko > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Нет, не описан как default. Более того я специально подправил его до вида , но ситуация не изменилась. server { listen *:80 default; server_name _ ""; return 444; } Сегодня с вероятностью в 99% определил, что эту гадость шлет наш браузерный плагин. Поэтому думаю пока проблему буду решать уже с фронтедщиками. Спасибо за помощь. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236787,236919#msg-236919 From hell-for-yahoo at umail.ru Mon Mar 4 18:23:48 2013 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Mon, 4 Mar 2013 22:23:48 +0400 Subject: upstream && if In-Reply-To: References: Message-ID: <638612583.20130304222348@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Андрей Середенко! АС> Доброго времени суток всем подписчикам! АС> Подскажите, возможно ли нечто этакое: АС> Использую proxy_pass, для примера: АС> upstream some_proxy { АС> server SERV_NAME_1:8080; АС> server SERV_NAME_2:8080 backup; АС> } АС> в локейшене анализирую урел на предмет наличия определенного параметра: АС> /some/url/.....?param=SERV_NAME_x АС> Задача в том, чтобы отдавать запрашиваемый файлик (имя передается в том же АС> в урле) при встрече такого параметра с машины SERV_NAME_x, и не АС> проксировался на вторую машину. Хотел попробовать в upstream вписать if АС> проверки, а-ля: Что мешает прописать ещё два апстрима, по одному на конкретный сервер? И при необходимости отдавать с них. АС> if ($args ~* (.*) param=SERV_NAME_1 (.+)) { АС> * server SERV_NAME_1:8080;* АС> } АС> аналогично для serv_name_2. Но в upstream, насколько я понял, нельзя АС> использовать директиву if. Подскажите, есть ли какое-то более-менее АС> стандартное решение этого вопроса, или же надо искать в другой степи? АС> Спасибо. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) понедельник, 04.03.2013, <22:23> From szh.subs at gmail.com Mon Mar 4 18:41:47 2013 From: szh.subs at gmail.com (Sergey Zhemzhitsky) Date: Mon, 4 Mar 2013 22:41:47 +0400 Subject: =?UTF-8?B?UmU6INCT0LTQtSDQu9GD0YfRiNC1INCy0YHQtdCz0L4g0YXRgNCw0L3QuNGC0Ywg?= =?UTF-8?B?0YHQvtGB0YLQvtGP0L3QuNC1INC80L7QtNGD0LvRjz8=?= In-Reply-To: <20130304120427.GK15378@mdounin.ru> References: <1114475269.20130304082900@gmail.com> <20130304120427.GK15378@mdounin.ru> Message-ID: <1852926279.20130304224147@gmail.com> Максим, большое спасибо за комментарии! > Так что если вы там, e.g., хотите создавать постоянные соединения с бекендом - то > делать это надо уже после старта рабочих процессов в них самих, а не при чтении конфига. А не подскажете, где лучше всего это делать. Насколько я понял по исходникам, все callback-и модуля выполняются именно master-процессом. > Hello! > On Mon, Mar 04, 2013 at 08:29:00AM +0400, Sergey Zhemzhitsky wrote: >> Привет, Nginx Гуру >> >> Модули к nginx никогда не разрабатывал, поэтому не пинайте сильно. >> >> Я пытаюсь написать nginx http-модуль к сторонней системе у которой есть С API. >> Под этим API лежит в том чесле и установка TCP/IP соединения. >> >> Насколько я понял, правильным способом подключения к сторонней системе была бы разработка unstream http модуля. >> Проблема в том, что протокол довольно сложный и в условиях ограниченного времени разбираться с ним некогда, >> поэтому хотелось бы попользовать API, которое предоставляет система. >> >> Посоветуйте, плиз, по следующим вопросам >> >> 1. Где лучше всего хранить объекты, которые должны быть созданы и инициализированы только один раз для куска конфигурации >> server или http? >> 2. Где лучше всего создавать объекты, которые должны присутствовать единожды для конфигурации server или http (например, >> устанавливать соединение со сторонней системой)? >> 3. Насколько я понял под upstream-ами *всегда* лежит асинхронное сокетное api. Верно? >> 4. Насколько плохо работать напрямую со своими TPC/IP соединениями прямо из request handler-ов? > In no particular order: > 1. Конфигурацию модуля, а также глобальные сущности с ней связанные - > правильнее всего хранить в, как это ни странно, конфиге модуля. > Надо, однако, иметь ввиду, что конфиг создаётся в master-процессе, > а потом при fork()'е наследуется в worker'ов. Так что если вы > там, e.g., хотите создавать постоянные соединения с бекендом - то > делать это надо уже после старта рабочих процессов в них самих, а > не при чтении конфига. > 2. Таки да, nginx - event-based сервер, и для работы со всем чем > можно - используются event-based API. > 3. Upstream - это точно такой же модуль, как и все остальные. > Если вы хотите написать свой модуль, аналогичный upstream'у, я бы > рекомендовал для начала посмотреть на upstream. > 4. Работать с сокетами из request handler'ов - не плохо. Работать > с ними в блокирующемся режиме - плохая идея. From szh.subs at gmail.com Mon Mar 4 19:45:10 2013 From: szh.subs at gmail.com (Sergey Zhemzhitsky) Date: Mon, 4 Mar 2013 23:45:10 +0400 Subject: =?UTF-8?B?UmU6INCT0LTQtSDQu9GD0YfRiNC1INCy0YHQtdCz0L4g0YXRgNCw0L3QuNGC0Ywg?= =?UTF-8?B?0YHQvtGB0YLQvtGP0L3QuNC1INC80L7QtNGD0LvRjz8=?= In-Reply-To: <20130304120427.GK15378@mdounin.ru> References: <1114475269.20130304082900@gmail.com> <20130304120427.GK15378@mdounin.ru> Message-ID: <1607344244.20130304234510@gmail.com> Максим, большое спасибо за комментарии! > Так что если вы там, e.g., хотите создавать постоянные соединения с бекендом - то > делать это надо уже после старта рабочих процессов в них самих, а не при чтении конфига. А не подскажете, где лучше всего это делать. По исходникам и экспериментам, похоже, что callback init_process срабатывает как раз внутри воркера. > Hello! > On Mon, Mar 04, 2013 at 08:29:00AM +0400, Sergey Zhemzhitsky wrote: >> Привет, Nginx Гуру >> >> Модули к nginx никогда не разрабатывал, поэтому не пинайте сильно. >> >> Я пытаюсь написать nginx http-модуль к сторонней системе у которой есть С API. >> Под этим API лежит в том чесле и установка TCP/IP соединения. >> >> Насколько я понял, правильным способом подключения к сторонней системе была бы разработка unstream http модуля. >> Проблема в том, что протокол довольно сложный и в условиях ограниченного времени разбираться с ним некогда, >> поэтому хотелось бы попользовать API, которое предоставляет система. >> >> Посоветуйте, плиз, по следующим вопросам >> >> 1. Где лучше всего хранить объекты, которые должны быть созданы и инициализированы только один раз для куска конфигурации >> server или http? >> 2. Где лучше всего создавать объекты, которые должны присутствовать единожды для конфигурации server или http (например, >> устанавливать соединение со сторонней системой)? >> 3. Насколько я понял под upstream-ами *всегда* лежит асинхронное сокетное api. Верно? >> 4. Насколько плохо работать напрямую со своими TPC/IP соединениями прямо из request handler-ов? > In no particular order: > 1. Конфигурацию модуля, а также глобальные сущности с ней связанные - > правильнее всего хранить в, как это ни странно, конфиге модуля. > Надо, однако, иметь ввиду, что конфиг создаётся в master-процессе, > а потом при fork()'е наследуется в worker'ов. Так что если вы > там, e.g., хотите создавать постоянные соединения с бекендом - то > делать это надо уже после старта рабочих процессов в них самих, а > не при чтении конфига. > 2. Таки да, nginx - event-based сервер, и для работы со всем чем > можно - используются event-based API. > 3. Upstream - это точно такой же модуль, как и все остальные. > Если вы хотите написать свой модуль, аналогичный upstream'у, я бы > рекомендовал для начала посмотреть на upstream. > 4. Работать с сокетами из request handler'ов - не плохо. Работать > с ними в блокирующемся режиме - плохая идея. -- Best regards, Sergey mailto:szh.subs at gmail.com From szh.subs at gmail.com Mon Mar 4 21:59:52 2013 From: szh.subs at gmail.com (Sergey Zhemzhitsky) Date: Tue, 5 Mar 2013 01:59:52 +0400 Subject: =?UTF-8?B?UmU6INCT0LTQtSDQu9GD0YfRiNC1INCy0YHQtdCz0L4g0YXRgNCw0L3QuNGC0Ywg?= =?UTF-8?B?0YHQvtGB0YLQvtGP0L3QuNC1INC80L7QtNGD0LvRjz8=?= In-Reply-To: <1607344244.20130304234510@gmail.com> References: <1114475269.20130304082900@gmail.com> <20130304120427.GK15378@mdounin.ru> <1607344244.20130304234510@gmail.com> Message-ID: <982917648.20130305015952@gmail.com> Так, вроде бы разобрался. init_process действительно то, что нужно. Спасибо! > Максим, большое спасибо за комментарии! >> Так что если вы там, e.g., хотите создавать постоянные соединения с бекендом - то >> делать это надо уже после старта рабочих процессов в них самих, а не при чтении конфига. > А не подскажете, где лучше всего это делать. > По исходникам и экспериментам, похоже, что callback init_process > срабатывает как раз внутри воркера. >> Hello! >> On Mon, Mar 04, 2013 at 08:29:00AM +0400, Sergey Zhemzhitsky wrote: >>> Привет, Nginx Гуру >>> >>> Модули к nginx никогда не разрабатывал, поэтому не пинайте сильно. >>> >>> Я пытаюсь написать nginx http-модуль к сторонней системе у которой есть С API. >>> Под этим API лежит в том чесле и установка TCP/IP соединения. >>> >>> Насколько я понял, правильным способом подключения к сторонней системе была бы разработка unstream http модуля. >>> Проблема в том, что протокол довольно сложный и в условиях ограниченного времени разбираться с ним некогда, >>> поэтому хотелось бы попользовать API, которое предоставляет система. >>> >>> Посоветуйте, плиз, по следующим вопросам >>> >>> 1. Где лучше всего хранить объекты, которые должны быть созданы и инициализированы только один раз для куска конфигурации >>> server или http? >>> 2. Где лучше всего создавать объекты, которые должны присутствовать единожды для конфигурации server или http (например, >>> устанавливать соединение со сторонней системой)? >>> 3. Насколько я понял под upstream-ами *всегда* лежит асинхронное сокетное api. Верно? >>> 4. Насколько плохо работать напрямую со своими TPC/IP соединениями прямо из request handler-ов? >> In no particular order: >> 1. Конфигурацию модуля, а также глобальные сущности с ней связанные - >> правильнее всего хранить в, как это ни странно, конфиге модуля. >> Надо, однако, иметь ввиду, что конфиг создаётся в master-процессе, >> а потом при fork()'е наследуется в worker'ов. Так что если вы >> там, e.g., хотите создавать постоянные соединения с бекендом - то >> делать это надо уже после старта рабочих процессов в них самих, а >> не при чтении конфига. >> 2. Таки да, nginx - event-based сервер, и для работы со всем чем >> можно - используются event-based API. >> 3. Upstream - это точно такой же модуль, как и все остальные. >> Если вы хотите написать свой модуль, аналогичный upstream'у, я бы >> рекомендовал для начала посмотреть на upstream. >> 4. Работать с сокетами из request handler'ов - не плохо. Работать >> с ними в блокирующемся режиме - плохая идея. From chipitsine at gmail.com Tue Mar 5 01:59:14 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 5 Mar 2013 06:59:14 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQutCwINC/0LXRgNC10LrRgNGL0YLRjCDQtNC+0YHRgtGD0L8g0Log?= =?UTF-8?B?0LvRjtCx0YvQvCDRhNCw0LnQu9Cw0Lwg0Lgg0LTQuNGA0LXQutGC0L7RgNC4?= =?UTF-8?B?0Y/QvCAo0YTRgNC10LnQvNCy0L7RgNC6KSDQvdCwINC00LjRgdC60LU/?= In-Reply-To: <8b0843b73d8b36bc3ef97ec3aca93b57.NginxMailingListRussian@forum.nginx.org> References: <8b0843b73d8b36bc3ef97ec3aca93b57.NginxMailingListRussian@forum.nginx.org> Message-ID: Фреймворк, наверное, умеет делать include (или require) из любой папки, настройте его и оставьте в папке сайта только index.php 28.02.2013 22:45 пользователь "ShivaS" написал: > Всем добрый вечер, > > Запускается важный сайт (фреймворк), для которого соотв. прописано: > try_files $uri $uri/ /index.php; (можно и try files "" /index.php;) > > Нужно перекрыть доступ ко всем имеющимся на сервере (физически) файлам и > папкам > Хочется по науке и без -f $request_filename (и -d соотв), no видимо никак > не > обойтись > > Может кто-то подскажет возможно ли так сделать? > > Одна из идей была проверять на наличие реферера , но тоже упирается в if > > Спасибо! > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,236726,236726#msg-236726 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinny13 at land.ru Tue Mar 5 08:27:50 2013 From: vinny13 at land.ru (vinny13 at land.ru) Date: Tue, 05 Mar 2013 12:27:50 +0400 Subject: =?UTF-8?B?UmU6INC70L7Qs9C40LrQsCBmYWlsIHRpbWVvdXQg0LLCrcKtINCw0L/RgdGC0YA=?= =?UTF-8?B?0LjQvNC1Lg==?= In-Reply-To: <090c742400aa3fe292baf86435b0de8d3b9646fe@mail.qip.ru> References: <090c742400aa3fe292baf86435b0de8d3b9646fe@mail.qip.ru> Message-ID: <1cacd0dcc010bc173881a8d21633b29467f51b68@mail.qip.ru> В том-то и дело что в логе проскакивает только upstream timed out (60: Operation timed out) while connecting to upstream, и всё дальше работает как ни в чём не бывало.. no live upstreams появляется только когда действительно нет живых бекендов . > > Здравствуйте. > > > > Имеется слудующий апстрим: > > upstream web1 { > > server 10.10.10.1 fail_timeout=180; > > server 10.10.10.2; > > } > > > > Т.е. насколько я понимаю, при возникновении хотя бы одного таймаута за 180 секунд, сервер должен "выбывать" из апстрима на те же 180 > > секунд. Но, судя по tcpdump'у на бекенде, этого не происходит - запросы идут с той же интенсивностью. Собственно либо я неправильно > > понимаю логику работы fail_timeout,либо что-то не так делаю - проясните ситуацию пожалуйста. > > > > в nginx.conf во все location с proxy_pass инклудится proxy.conf в котором: > > proxy_connect_timeout 1; > > proxy_send_timeout 3; > > proxy_read_timeout 3; proxy_next_upstream error timeout invalid_header http_500 http_503; > > (Во первых строках попрошу - отключите, пожалуйста, html в вашем > почтовом клиенте. То, что он пытается выдавать за plain text > вариант - текстом можно считать только с очень большой натяжкой, > и читать можно с трудом.) > > Подозреваю, что в логе nginx'а должны быть регулярные сообщения > "no live upstreams". Это означает, что все сервера в соответствии > с max_fails/fail_timeout оказались признаны неработающими. В этом > случае счётчики ошибок сбрасываются, и дальше nginx пытается > ходить на то, что есть - в надежде, что кто-то из бекендов > поднялся. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----- Конец пересылаемого письма ----- From vinny13 at land.ru Tue Mar 5 08:29:36 2013 From: vinny13 at land.ru (vinny13 at land.ru) Date: Tue, 05 Mar 2013 12:29:36 +0400 Subject: =?UTF-8?B?UmU6INC70L7Qs9C40LrQsCBmYWlsIHRpbWVvdXQg0LLCrcKtwq0g0LDQv9GB0YI=?= =?UTF-8?B?0YDQuNC80LUu?= In-Reply-To: References: Message-ID: Да, т.к. это синтетические тесты, то единичные случаи, но в "реале" хотелось бы что бы при определённом соотношении max_fail/fail_timeout сервер полностью выключался на время из апстрима. Ваша фраза о том, что состояние upstream-серверов - для каждого рабочего процесса своё, подтвердила мои подозрения... Тогда получается, что добиться желаемого поведения можно либо запустив nginx с одним воркером, либо городить костыли, которые как-то из вне мониторят состояние серверов в апстриме и управляют балансировкой запросов на них ? P.S. Забегая вперёд спрошу следующее - как выбирается какой из воркеров будет обрабатывать поступивший HTTP запрос ? > "Проскакивает" - смысле единичные записи? А рабочих процессов при > этом сколько? На всякий случай обращаю внимание, что состояние > upstream-серверов - для каждого рабочего процесса своё, и не следует > ожидать полного прекращения отправки запросов на бекенд из-за > одной ошибки. > > -- > Maxim Dounin > http://nginx.org/en/donation.html ----- Конец пересылаемого письма ----- From vinny13 at land.ru Tue Mar 5 08:31:34 2013 From: vinny13 at land.ru (vinny13 at land.ru) Date: Tue, 05 Mar 2013 12:31:34 +0400 Subject: =?UTF-8?B?UmU6INC70L7Qs9C40LrQsCBmYWlsX3RpbWVvdXQg0LLCrcKtwq0g0LDQv9GB0YI=?= =?UTF-8?B?0YDQuNC80LUu?= In-Reply-To: <20130304160614.GS15378@mdounin.ru> References: <20130304160614.GS15378@mdounin.ru> Message-ID: > Да, т.к. это синтетические тесты, то единичные случаи, но в "реале" хотелось бы > что бы при определённом соотношении max_fail/fail_timeout сервер полностью > выключался на время из апстрима. > > Ваша фраза о том, что состояние upstream-серверов - для каждого рабочего процесса своё, > подтвердила мои подозрения... > Тогда получается, что добиться желаемого поведения можно либо запустив nginx > с одним воркером, либо городить костыли, которые как-то из вне мониторят > состояние серверов в апстриме и управляют балансировкой запросов на них ? А в чём смысл? Если на бекенде проблемы - то все рабочие процессы рано или поздно об этом узнают. > P.S. Забегая вперёд спрошу следующее - как выбирается какой из воркеров будет > обрабатывать поступивший HTTP запрос ? Никак - какому рабочему процессу повезло получить соединение из ядра, тот и будет обрабатывать запросы в данном соединении. Есть директива accept_mutex (http://nginx.org/r/accept_mutex/ru), которая слегка влияет на это "повезло", но она, опять же, никакого выбора не обеспечивает. -- Maxim Dounin http://nginx.org/en/donation.html ----- Конец пересылаемого письма ----- From vinny13 at land.ru Tue Mar 5 08:32:30 2013 From: vinny13 at land.ru (vinny13 at land.ru) Date: Tue, 05 Mar 2013 12:32:30 +0400 Subject: =?UTF-8?B?UmU6INC70L7Qs9C40LrQsCBmYWlsIHRpbWVvwq11dCDQssKtwq3CrSDQsNC/0YE=?= =?UTF-8?B?0YLRgNC40LzQtS4=?= In-Reply-To: <0317afa774fc407458dfafc23f3004690e785b89@mail.qip.ru> References: <0317afa774fc407458dfafc23f3004690e785b89@mail.qip.ru> Message-ID: <36232654d1ec9790286a0444d4d87c9fa74e1aee@mail.qip.ru> > > А в чём смысл? Если на бекенде проблемы - то все рабочие процессы > рано или поздно об этом узнают. > Смысл в следующем. Приложение-бекенд очень медленное и нестабильное - для его работы приходиться выставлять timeout'ы в 30-50 секунд. В дополнение к этому итоговая страница, которая отдаётся браузеру, собирается со всего апстрима, причём последовательно. Т.е. при проблемах на одном бекенде конечные страницы всех клиентов начинают собираться в рамках этих 30-50 секунд умноженных на число запросов попавших на проблемный бекенд, что делает систему практически неработоспособной. Переписать\улучшить приложение в обозримом будущем ресурсов нет. Если же при первых симптомах "отстреливать" проблемный бекенд то, _теоретически_, это должно улучшить ситуацию. Есть ещё одна мысль - все запросы в рамках одной сессии ( сессия здесь - сборка конечной страницы ), перенаправлять на один бекенд, однозначно выбираемый из апстрима в соответствии с некоторым кастомным HTTP заголовком, но как это реализовать в nginx я пока не изучал - возможно Вы мне подскажете направление в котором двигаться :) From vinny13 at land.ru Tue Mar 5 08:33:01 2013 From: vinny13 at land.ru (vinny13 at land.ru) Date: Tue, 05 Mar 2013 12:33:01 +0400 Subject: =?UTF-8?B?UmU6INC70L7Qs9C40LrQsCBmYWlsIHRpbWVvwq11dCDQssKtwq3CrSDQsNC/0YE=?= =?UTF-8?B?0YLRgNC40LzQtS4=?= In-Reply-To: <36a1de22715b2b9b041b5f09416f1de81c8a23f6@mail.qip.ru> References: <36a1de22715b2b9b041b5f09416f1de81c8a23f6@mail.qip.ru> Message-ID: <394f77ba2e9692350d18a1996b6c8045a4ce7c3d@mail.qip.ru> > Никак - какому рабочему процессу повезло получить соединение из > ядра, тот и будет обрабатывать запросы в данном соединении. > Тогда в моём случае получается, что чем меньше воркеров, тем быстрее и менее безболезненно для клиента "весь" nginx "узнает" о проблемном бекенде и перестанет посылать на него запросы. From onokonem at gmail.com Tue Mar 5 09:07:06 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Tue, 5 Mar 2013 12:07:06 +0300 Subject: =?UTF-8?B?UmU6INC70L7Qs9C40LrQsCBmYWlsIHRpbWVvdXQg0LIg0LDQv9GB0YLRgNC40Lw=?= =?UTF-8?B?0LUu?= In-Reply-To: <394f77ba2e9692350d18a1996b6c8045a4ce7c3d@mail.qip.ru> References: <36a1de22715b2b9b041b5f09416f1de81c8a23f6@mail.qip.ru> <394f77ba2e9692350d18a1996b6c8045a4ce7c3d@mail.qip.ru> Message-ID: > Тогда в моём случае получается, что чем меньше воркеров, тем быстрее > и менее безболезненно для клиента "весь" nginx "узнает" о проблемном > бекенде и перестанет посылать на него запросы. Когда-то давно я задавал Игорю вопрос - есть ли смысл делать больше одного воркера, если они только проксируют. И получил однозначный ответ - смысла нет. From gmm at csdoc.com Tue Mar 5 10:36:17 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Tue, 05 Mar 2013 12:36:17 +0200 Subject: =?UTF-8?B?UmU6INC70L7Qs9C40LrQsCBmYWlsIHRpbWVvdXQg0LIg0LDQv9GB0YLRgNC40Lw=?= =?UTF-8?B?0LUu?= In-Reply-To: References: <36a1de22715b2b9b041b5f09416f1de81c8a23f6@mail.qip.ru> <394f77ba2e9692350d18a1996b6c8045a4ce7c3d@mail.qip.ru> Message-ID: <5135CAA1.5050504@csdoc.com> On 05.03.2013 11:07, Daniel Podolsky wrote: >> Тогда в моём случае получается, что чем меньше воркеров, тем быстрее >> и менее безболезненно для клиента "весь" nginx "узнает" о проблемном >> бекенде и перестанет посылать на него запросы. > Когда-то давно я задавал Игорю вопрос - есть ли смысл делать больше > одного воркера, если они только проксируют. И получил однозначный > ответ - смысла нет. ...только если не используется https. если используется https - смысл есть делать число воркеров равным числу физических ядер. и настроить ssl_session_cache, потому что по умолчанию это выключено. http://nginx.org/ru/docs/http/ngx_http_ssl_module.html -- Best regards, Gena From mdounin at mdounin.ru Tue Mar 5 14:56:13 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 5 Mar 2013 18:56:13 +0400 Subject: nginx-1.3.14 Message-ID: <20130305145613.GD15378@mdounin.ru> Изменения в nginx 1.3.14 05.03.2013 *) Добавление: переменные $connections_active, $connections_reading и $connections_writing в модуле ngx_http_stub_status_module. *) Добавление: поддержка WebSocket-соединений в модулях ngx_http_uwsgi_module и ngx_http_scgi_module. *) Исправление: в обработке виртуальных серверов при использовании SNI. *) Исправление: при использовании директивы "ssl_session_cache shared" новые сессии могли не сохраняться, если заканчивалось место в разделяемой памяти. Спасибо Piotr Sikora. *) Исправление: несколько заголовков X-Forwarded-For обрабатывались неправильно. Спасибо Neal Poole за спонсирование разработки. *) Исправление: в модуле ngx_http_mp4_module. Спасибо Gernot Vormayr. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Mar 6 11:27:39 2013 From: nginx-forum at nginx.us (krain) Date: Wed, 06 Mar 2013 06:27:39 -0500 Subject: =?UTF-8?B?cHJveHkgcGFzcyDRh9C10YDQtdC3IEhlYWRlcg==?= Message-ID: <2cb423f28d59fdd24622e80bfae6c4ad.NginxMailingListRussian@forum.nginx.org> nginx стоит балансировщиком и переадресует запросы скажем на группу серверов 192.168.0.1 192.168.0.2 192.168.0.2 через proxy_pass Например запрос перешел на 192.168.0.1, можно ли как-то вернуть в заголовке команду для балансировщика сменить upstream сервер с 192.168.0.1 на 192.168.0.2 или 192.168.0.3 (на тот, который укажет скрипт) Не передавая ничего в браузер пользователя (что-то вроде внутреннего редиректа, но на другой upstream сервер) Как я понял proxy_next_upstream не подходит. Задача в следующем: Если на сервере нет нужного файла, но скрипт определил где файл находится (после запроса к базе данных) и готов указать указать на каком сервере он лежит. Хочется чтобы балансировщик nginx переподключился к указанному серверу. Заранее спасибо за ответ. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236984,236984#msg-236984 From nginx-forum at nginx.us Wed Mar 6 11:57:22 2013 From: nginx-forum at nginx.us (arty777) Date: Wed, 06 Mar 2013 06:57:22 -0500 Subject: nginx-1.3.14 In-Reply-To: <20130305145613.GD15378@mdounin.ru> References: <20130305145613.GD15378@mdounin.ru> Message-ID: <19d858dc2f1879dd6890483f71c81b6e.NginxMailingListRussian@forum.nginx.org> Исправление: в модуле ngx_http_mp4_module. Что было? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236958,236985#msg-236985 From mdounin at mdounin.ru Wed Mar 6 12:31:32 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 6 Mar 2013 16:31:32 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5IHBhc3Mg0YfQtdGA0LXQtyBIZWFkZXI=?= In-Reply-To: <2cb423f28d59fdd24622e80bfae6c4ad.NginxMailingListRussian@forum.nginx.org> References: <2cb423f28d59fdd24622e80bfae6c4ad.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130306123132.GR15378@mdounin.ru> Hello! On Wed, Mar 06, 2013 at 06:27:39AM -0500, krain wrote: > nginx стоит балансировщиком и переадресует запросы скажем > на группу серверов > 192.168.0.1 > 192.168.0.2 > 192.168.0.2 > через proxy_pass > > Например запрос перешел на 192.168.0.1, можно ли как-то вернуть в заголовке > команду для балансировщика > сменить upstream сервер с 192.168.0.1 на 192.168.0.2 или 192.168.0.3 (на > тот, который укажет скрипт) > Не передавая ничего в браузер пользователя (что-то вроде внутреннего > редиректа, но на другой upstream сервер) > > Как я понял proxy_next_upstream не подходит. > > Задача в следующем: > Если на сервере нет нужного файла, но скрипт определил где файл находится > (после запроса к базе данных) и готов указать указать > на каком сервере он лежит. > Хочется чтобы балансировщик nginx переподключился к указанному серверу. > > Заранее спасибо за ответ. Логичным решением было бы вернуть X-Accel-Redirect в location, который в свою очередь проксируется на нужный сервер. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Wed Mar 6 13:05:52 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 6 Mar 2013 17:05:52 +0400 Subject: nginx-1.3.14 In-Reply-To: <19d858dc2f1879dd6890483f71c81b6e.NginxMailingListRussian@forum.nginx.org> References: <20130305145613.GD15378@mdounin.ru> <19d858dc2f1879dd6890483f71c81b6e.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130306130552.GW15378@mdounin.ru> Hello! On Wed, Mar 06, 2013 at 06:57:22AM -0500, arty777 wrote: > Исправление: в модуле ngx_http_mp4_module. > > Что было? Ничего серьёзного. http://trac.nginx.org/nginx/ticket/266 -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Mar 6 14:53:49 2013 From: nginx-forum at nginx.us (krain) Date: Wed, 06 Mar 2013 09:53:49 -0500 Subject: =?UTF-8?B?UmU6IHByb3h5IHBhc3Mg0YfQtdGA0LXQtyBIZWFkZXI=?= In-Reply-To: <20130306123132.GR15378@mdounin.ru> References: <20130306123132.GR15378@mdounin.ru> Message-ID: <0ee9f9c4c7314c13af6cc6e05c4bcf10.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > On Wed, Mar 06, 2013 at 06:27:39AM -0500, krain wrote: > > > nginx стоит балансировщиком и переадресует запросы скажем > > на группу серверов > > 192.168.0.1 > > 192.168.0.2 > > 192.168.0.2 > > через proxy_pass > > > > Например запрос перешел на 192.168.0.1, можно ли как-то вернуть в > заголовке > > команду для балансировщика > > сменить upstream сервер с 192.168.0.1 на 192.168.0.2 или 192.168.0.3 > (на > > тот, который укажет скрипт) > > Не передавая ничего в браузер пользователя (что-то вроде внутреннего > > редиректа, но на другой upstream сервер) > > > > Как я понял proxy_next_upstream не подходит. > > > > Задача в следующем: > > Если на сервере нет нужного файла, но скрипт определил где файл > находится > > (после запроса к базе данных) и готов указать указать > > на каком сервере он лежит. > > Хочется чтобы балансировщик nginx переподключился к указанному > серверу. > > > > Заранее спасибо за ответ. > > Логичным решением было бы вернуть X-Accel-Redirect в location, > который в свою очередь проксируется на нужный сервер. Вроде как "X-Accel-Redirect:" только локально работает? (http://kovyrin.net/2010/07/24/nginx-fu-x-accel-redirect-remote/) т.е. выдавая скриптом с сервера 192.168.0.1 ответ в header-е X-Accel-Redirect: http://192.168.0.2/a.html бэкенд до ответа посетителю должен переслать запрос к 192.168.0.2 и если все ок, то отдать нормальный ответ посетителю? Возможно ли так передать POST запрос? > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236991,237005#msg-237005 From nginx-forum at nginx.us Wed Mar 6 15:39:42 2013 From: nginx-forum at nginx.us (krain) Date: Wed, 06 Mar 2013 10:39:42 -0500 Subject: =?UTF-8?B?UmU6IHByb3h5IHBhc3Mg0YfQtdGA0LXQtyBIZWFkZXI=?= In-Reply-To: <0ee9f9c4c7314c13af6cc6e05c4bcf10.NginxMailingListRussian@forum.nginx.org> References: <20130306123132.GR15378@mdounin.ru> <0ee9f9c4c7314c13af6cc6e05c4bcf10.NginxMailingListRussian@forum.nginx.org> Message-ID: <6001ecf1ee63d8206c5a4f90d898345e.NginxMailingListRussian@forum.nginx.org> krain Wrote: ------------------------------------------------------- > Maxim Dounin Wrote: > ------------------------------------------------------- > > Hello! > > > > On Wed, Mar 06, 2013 at 06:27:39AM -0500, krain wrote: > > > > > nginx стоит балансировщиком и переадресует запросы скажем > > > на группу серверов > > > 192.168.0.1 > > > 192.168.0.2 > > > 192.168.0.2 > > > через proxy_pass > > > > > > Например запрос перешел на 192.168.0.1, можно ли как-то вернуть в > > заголовке > > > команду для балансировщика > > > сменить upstream сервер с 192.168.0.1 на 192.168.0.2 или > 192.168.0.3 > > (на > > > тот, который укажет скрипт) > > > Не передавая ничего в браузер пользователя (что-то вроде > внутреннего > > > редиректа, но на другой upstream сервер) > > > > > > Как я понял proxy_next_upstream не подходит. > > > > > > Задача в следующем: > > > Если на сервере нет нужного файла, но скрипт определил где файл > > находится > > > (после запроса к базе данных) и готов указать указать > > > на каком сервере он лежит. > > > Хочется чтобы балансировщик nginx переподключился к указанному > > серверу. > > > > > > Заранее спасибо за ответ. > > > > Логичным решением было бы вернуть X-Accel-Redirect в location, > > который в свою очередь проксируется на нужный сервер. > > Вроде как "X-Accel-Redirect:" только локально работает? > (http://kovyrin.net/2010/07/24/nginx-fu-x-accel-redirect-remote/) > > т.е. выдавая скриптом с сервера 192.168.0.1 ответ в header-е > > X-Accel-Redirect: http://192.168.0.2/a.html > бэкенд до ответа посетителю должен переслать запрос к > 192.168.0.2 > и если все ок, то отдать нормальный ответ посетителю? > > Возможно ли так передать POST запрос? так не работает!!! X-Accel-Redirect: http://192.168.0.2/a.html работает только для локальных файлов. > > > > > > > > > -- > > Maxim Dounin > > http://nginx.org/en/donation.html > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,236991,237009#msg-237009 From mdounin at mdounin.ru Wed Mar 6 15:40:03 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 6 Mar 2013 19:40:03 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5IHBhc3Mg0YfQtdGA0LXQtyBIZWFkZXI=?= In-Reply-To: <0ee9f9c4c7314c13af6cc6e05c4bcf10.NginxMailingListRussian@forum.nginx.org> References: <20130306123132.GR15378@mdounin.ru> <0ee9f9c4c7314c13af6cc6e05c4bcf10.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130306154002.GC15378@mdounin.ru> Hello! On Wed, Mar 06, 2013 at 09:53:49AM -0500, krain wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > Hello! > > > > On Wed, Mar 06, 2013 at 06:27:39AM -0500, krain wrote: > > > > > nginx стоит балансировщиком и переадресует запросы скажем > > > на группу серверов > > > 192.168.0.1 > > > 192.168.0.2 > > > 192.168.0.2 > > > через proxy_pass > > > > > > Например запрос перешел на 192.168.0.1, можно ли как-то вернуть в > > заголовке > > > команду для балансировщика > > > сменить upstream сервер с 192.168.0.1 на 192.168.0.2 или 192.168.0.3 > > (на > > > тот, который укажет скрипт) > > > Не передавая ничего в браузер пользователя (что-то вроде внутреннего > > > редиректа, но на другой upstream сервер) > > > > > > Как я понял proxy_next_upstream не подходит. > > > > > > Задача в следующем: > > > Если на сервере нет нужного файла, но скрипт определил где файл > > находится > > > (после запроса к базе данных) и готов указать указать > > > на каком сервере он лежит. > > > Хочется чтобы балансировщик nginx переподключился к указанному > > серверу. > > > > > > Заранее спасибо за ответ. > > > > Логичным решением было бы вернуть X-Accel-Redirect в location, > > который в свою очередь проксируется на нужный сервер. > > Вроде как "X-Accel-Redirect:" только локально работает? > (http://kovyrin.net/2010/07/24/nginx-fu-x-accel-redirect-remote/) X-Accel-Redirect вызывает внутреннее перенаправление в nginx'е, а как полученный URI обработать - это лишь вопрос конфигурации. > т.е. выдавая скриптом с сервера 192.168.0.1 ответ в header-е > > X-Accel-Redirect: http://192.168.0.2/a.html > бэкенд до ответа посетителю должен переслать запрос к > 192.168.0.2 > и если все ок, то отдать нормальный ответ посетителю? Нет. Нужно сделать как-то так: location / { proxy_pass http://all_backends; } location /files_on_server_1/ { proxy_pass http://server_1/; } location /files_on_server_2/ { proxy_pass http://server_2/; } И возвращать X-Accel-Redirect /files_on_server_1/a.html. > Возможно ли так передать POST запрос? Если очень хочется - то можно. Но вообще я бы не рекомендовал лишнего заниматься перенаправлениями POST-запросов. -- Maxim Dounin http://nginx.org/en/donation.html From anatoly at sonru.com Wed Mar 6 16:54:34 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 6 Mar 2013 16:54:34 +0000 Subject: =?UTF-8?B?UENSRSDQstC10YDRgdC40Y8=?= Message-ID: <7D286A1D-D70F-4552-93E2-3CFE1EA9600C@sonru.com> добрый день, Какая версия PCRE совместимы с Nginx 1.3.12+? В Wiki сказано PCRE "version 4.4 ? 8.21", но я давно устанавливаю 8.30 - все совместимо. Но уже доступна 8.32 (http://www.pcre.org/changelog.txt), стоит пробовать? Анатолий From chipitsine at gmail.com Wed Mar 6 17:52:28 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 6 Mar 2013 22:52:28 +0500 Subject: =?UTF-8?B?UmU6IFBDUkUg0LLQtdGA0YHQuNGP?= In-Reply-To: <7D286A1D-D70F-4552-93E2-3CFE1EA9600C@sonru.com> References: <7D286A1D-D70F-4552-93E2-3CFE1EA9600C@sonru.com> Message-ID: модульными тестами проверяете ? поделитесь ? 6 марта 2013 г., 22:54 пользователь Anatoly Mikhailov написал: > добрый день, > > Какая версия PCRE совместимы с Nginx 1.3.12+? > В Wiki сказано PCRE "version 4.4 -- 8.21", но я давно устанавливаю 8.30 - > все совместимо. > Но уже доступна 8.32 (http://www.pcre.org/changelog.txt), стоит пробовать? > > Анатолий > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Wed Mar 6 18:51:21 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 6 Mar 2013 22:51:21 +0400 Subject: =?UTF-8?B?UmU6IFBDUkUg0LLQtdGA0YHQuNGP?= In-Reply-To: <7D286A1D-D70F-4552-93E2-3CFE1EA9600C@sonru.com> References: <7D286A1D-D70F-4552-93E2-3CFE1EA9600C@sonru.com> Message-ID: <201303062251.21525.vbart@nginx.com> On Wednesday 06 March 2013 20:54:34 Anatoly Mikhailov wrote: > добрый день, > > Какая версия PCRE совместимы с Nginx 1.3.12+? > В Wiki сказано PCRE "version 4.4 ? 8.21", но я давно устанавливаю 8.30 - > все совместимо. Но уже доступна 8.32 (http://www.pcre.org/changelog.txt), > стоит пробовать? > Официальные бинарные сборки для Windows собираются с 8.32: http://trac.nginx.org/nginx/browser/nginx/trunk/misc/GNUmakefile Стоит иметь ввиду, что в wiki может писать любой желающий (нужно только зарегистрироваться), и контент там поддерживается по большей части силами энтузиастов. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From anatoly at sonru.com Wed Mar 6 18:59:20 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 6 Mar 2013 18:59:20 +0000 Subject: =?UTF-8?B?UmU6IFBDUkUg0LLQtdGA0YHQuNGP?= In-Reply-To: <201303062251.21525.vbart@nginx.com> References: <7D286A1D-D70F-4552-93E2-3CFE1EA9600C@sonru.com> <201303062251.21525.vbart@nginx.com> Message-ID: On Mar 6, 2013, at 6:51 PM, Валентин Бартенев wrote: > On Wednesday 06 March 2013 20:54:34 Anatoly Mikhailov wrote: >> добрый день, >> >> Какая версия PCRE совместимы с Nginx 1.3.12+? >> В Wiki сказано PCRE "version 4.4 ? 8.21", но я давно устанавливаю 8.30 - >> все совместимо. Но уже доступна 8.32 (http://www.pcre.org/changelog.txt), >> стоит пробовать? >> > > Официальные бинарные сборки для Windows собираются с 8.32: > http://trac.nginx.org/nginx/browser/nginx/trunk/misc/GNUmakefile Linux/FreeBSD версии тоже имеет смысл собирать с 8.32? > > Стоит иметь ввиду, что в wiki может писать любой желающий (нужно только > зарегистрироваться), и контент там поддерживается по большей части силами > энтузиастов. понял > > -- > Валентин Бартенев > http://nginx.com/support.html > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Wed Mar 6 19:15:20 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 6 Mar 2013 23:15:20 +0400 Subject: =?UTF-8?B?UmU6IFBDUkUg0LLQtdGA0YHQuNGP?= In-Reply-To: References: <7D286A1D-D70F-4552-93E2-3CFE1EA9600C@sonru.com> <201303062251.21525.vbart@nginx.com> Message-ID: <201303062315.20961.vbart@nginx.com> On Wednesday 06 March 2013 22:59:20 Anatoly Mikhailov wrote: > On Mar 6, 2013, at 6:51 PM, Валентин Бартенев wrote: > > On Wednesday 06 March 2013 20:54:34 Anatoly Mikhailov wrote: > >> добрый день, > >> > >> Какая версия PCRE совместимы с Nginx 1.3.12+? > >> В Wiki сказано PCRE "version 4.4 ? 8.21", но я давно устанавливаю 8.30 - > >> все совместимо. Но уже доступна 8.32 > >> (http://www.pcre.org/changelog.txt), стоит пробовать? > > > > Официальные бинарные сборки для Windows собираются с 8.32: > > http://trac.nginx.org/nginx/browser/nginx/trunk/misc/GNUmakefile > > Linux/FreeBSD версии тоже имеет смысл собирать с 8.32? > В большинстве случаев можно не беспокоиться по этому поводу и собирать с той версией, что поставляется в репозиториях вашего дистрибутива. Я бы не стал на этом особо заострять внимание, если только в более свежей версии не исправили уязвимость, или какой-то баг, который вас беспокоит, либо если нужна какая-то возможность, появившаяся в более свежих версиях. -- Валентин Бартенев http://nginx.com/support.html http://nginx.org/en/donation.html From anatoly at sonru.com Wed Mar 6 19:23:39 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 6 Mar 2013 19:23:39 +0000 Subject: =?UTF-8?B?UmU6IFBDUkUg0LLQtdGA0YHQuNGP?= In-Reply-To: <201303062315.20961.vbart@nginx.com> References: <7D286A1D-D70F-4552-93E2-3CFE1EA9600C@sonru.com> <201303062251.21525.vbart@nginx.com> <201303062315.20961.vbart@nginx.com> Message-ID: <123AD9BB-8592-4F9B-B32E-6F84E79907B3@sonru.com> On Mar 6, 2013, at 7:15 PM, Валентин Бартенев wrote: > On Wednesday 06 March 2013 22:59:20 Anatoly Mikhailov wrote: >> On Mar 6, 2013, at 6:51 PM, Валентин Бартенев wrote: >>> On Wednesday 06 March 2013 20:54:34 Anatoly Mikhailov wrote: >>>> добрый день, >>>> >>>> Какая версия PCRE совместимы с Nginx 1.3.12+? >>>> В Wiki сказано PCRE "version 4.4 ? 8.21", но я давно устанавливаю 8.30 - >>>> все совместимо. Но уже доступна 8.32 >>>> (http://www.pcre.org/changelog.txt), стоит пробовать? >>> >>> Официальные бинарные сборки для Windows собираются с 8.32: >>> http://trac.nginx.org/nginx/browser/nginx/trunk/misc/GNUmakefile >> >> Linux/FreeBSD версии тоже имеет смысл собирать с 8.32? >> > > В большинстве случаев можно не беспокоиться по этому поводу и собирать с той > версией, что поставляется в репозиториях вашего дистрибутива. к сожалению, приходится иметь дело с разными дистрибутивами, нередко 5-7 летней давности, поэтому было решено использовать стабильные зависимости (свежие на определенный момент времени), чтобы не ловить баги и не дебажить nginx на разных системах. ОК, остаемся на версии 8.30 > > Я бы не стал на этом особо заострять внимание, если только в более свежей версии > не исправили уязвимость, или какой-то баг, который вас беспокоит, либо если > нужна какая-то возможность, появившаяся в более свежих версиях. ничего не беспокоит, но "Improve the matching speed of capturing brackets." поднимает настроение > > -- > Валентин Бартенев > http://nginx.com/support.html > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From anatoly at sonru.com Wed Mar 6 19:35:04 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 6 Mar 2013 19:35:04 +0000 Subject: =?UTF-8?B?0LrQsNGB0LrQsNC0INC/0YDQvtC60YHQuNGA0YPRjtGJ0LjRhSDRgdC10YDQstC1?= =?UTF-8?B?0YDQvtCy?= Message-ID: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> добрый день, Вопрос балансировки нагрузки не дает мне покоя несколько дней, пока склоняюсь к использованию Nginx в роли балансировщика. Таким образом будет каскад Nginx - (Nginx - Unicorn) x 5. У нас связка Nginx+Unicorn на нескольких независимых серверах разного назначения (Main, Admin, API, Mobile-API), но сейчас, ввиду растущей нагрузки, есть необходимость основное (Main) приложение поставить за балансировщиком (условно Nginx-А), получив 5 бэк-энд серверов (условно Nginx-B), которые и будут непосредственно проксировать на Unicorn. В роли балансировщика выступают 2 кандидата: Nginx и Haproxy. С первым все понятно: - SSL-offload, и чистый http между Nginx-A и Nginx-B - с одной стороны, знакомая и понятная настройка - с другой стороны, какие параметры proxy надо настроить (нужен ли http-1.1 между A и B ) Haproxy: - банально "типичное решение" - нетривиальная и запутанная конфигурация Анатолий From igor at sysoev.ru Wed Mar 6 19:53:06 2013 From: igor at sysoev.ru (Igor Sysoev) Date: Wed, 6 Mar 2013 23:53:06 +0400 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> Message-ID: <51B407FA-FFBC-4574-86D8-990DF4A034A0@sysoev.ru> On Mar 6, 2013, at 23:35 , Anatoly Mikhailov wrote: > добрый день, > > Вопрос балансировки нагрузки не дает мне покоя несколько дней, пока склоняюсь к использованию > Nginx в роли балансировщика. Таким образом будет каскад Nginx - (Nginx - Unicorn) x 5. > > У нас связка Nginx+Unicorn на нескольких независимых серверах разного назначения (Main, Admin, API, Mobile-API), > но сейчас, ввиду растущей нагрузки, есть необходимость основное (Main) приложение поставить > за балансировщиком (условно Nginx-А), получив 5 бэк-энд серверов (условно Nginx-B), которые > и будут непосредственно проксировать на Unicorn. > > В роли балансировщика выступают 2 кандидата: Nginx и Haproxy. > С первым все понятно: > - SSL-offload, и чистый http между Nginx-A и Nginx-B > - с одной стороны, знакомая и понятная настройка > - с другой стороны, какие параметры proxy надо настроить (нужен ли http-1.1 между A и B ) Между nginx'ами можно поставить 1.1, поскольку для второго nginx'а постоянные соедиения дешёвые. > Haproxy: > - банально "типичное решение" > - нетривиальная и запутанная конфигурация -- Igor Sysoev http://nginx.com/support.html From anatoly at sonru.com Wed Mar 6 20:08:06 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 6 Mar 2013 20:08:06 +0000 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: <51B407FA-FFBC-4574-86D8-990DF4A034A0@sysoev.ru> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <51B407FA-FFBC-4574-86D8-990DF4A034A0@sysoev.ru> Message-ID: <6B8645CD-5B0D-46A6-AA0A-018016A25829@sonru.com> On Mar 6, 2013, at 7:53 PM, Igor Sysoev wrote: > On Mar 6, 2013, at 23:35 , Anatoly Mikhailov wrote: > >> добрый день, >> >> Вопрос балансировки нагрузки не дает мне покоя несколько дней, пока склоняюсь к использованию >> Nginx в роли балансировщика. Таким образом будет каскад Nginx - (Nginx - Unicorn) x 5. >> >> У нас связка Nginx+Unicorn на нескольких независимых серверах разного назначения (Main, Admin, API, Mobile-API), >> но сейчас, ввиду растущей нагрузки, есть необходимость основное (Main) приложение поставить >> за балансировщиком (условно Nginx-А), получив 5 бэк-энд серверов (условно Nginx-B), которые >> и будут непосредственно проксировать на Unicorn. >> >> В роли балансировщика выступают 2 кандидата: Nginx и Haproxy. >> С первым все понятно: >> - SSL-offload, и чистый http между Nginx-A и Nginx-B >> - с одной стороны, знакомая и понятная настройка >> - с другой стороны, какие параметры proxy надо настроить (нужен ли http-1.1 между A и B ) > > Между nginx'ами можно поставить 1.1, поскольку для второго nginx'а постоянные соедиения > дешёвые. Да, Игорь, спасибо, что прояснили этот момент. Если я правильно понимаю, то конфигурация Nginx-A будет: upstream http_backend { server 10.0.0.1:8080; # Nginx-B server 10.0.0.1:8080; # Nginx-B keepalive 16; } server { ssl on; listen 443 default spdy ssl; location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $http_host; proxy_redirect off; proxy_pass http://http_backend; proxy_http_version 1.1; proxy_set_header Connection ""; } } > >> Haproxy: >> - банально "типичное решение" >> - нетривиальная и запутанная конфигурация > > > -- > Igor Sysoev > http://nginx.com/support.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Mar 7 09:27:05 2013 From: nginx-forum at nginx.us (arty777) Date: Thu, 07 Mar 2013 04:27:05 -0500 Subject: =?UTF-8?B?UmU6INCf0L7RgdC+0LLQtdGC0YPQudGC0LUg0LrQvtC90YTQuNCzIG5naW54INC0?= =?UTF-8?B?0LvRjyDQvtGC0LTQsNGH0Lgg0L7QtNC90L7QstGA0LXQvNC10L3QvdC+IDEw?= =?UTF-8?B?0LorINGE0LDQudC70L7Qsg==?= In-Reply-To: <4F3E7181.8060309@kpi.ua> References: <4F3E7181.8060309@kpi.ua> Message-ID: Андрей Василишин Wrote: ------------------------------------------------------- > Вам говорят что-нибудь слова block size, sector size? > > Опять же из мана: > Поскольку directio в Linux можно использовать только для чтения > блоков, > выравненных на границу 512 байт (или 4К для XFS), то невыравненный > конец > файла будет читаться блокированно. То же относится к запросам с > указанием диапазона запрашиваемых байт (byte-range requests) и к > запросам FLV не с начала файла: чтение невыравненных начала и конца > ответа будет блокирующимся. Явно выключать sendfile не нужно, так как > при использовании directio он выключается автоматически. У меня линукс , и ext4 tune2fs -l /dev/sdm1 Block size: 4096 Fragment size: 4096 Получается что надо ставить directio_alignment 4K; а не 512 как написано в мане :) Верно? Если да, то может стоить ман поправить , а то все у кого линукс и не XFS будут ставить 512 , хотя по умолчанию блок сайз у ext4 4К Posted at Nginx Forum: http://forum.nginx.org/read.php?21,216159,237041#msg-237041 From vbart at nginx.com Thu Mar 7 09:54:22 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 7 Mar 2013 13:54:22 +0400 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> Message-ID: <201303071354.22491.vbart@nginx.com> On Wednesday 06 March 2013 23:35:04 Anatoly Mikhailov wrote: > добрый день, > > Вопрос балансировки нагрузки не дает мне покоя несколько дней, пока > склоняюсь к использованию Nginx в роли балансировщика. Таким образом будет > каскад Nginx - (Nginx - Unicorn) x 5. > > У нас связка Nginx+Unicorn на нескольких независимых серверах разного > назначения (Main, Admin, API, Mobile-API), но сейчас, ввиду растущей > нагрузки, есть необходимость основное (Main) приложение поставить за > балансировщиком (условно Nginx-А), получив 5 бэк-энд серверов (условно > Nginx-B), которые и будут непосредственно проксировать на Unicorn. > [...] А в чем необходимость Nginx-B стоять перед Unicorn-ом? Почему бы не проксировать с Nginx-A на Unicorn напрямую? -- Валентин Бартенев http://nginx.org/en/donation.html From vbart at nginx.com Thu Mar 7 10:10:09 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 7 Mar 2013 14:10:09 +0400 Subject: =?UTF-8?B?UmU6ICDQn9C+0YHQvtCy0LXRgtGD0LnRgtC1INC60L7QvdGE0LjQsyBuZ2lueCA=?= =?UTF-8?B?0LTQu9GPINC+0YLQtNCw0YfQuCDQvtC00L3QvtCy0YDQtdC80LXQvdC90L4g?= =?UTF-8?B?MTDQuisg0YTQsNC50LvQvtCy?= In-Reply-To: References: <4F3E7181.8060309@kpi.ua> Message-ID: <201303071410.09300.vbart@nginx.com> On Thursday 07 March 2013 13:27:05 arty777 wrote: > Андрей Василишин Wrote: > ------------------------------------------------------- > > > Вам говорят что-нибудь слова block size, sector size? > > > > Опять же из мана: > > Поскольку directio в Linux можно использовать только для чтения > > блоков, > > выравненных на границу 512 байт (или 4К для XFS), то невыравненный > > конец > > файла будет читаться блокированно. То же относится к запросам с > > указанием диапазона запрашиваемых байт (byte-range requests) и к > > запросам FLV не с начала файла: чтение невыравненных начала и конца > > ответа будет блокирующимся. Явно выключать sendfile не нужно, так как > > при использовании directio он выключается автоматически. > > У меня линукс , и ext4 > tune2fs -l /dev/sdm1 > Block size: 4096 > Fragment size: 4096 > > Получается что надо ставить > directio_alignment 4K; > > а не 512 как написано в мане :) Верно? > Нет, не верно. > Если да, то может стоить ман поправить , а то все у кого линукс и не XFS > будут ставить 512 , хотя по умолчанию блок сайз у ext4 4К > Размер блоков на ext4 не имеет значения для O_DIRECT. В мане написано верно. -- Валентин Бартенев http://nginx.org/en/donation.html From igor at sysoev.ru Thu Mar 7 10:12:23 2013 From: igor at sysoev.ru (Igor Sysoev) Date: Thu, 7 Mar 2013 14:12:23 +0400 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: <6B8645CD-5B0D-46A6-AA0A-018016A25829@sonru.com> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <51B407FA-FFBC-4574-86D8-990DF4A034A0@sysoev.ru> <6B8645CD-5B0D-46A6-AA0A-018016A25829@sonru.com> Message-ID: <258DAB24-E031-4499-A4AD-DB9D4F25A685@sysoev.ru> On Mar 7, 2013, at 0:08 , Anatoly Mikhailov wrote: > On Mar 6, 2013, at 7:53 PM, Igor Sysoev wrote: > >> On Mar 6, 2013, at 23:35 , Anatoly Mikhailov wrote: >> >>> добрый день, >>> >>> Вопрос балансировки нагрузки не дает мне покоя несколько дней, пока склоняюсь к использованию >>> Nginx в роли балансировщика. Таким образом будет каскад Nginx - (Nginx - Unicorn) x 5. >>> >>> У нас связка Nginx+Unicorn на нескольких независимых серверах разного назначения (Main, Admin, API, Mobile-API), >>> но сейчас, ввиду растущей нагрузки, есть необходимость основное (Main) приложение поставить >>> за балансировщиком (условно Nginx-А), получив 5 бэк-энд серверов (условно Nginx-B), которые >>> и будут непосредственно проксировать на Unicorn. >>> >>> В роли балансировщика выступают 2 кандидата: Nginx и Haproxy. >>> С первым все понятно: >>> - SSL-offload, и чистый http между Nginx-A и Nginx-B >>> - с одной стороны, знакомая и понятная настройка >>> - с другой стороны, какие параметры proxy надо настроить (нужен ли http-1.1 между A и B ) >> >> Между nginx'ами можно поставить 1.1, поскольку для второго nginx'а постоянные соедиения >> дешёвые. > > Да, Игорь, спасибо, что прояснили этот момент. > Если я правильно понимаю, то конфигурация Nginx-A будет: > > > upstream http_backend { > server 10.0.0.1:8080; # Nginx-B > server 10.0.0.1:8080; # Nginx-B > keepalive 16; > } keepalive можно поставить значительно больше. -- Igor Sysoev http://nginx.com/support.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Mar 7 11:02:49 2013 From: nginx-forum at nginx.us (arty777) Date: Thu, 07 Mar 2013 06:02:49 -0500 Subject: =?UTF-8?B?UmU6INCf0L7RgdC+0LLQtdGC0YPQudGC0LUg0LrQvtC90YTQuNCzIG5naW54INC0?= =?UTF-8?B?0LvRjyDQvtGC0LTQsNGH0Lgg0L7QtNC90L7QstGA0LXQvNC10L3QvdC+IDEw?= =?UTF-8?B?0LorINGE0LDQudC70L7Qsg==?= In-Reply-To: <201303071410.09300.vbart@nginx.com> References: <201303071410.09300.vbart@nginx.com> Message-ID: <487acb902ae529720ef6e42fcfec8659.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Thursday 07 March 2013 13:27:05 arty777 wrote: > > Андрей Василишин Wrote: > > ------------------------------------------------------- > > > > > Вам говорят что-нибудь слова block size, sector size? > > > > > > Опять же из мана: > > > Поскольку directio в Linux можно использовать только для чтения > > > блоков, > > > выравненных на границу 512 байт (или 4К для XFS), то невыравненный > > > конец > > > файла будет читаться блокированно. То же относится к запросам с > > > указанием диапазона запрашиваемых байт (byte-range requests) и к > > > запросам FLV не с начала файла: чтение невыравненных начала и > конца > > > ответа будет блокирующимся. Явно выключать sendfile не нужно, так > как > > > при использовании directio он выключается автоматически. > > > > У меня линукс , и ext4 > > tune2fs -l /dev/sdm1 > > Block size: 4096 > > Fragment size: 4096 > > > > Получается что надо ставить > > directio_alignment 4K; > > > > а не 512 как написано в мане :) Верно? > > > > Нет, не верно. > > > Если да, то может стоить ман поправить , а то все у кого линукс и > не XFS > > будут ставить 512 , хотя по умолчанию блок сайз у ext4 4К > > > > Размер блоков на ext4 не имеет значения для O_DIRECT. В мане написано > верно. Пишите понятнее. Аргументируйте. Размер блоков не имеет значения , а что имеет:? Я поставил directio_alignment 4K; производительност ькаждого отдельного диска увеличалась существенно , +25-30% . Как это объяснить? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,216159,237049#msg-237049 From anatoly at sonru.com Thu Mar 7 11:03:59 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Thu, 7 Mar 2013 11:03:59 +0000 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: <201303071354.22491.vbart@nginx.com> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <201303071354.22491.vbart@nginx.com> Message-ID: <92C91BDB-9821-4741-A737-4117621044B2@sonru.com> On Mar 7, 2013, at 9:54 AM, Валентин Бартенев wrote: > On Wednesday 06 March 2013 23:35:04 Anatoly Mikhailov wrote: >> добрый день, >> >> Вопрос балансировки нагрузки не дает мне покоя несколько дней, пока >> склоняюсь к использованию Nginx в роли балансировщика. Таким образом будет >> каскад Nginx - (Nginx - Unicorn) x 5. >> >> У нас связка Nginx+Unicorn на нескольких независимых серверах разного >> назначения (Main, Admin, API, Mobile-API), но сейчас, ввиду растущей >> нагрузки, есть необходимость основное (Main) приложение поставить за >> балансировщиком (условно Nginx-А), получив 5 бэк-энд серверов (условно >> Nginx-B), которые и будут непосредственно проксировать на Unicorn. >> > [...] > > А в чем необходимость Nginx-B стоять перед Unicorn-ом? > Почему бы не проксировать с Nginx-A на Unicorn напрямую? Ребята из Github не советуют так делать: http://stackoverflow.com/questions/14082243/unicorn-multiple-machines-setup А если серьезно, то как в этом случае отдавать статику, если она не на CDN? > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Thu Mar 7 11:41:43 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 7 Mar 2013 15:41:43 +0400 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: <92C91BDB-9821-4741-A737-4117621044B2@sonru.com> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <201303071354.22491.vbart@nginx.com> <92C91BDB-9821-4741-A737-4117621044B2@sonru.com> Message-ID: <201303071541.43901.vbart@nginx.com> On Thursday 07 March 2013 15:03:59 Anatoly Mikhailov wrote: > On Mar 7, 2013, at 9:54 AM, Валентин Бартенев wrote: > > On Wednesday 06 March 2013 23:35:04 Anatoly Mikhailov wrote: > >> добрый день, > >> > >> Вопрос балансировки нагрузки не дает мне покоя несколько дней, пока > >> склоняюсь к использованию Nginx в роли балансировщика. Таким образом > >> будет каскад Nginx - (Nginx - Unicorn) x 5. > >> > >> У нас связка Nginx+Unicorn на нескольких независимых серверах разного > >> назначения (Main, Admin, API, Mobile-API), но сейчас, ввиду растущей > >> нагрузки, есть необходимость основное (Main) приложение поставить за > >> балансировщиком (условно Nginx-А), получив 5 бэк-энд серверов (условно > >> Nginx-B), которые и будут непосредственно проксировать на Unicorn. > > > > [...] > > > > А в чем необходимость Nginx-B стоять перед Unicorn-ом? > > Почему бы не проксировать с Nginx-A на Unicorn напрямую? > > Ребята из Github не советуют так делать: > http://stackoverflow.com/questions/14082243/unicorn-multiple-machines-setu > p А если серьезно, то как в этом случае отдавать статику, если она не на > CDN? > Дополнительный промежуточный nginx тоже добавляет оверхэда, и тут вопрос скорее в том, какой из них больше (от установки соединения между nginx-ом и unicorn по сети, или от дополнительного nginx-а с keepalive). А в чём проблема отдавать статику? Мне казалось, что создание помойки из кода и статики - это исключительно черта php-программистов, и у рубистов должно быть с этим всё в порядке, в том смысле, что отличить запрос к статике можно ещё на балансировщике без stat() (и проксировать далее, либо на nginx, либо на unicorn). -- Валентин Бартенев http://nginx.org/en/donation.html From vbart at nginx.com Thu Mar 7 12:01:37 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 7 Mar 2013 16:01:37 +0400 Subject: =?UTF-8?B?UmU6ICDQn9C+0YHQvtCy0LXRgtGD0LnRgtC1INC60L7QvdGE0LjQsyBuZ2lueCA=?= =?UTF-8?B?0LTQu9GPINC+0YLQtNCw0YfQuCDQvtC00L3QvtCy0YDQtdC80LXQvdC90L4g?= =?UTF-8?B?MTDQuisg0YTQsNC50LvQvtCy?= In-Reply-To: <487acb902ae529720ef6e42fcfec8659.NginxMailingListRussian@forum.nginx.org> References: <201303071410.09300.vbart@nginx.com> <487acb902ae529720ef6e42fcfec8659.NginxMailingListRussian@forum.nginx.org> Message-ID: <201303071601.37426.vbart@nginx.com> On Thursday 07 March 2013 15:02:49 arty777 wrote: > Валентин Бартенев Wrote: > ------------------------------------------------------- > > > On Thursday 07 March 2013 13:27:05 arty777 wrote: > > > Андрей Василишин Wrote: > > > ------------------------------------------------------- > > > > > > > Вам говорят что-нибудь слова block size, sector size? > > > > > > > > Опять же из мана: > > > > Поскольку directio в Linux можно использовать только для чтения > > > > блоков, > > > > выравненных на границу 512 байт (или 4К для XFS), то невыравненный > > > > конец > > > > файла будет читаться блокированно. То же относится к запросам с > > > > указанием диапазона запрашиваемых байт (byte-range requests) и к > > > > запросам FLV не с начала файла: чтение невыравненных начала и > > > > конца > > > > > > ответа будет блокирующимся. Явно выключать sendfile не нужно, так > > > > как > > > > > > при использовании directio он выключается автоматически. > > > > > > У меня линукс , и ext4 > > > > > > tune2fs -l /dev/sdm1 > > > Block size: 4096 > > > Fragment size: 4096 > > > > > > Получается что надо ставить > > > directio_alignment 4K; > > > > > > а не 512 как написано в мане :) Верно? > > > > Нет, не верно. > > > > > Если да, то может стоить ман поправить , а то все у кого линукс и > > > > не XFS > > > > > будут ставить 512 , хотя по умолчанию блок сайз у ext4 4К > > > > Размер блоков на ext4 не имеет значения для O_DIRECT. В мане написано > > верно. > > Пишите понятнее. Аргументируйте. Размер блоков не имеет значения , а что > имеет:? Имеет значение особенности реализации поддержки O_DIRECT в Linux-ядре. > Я поставил directio_alignment 4K; производительност ькаждого отдельного > диска увеличалась существенно , +25-30% . Как это объяснить? > Вы выключили O_DIRECT для всех чтений не выравненных на 4k, т.е. для некоторых, которых он ранее работал - более не включается вообще. Это такой очень странный способ повлиять на значение директивы directio. Зачем вы её вообще включили, если вам без неё лучше? Неправильно указанный directio_alignment (скажем 512 там, где нужно 4k) приведет к ошибкам в error_log вида: [crit] pread() failed (22: Invalid argument) while sending response to client и невозможности nginx обработать запрос. -- Валентин Бартенев http://nginx.org/en/donation.html From anatoly at sonru.com Thu Mar 7 12:26:03 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Thu, 7 Mar 2013 12:26:03 +0000 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: <201303071541.43901.vbart@nginx.com> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <201303071354.22491.vbart@nginx.com> <92C91BDB-9821-4741-A737-4117621044B2@sonru.com> <201303071541.43901.vbart@nginx.com> Message-ID: On Mar 7, 2013, at 11:41 AM, Валентин Бартенев wrote: > On Thursday 07 March 2013 15:03:59 Anatoly Mikhailov wrote: >> On Mar 7, 2013, at 9:54 AM, Валентин Бартенев wrote: >>> On Wednesday 06 March 2013 23:35:04 Anatoly Mikhailov wrote: >>>> добрый день, >>>> >>>> Вопрос балансировки нагрузки не дает мне покоя несколько дней, пока >>>> склоняюсь к использованию Nginx в роли балансировщика. Таким образом >>>> будет каскад Nginx - (Nginx - Unicorn) x 5. >>>> >>>> У нас связка Nginx+Unicorn на нескольких независимых серверах разного >>>> назначения (Main, Admin, API, Mobile-API), но сейчас, ввиду растущей >>>> нагрузки, есть необходимость основное (Main) приложение поставить за >>>> балансировщиком (условно Nginx-А), получив 5 бэк-энд серверов (условно >>>> Nginx-B), которые и будут непосредственно проксировать на Unicorn. >>> >>> [...] >>> >>> А в чем необходимость Nginx-B стоять перед Unicorn-ом? >>> Почему бы не проксировать с Nginx-A на Unicorn напрямую? >> >> Ребята из Github не советуют так делать: >> http://stackoverflow.com/questions/14082243/unicorn-multiple-machines-setu >> p А если серьезно, то как в этом случае отдавать статику, если она не на >> CDN? >> > > Дополнительный промежуточный nginx тоже добавляет оверхэда, и тут вопрос скорее > в том, какой из них больше (от установки соединения между nginx-ом и unicorn по > сети, или от дополнительного nginx-а с keepalive). оверхэд будет в любом случае, поэтому и нужна ваша помощь, как все правильно сделать > > А в чём проблема отдавать статику? Мне казалось, что создание помойки из кода и > статики - это исключительно черта php-программистов, и у рубистов должно быть с > этим всё в порядке, в том смысле, что отличить запрос к статике можно ещё на > балансировщике без stat() (и проксировать далее, либо на nginx, либо на > unicorn). помойки из кода и статики никакой нет, вся статика лежит отдельно как у всех рубистов :) вопрос в том, как правильно ее отдавать - через 2 nginx-а или деплоить статику на балансировщик? > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From denis at webmaster.spb.ru Thu Mar 7 12:37:13 2013 From: denis at webmaster.spb.ru (denis) Date: Thu, 07 Mar 2013 16:37:13 +0400 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <201303071354.22491.vbart@nginx.com> <92C91BDB-9821-4741-A737-4117621044B2@sonru.com> <201303071541.43901.vbart@nginx.com> Message-ID: <513889F9.9080801@webmaster.spb.ru> 07.03.2013 16:26, Anatoly Mikhailov пишет: > >> А в чём проблема отдавать статику? Мне казалось, что создание помойки из кода и >> статики - это исключительно черта php-программистов, и у рубистов должно быть с >> этим всё в порядке, в том смысле, что отличить запрос к статике можно ещё на >> балансировщике без stat() (и проксировать далее, либо на nginx, либо на >> unicorn). > помойки из кода и статики никакой нет, вся статика лежит отдельно как у всех рубистов :) > вопрос в том, как правильно ее отдавать - через 2 nginx-а или деплоить статику на балансировщик? жизнь показывает, что 2 нгинха для статики показывает себя стабильнее. Мы с этим столкнулись, когда статика на внешнем нгинхе и там начинается бэкап файлов (io проседает) и _особенно_ заметно с s3cmd sync на 100к+ файлах, даже чисто динамические запросы не проходят по таймауту и не происходит переключения на резерв. Правда, синхронизация занимает от минуты до 5 минут, так что для нас это не критично. From nginx-forum at nginx.us Thu Mar 7 12:37:24 2013 From: nginx-forum at nginx.us (arty777) Date: Thu, 07 Mar 2013 07:37:24 -0500 Subject: =?UTF-8?B?UmU6INCf0L7RgdC+0LLQtdGC0YPQudGC0LUg0LrQvtC90YTQuNCzIG5naW54INC0?= =?UTF-8?B?0LvRjyDQvtGC0LTQsNGH0Lgg0L7QtNC90L7QstGA0LXQvNC10L3QvdC+IDEw?= =?UTF-8?B?0LorINGE0LDQudC70L7Qsg==?= In-Reply-To: <201303071601.37426.vbart@nginx.com> References: <201303071601.37426.vbart@nginx.com> Message-ID: Какие должны быт ьправильные настройки что б работало AIO (асинхронн) , привидите пример конфига правильный, для линукс , с файловой системой ext4 >Неправильно указанный directio_alignment (скажем 512 там, где нужно 4k) приведет >к ошибкам в error_log вида: > >[crit] pread() failed (22: Invalid argument) while sending response to client У меня ранее стояло 512 , сейчас 4К , и ошибок таких как не было так и нет Posted at Nginx Forum: http://forum.nginx.org/read.php?21,216159,237055#msg-237055 From anatoly at sonru.com Thu Mar 7 12:42:31 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Thu, 7 Mar 2013 12:42:31 +0000 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: <513889F9.9080801@webmaster.spb.ru> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <201303071354.22491.vbart@nginx.com> <92C91BDB-9821-4741-A737-4117621044B2@sonru.com> <201303071541.43901.vbart@nginx.com> <513889F9.9080801@webmaster.spb.ru> Message-ID: <309F7FDE-04D6-4137-A58F-5DEAB314C83B@sonru.com> On Mar 7, 2013, at 12:37 PM, denis wrote: > 07.03.2013 16:26, Anatoly Mikhailov пишет: >> >>> А в чём проблема отдавать статику? Мне казалось, что создание помойки из кода и >>> статики - это исключительно черта php-программистов, и у рубистов должно быть с >>> этим всё в порядке, в том смысле, что отличить запрос к статике можно ещё на >>> балансировщике без stat() (и проксировать далее, либо на nginx, либо на >>> unicorn). >> помойки из кода и статики никакой нет, вся статика лежит отдельно как у всех рубистов :) >> вопрос в том, как правильно ее отдавать - через 2 nginx-а или деплоить статику на балансировщик? > жизнь показывает, что 2 нгинха для статики показывает себя стабильнее. Мы с этим столкнулись, когда статика на внешнем нгинхе и там начинается бэкап файлов (io проседает) и _особенно_ заметно с s3cmd sync на 100к+ файлах, даже чисто динамические запросы не проходят по таймауту и не происходит переключения на резерв. Правда, синхронизация занимает от минуты до 5 минут, так что для нас это не критично. > бэкап на внешнем nginx - то есть "бэкап на балансировщике"? если да, то зачем? > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From anatoly at sonru.com Thu Mar 7 12:52:25 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Thu, 7 Mar 2013 12:52:25 +0000 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: <258DAB24-E031-4499-A4AD-DB9D4F25A685@sysoev.ru> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <51B407FA-FFBC-4574-86D8-990DF4A034A0@sysoev.ru> <6B8645CD-5B0D-46A6-AA0A-018016A25829@sonru.com> <258DAB24-E031-4499-A4AD-DB9D4F25A685@sysoev.ru> Message-ID: On Mar 7, 2013, at 10:12 AM, Igor Sysoev wrote: > On Mar 7, 2013, at 0:08 , Anatoly Mikhailov wrote: > >> On Mar 6, 2013, at 7:53 PM, Igor Sysoev wrote: >> >>> On Mar 6, 2013, at 23:35 , Anatoly Mikhailov wrote: >>> >>>> добрый день, >>>> >>>> Вопрос балансировки нагрузки не дает мне покоя несколько дней, пока склоняюсь к использованию >>>> Nginx в роли балансировщика. Таким образом будет каскад Nginx - (Nginx - Unicorn) x 5. >>>> >>>> У нас связка Nginx+Unicorn на нескольких независимых серверах разного назначения (Main, Admin, API, Mobile-API), >>>> но сейчас, ввиду растущей нагрузки, есть необходимость основное (Main) приложение поставить >>>> за балансировщиком (условно Nginx-А), получив 5 бэк-энд серверов (условно Nginx-B), которые >>>> и будут непосредственно проксировать на Unicorn. >>>> >>>> В роли балансировщика выступают 2 кандидата: Nginx и Haproxy. >>>> С первым все понятно: >>>> - SSL-offload, и чистый http между Nginx-A и Nginx-B >>>> - с одной стороны, знакомая и понятная настройка >>>> - с другой стороны, какие параметры proxy надо настроить (нужен ли http-1.1 между A и B ) >>> >>> Между nginx'ами можно поставить 1.1, поскольку для второго nginx'а постоянные соедиения >>> дешёвые. >> >> Да, Игорь, спасибо, что прояснили этот момент. >> Если я правильно понимаю, то конфигурация Nginx-A будет: >> >> >> upstream http_backend { >> server 10.0.0.1:8080; # Nginx-B >> server 10.0.0.1:8080; # Nginx-B >> keepalive 16; >> } > > keepalive можно поставить значительно больше. > Игорь, а что вы думаете о ldirectord, это не балансировщик, разумеется, но отдача ответа от бэкэнда идет напрямую в обход балансировщика. Это решение может не подойти по разным причинам, но мне очень хочется узнать ваше мнение об этом, тем более, что Github именно так и делает. > > -- > Igor Sysoev > http://nginx.com/support.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at webmaster.spb.ru Thu Mar 7 12:54:02 2013 From: denis at webmaster.spb.ru (denis) Date: Thu, 07 Mar 2013 16:54:02 +0400 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: <309F7FDE-04D6-4137-A58F-5DEAB314C83B@sonru.com> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <201303071354.22491.vbart@nginx.com> <92C91BDB-9821-4741-A737-4117621044B2@sonru.com> <201303071541.43901.vbart@nginx.com> <513889F9.9080801@webmaster.spb.ru> <309F7FDE-04D6-4137-A58F-5DEAB314C83B@sonru.com> Message-ID: <51388DEA.3000300@webmaster.spb.ru> 07.03.2013 16:42, Anatoly Mikhailov пишет: > > бэкап на внешнем nginx - то есть "бэкап на балансировщике"? если да, то зачем? > он не балансировщик, он основной сервер + есть резервный в облаке с платными ресурсами. From vbart at nginx.com Thu Mar 7 14:15:07 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 7 Mar 2013 18:15:07 +0400 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <201303071541.43901.vbart@nginx.com> Message-ID: <201303071815.07552.vbart@nginx.com> On Thursday 07 March 2013 16:26:03 Anatoly Mikhailov wrote: > On Mar 7, 2013, at 11:41 AM, Валентин Бартенев wrote: > > On Thursday 07 March 2013 15:03:59 Anatoly Mikhailov wrote: > >> On Mar 7, 2013, at 9:54 AM, Валентин Бартенев wrote: > >>> On Wednesday 06 March 2013 23:35:04 Anatoly Mikhailov wrote: > >>>> добрый день, > >>>> > >>>> Вопрос балансировки нагрузки не дает мне покоя несколько дней, пока > >>>> склоняюсь к использованию Nginx в роли балансировщика. Таким образом > >>>> будет каскад Nginx - (Nginx - Unicorn) x 5. > >>>> > >>>> У нас связка Nginx+Unicorn на нескольких независимых серверах разного > >>>> назначения (Main, Admin, API, Mobile-API), но сейчас, ввиду растущей > >>>> нагрузки, есть необходимость основное (Main) приложение поставить за > >>>> балансировщиком (условно Nginx-А), получив 5 бэк-энд серверов (условно > >>>> Nginx-B), которые и будут непосредственно проксировать на Unicorn. > >>> > >>> [...] > >>> > >>> А в чем необходимость Nginx-B стоять перед Unicorn-ом? > >>> Почему бы не проксировать с Nginx-A на Unicorn напрямую? > >> > >> Ребята из Github не советуют так делать: > >> http://stackoverflow.com/questions/14082243/unicorn-multiple-machines-se > >> tu p А если серьезно, то как в этом случае отдавать статику, если она не > >> на CDN? > > > > Дополнительный промежуточный nginx тоже добавляет оверхэда, и тут вопрос > > скорее в том, какой из них больше (от установки соединения между > > nginx-ом и unicorn по сети, или от дополнительного nginx-а с keepalive). > > оверхэд будет в любом случае, поэтому и нужна ваша помощь, как все > правильно сделать > > > А в чём проблема отдавать статику? Мне казалось, что создание помойки из > > кода и статики - это исключительно черта php-программистов, и у рубистов > > должно быть с этим всё в порядке, в том смысле, что отличить запрос к > > статике можно ещё на балансировщике без stat() (и проксировать далее, > > либо на nginx, либо на unicorn). > > помойки из кода и статики никакой нет, вся статика лежит отдельно как у > всех рубистов :) вопрос в том, как правильно ее отдавать - через 2 nginx-а > или деплоить статику на балансировщик? > У каждого решения есть свои плюсы и минусы, нужно смотреть конкретно в вашем случае, что будет удобнее. И вообще, что является узким местом на текущий момент. Возможно даже нужно пробовать и смотреть. Я бы стремился сократить количество звеньев в системе с одной стороны, и уменьшить количество единых точек отказа - с другой, децентрализовать. -- Валентин Бартенев http://nginx.org/en/donation.html From vbart at nginx.com Thu Mar 7 14:24:58 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 7 Mar 2013 18:24:58 +0400 Subject: =?UTF-8?B?UmU6ICDQn9C+0YHQvtCy0LXRgtGD0LnRgtC1INC60L7QvdGE0LjQsyBuZ2lueCA=?= =?UTF-8?B?0LTQu9GPINC+0YLQtNCw0YfQuCDQvtC00L3QvtCy0YDQtdC80LXQvdC90L4g?= =?UTF-8?B?MTDQuisg0YTQsNC50LvQvtCy?= In-Reply-To: References: <201303071601.37426.vbart@nginx.com> Message-ID: <201303071824.58261.vbart@nginx.com> On Thursday 07 March 2013 16:37:24 arty777 wrote: > Какие должны быт ьправильные настройки что б работало AIO (асинхронн) , > привидите пример конфига правильный, для линукс , с файловой системой ext4 > А вам он действительно нужен? В исходном сообщение вы пишите: "Необходимо максимально снизить ио на дисковую стойку ...". Если исходить из этой задачи, то AIO вам не нужен. Включение directio однозначно увеличит нагрузку на диск. А AIO на линуксе работает только с ним, и только ещё более усугубит ситуацию (увеличит нагрузку), увеличив конкуренцию за диск. > У меня ранее стояло 512 , сейчас 4К , и ошибок таких как не было так и нет Что лишний раз подтверждает, что выравнивания 512 вам достаточно. -- Валентин Бартенев http://nginx.org/en/donation.html From anatoly at sonru.com Thu Mar 7 14:54:56 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Thu, 7 Mar 2013 14:54:56 +0000 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: <201303071815.07552.vbart@nginx.com> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <201303071541.43901.vbart@nginx.com> <201303071815.07552.vbart@nginx.com> Message-ID: <919D9C02-2E9B-4ECB-AB8A-BAB8784C9B43@sonru.com> On Mar 7, 2013, at 2:15 PM, Валентин Бартенев wrote: > On Thursday 07 March 2013 16:26:03 Anatoly Mikhailov wrote: >> On Mar 7, 2013, at 11:41 AM, Валентин Бартенев wrote: >>> On Thursday 07 March 2013 15:03:59 Anatoly Mikhailov wrote: >>>> On Mar 7, 2013, at 9:54 AM, Валентин Бартенев wrote: >>>>> On Wednesday 06 March 2013 23:35:04 Anatoly Mikhailov wrote: >>>>>> добрый день, >>>>>> >>>>>> Вопрос балансировки нагрузки не дает мне покоя несколько дней, пока >>>>>> склоняюсь к использованию Nginx в роли балансировщика. Таким образом >>>>>> будет каскад Nginx - (Nginx - Unicorn) x 5. >>>>>> >>>>>> У нас связка Nginx+Unicorn на нескольких независимых серверах разного >>>>>> назначения (Main, Admin, API, Mobile-API), но сейчас, ввиду растущей >>>>>> нагрузки, есть необходимость основное (Main) приложение поставить за >>>>>> балансировщиком (условно Nginx-А), получив 5 бэк-энд серверов (условно >>>>>> Nginx-B), которые и будут непосредственно проксировать на Unicorn. >>>>> >>>>> [...] >>>>> >>>>> А в чем необходимость Nginx-B стоять перед Unicorn-ом? >>>>> Почему бы не проксировать с Nginx-A на Unicorn напрямую? >>>> >>>> Ребята из Github не советуют так делать: >>>> http://stackoverflow.com/questions/14082243/unicorn-multiple-machines-se >>>> tu p А если серьезно, то как в этом случае отдавать статику, если она не >>>> на CDN? >>> >>> Дополнительный промежуточный nginx тоже добавляет оверхэда, и тут вопрос >>> скорее в том, какой из них больше (от установки соединения между >>> nginx-ом и unicorn по сети, или от дополнительного nginx-а с keepalive). >> >> оверхэд будет в любом случае, поэтому и нужна ваша помощь, как все >> правильно сделать >> >>> А в чём проблема отдавать статику? Мне казалось, что создание помойки из >>> кода и статики - это исключительно черта php-программистов, и у рубистов >>> должно быть с этим всё в порядке, в том смысле, что отличить запрос к >>> статике можно ещё на балансировщике без stat() (и проксировать далее, >>> либо на nginx, либо на unicorn). >> >> помойки из кода и статики никакой нет, вся статика лежит отдельно как у >> всех рубистов :) вопрос в том, как правильно ее отдавать - через 2 nginx-а >> или деплоить статику на балансировщик? >> > > У каждого решения есть свои плюсы и минусы, нужно смотреть конкретно в вашем > случае, что будет удобнее. И вообще, что является узким местом на текущий > момент. Возможно даже нужно пробовать и смотреть. > > Я бы стремился сократить количество звеньев в системе с одной стороны, и > уменьшить количество единых точек отказа - с другой, децентрализовать. > да, абсолютно согласен, уменьшить SPoF - это, пожалуй, главная моя задача, даже если это будет менее эффективно с точки зрения производительности. Идея с каскадными Nginx-ами мне нравится потому что: - Nginx-A делает только проксирование всех запросов на массив серверов из Nginx-B - Nginx-A осуществляется SSL-offload - при обновлении SSL-xсертификата надо будет обновить его только на Nginx-A - массив Nginx-B - самостоятельные сервера, на каждом из них точная копия кода и статики - имея 2 Nginx-A можно сделать перекрестную балансировку из 4-серверов, получаем 0 SPoF в данной случае с приложением (балансировку базы я не затрагиваю, это отдельный вопрос) Есть ли какие-то особенности в настройках keepalive на upstream, proxy_pass и на самих серверах? В среднем между запросами одного клиента проходит 1-20 секунд. Что думаете о такой конфигурации: [Nginx-A] http { ssl ? # no gzip settings keepalive_timeout 70; upstream backend { server 10.0.0.1:8080; # Nginx-B server 10.0.0.2:8080; # Nginx-B keepalive 70; } server { location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $http_host; proxy_redirect off; proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ""; } } } [Nginx-B] http { gzip ? # no ssl settings keepalive_timeout 70; upstream unicorn { server unix:/tmp/unicorn.production.main.sock fail_timeout=0; # no timeout here, because Unicorn is stateless itself } server { location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $http_host; proxy_redirect off; proxy_pass http://unicorn; } location ~ ^/(assets|images|javascripts|stylesheets|swfs|system)/ { # settings to serve static assets } } } Анатолий > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Thu Mar 7 15:31:35 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 7 Mar 2013 19:31:35 +0400 Subject: =?UTF-8?B?UmU6ICDQutCw0YHQutCw0LQg0L/RgNC+0LrRgdC40YDRg9GO0YnQuNGFINGB0LU=?= =?UTF-8?B?0YDQstC10YDQvtCy?= In-Reply-To: <919D9C02-2E9B-4ECB-AB8A-BAB8784C9B43@sonru.com> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <201303071815.07552.vbart@nginx.com> <919D9C02-2E9B-4ECB-AB8A-BAB8784C9B43@sonru.com> Message-ID: <201303071931.35635.vbart@nginx.com> On Thursday 07 March 2013 18:54:56 Anatoly Mikhailov wrote: [...] > Есть ли какие-то особенности в настройках keepalive на upstream, proxy_pass > и на самих серверах? В среднем между запросами одного клиента проходит > 1-20 секунд. Что думаете о такой конфигурации: > > [Nginx-A] > http { > ssl ? > # no gzip settings > keepalive_timeout 70; > > upstream backend { > server 10.0.0.1:8080; # Nginx-B > server 10.0.0.2:8080; # Nginx-B > keepalive 70; Я бы тут поставил worker_connections at nginx-B * worker_processes at nginx-B / 2. Но не зная полностью вашей ситуации - это исключительно "пальцем в небо". > } > > server { > location / { > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header X-Forwarded-Proto $scheme; > proxy_set_header Host $http_host; > proxy_redirect off; > proxy_pass http://backend; > proxy_http_version 1.1; > proxy_set_header Connection ""; > } > } > } > > > [Nginx-B] > http { > gzip ? > # no ssl settings > keepalive_timeout 70; А тут минут 5. (и опять же, см. отговорку выше) > > upstream unicorn { > server unix:/tmp/unicorn.production.main.sock > fail_timeout=0; # no timeout here, because Unicorn is stateless itself > } Тут какая-то бессмыслица написана. Рекомендую прочитать описание параметра "fail_timeout": http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#server > > server { > location / { > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header X-Forwarded-Proto $scheme; > proxy_set_header Host $http_host; > proxy_redirect off; > proxy_pass http://unicorn; > } > location ~ ^/(assets|images|javascripts|stylesheets|swfs|system)/ { > # settings to serve static assets > } > } > } > -- Валентин Бартенев http://nginx.org/en/donation.html From anatoly at sonru.com Thu Mar 7 15:39:27 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Thu, 7 Mar 2013 15:39:27 +0000 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: <201303071931.35635.vbart@nginx.com> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <201303071815.07552.vbart@nginx.com> <919D9C02-2E9B-4ECB-AB8A-BAB8784C9B43@sonru.com> <201303071931.35635.vbart@nginx.com> Message-ID: <7E9D4728-13B7-4478-AE34-AD53DA87761B@sonru.com> On Mar 7, 2013, at 3:31 PM, Валентин Бартенев wrote: > On Thursday 07 March 2013 18:54:56 Anatoly Mikhailov wrote: > [...] >> Есть ли какие-то особенности в настройках keepalive на upstream, proxy_pass >> и на самих серверах? В среднем между запросами одного клиента проходит >> 1-20 секунд. Что думаете о такой конфигурации: >> >> [Nginx-A] >> http { >> ssl ? >> # no gzip settings >> keepalive_timeout 70; >> >> upstream backend { >> server 10.0.0.1:8080; # Nginx-B >> server 10.0.0.2:8080; # Nginx-B >> keepalive 70; > > Я бы тут поставил worker_connections at nginx-B * worker_processes at nginx-B / 2. > > Но не зная полностью вашей ситуации - это исключительно "пальцем в небо". > >> } >> >> server { >> location / { >> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >> proxy_set_header X-Forwarded-Proto $scheme; >> proxy_set_header Host $http_host; >> proxy_redirect off; >> proxy_pass http://backend; >> proxy_http_version 1.1; >> proxy_set_header Connection ""; >> } >> } >> } >> >> >> [Nginx-B] >> http { >> gzip ? >> # no ssl settings >> keepalive_timeout 70; > > А тут минут 5. (и опять же, см. отговорку выше) > >> >> upstream unicorn { >> server unix:/tmp/unicorn.production.main.sock >> fail_timeout=0; # no timeout here, because Unicorn is stateless itself >> } > > Тут какая-то бессмыслица написана. > > Рекомендую прочитать описание параметра "fail_timeout": > http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#server конечно же речь шла о keepalive для Unicorn и мы это с вами уже обсуждали :) http://stackoverflow.com/questions/11321790/keepalived-upstream-connection-to-unicorn-via-socket > >> >> server { >> location / { >> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >> proxy_set_header X-Forwarded-Proto $scheme; >> proxy_set_header Host $http_host; >> proxy_redirect off; >> proxy_pass http://unicorn; >> } >> location ~ ^/(assets|images|javascripts|stylesheets|swfs|system)/ { >> # settings to serve static assets >> } >> } >> } >> > Спасибо за помощь, пошел настраивать! > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Thu Mar 7 15:45:46 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 7 Mar 2013 19:45:46 +0400 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: <201303071931.35635.vbart@nginx.com> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <201303071815.07552.vbart@nginx.com> <919D9C02-2E9B-4ECB-AB8A-BAB8784C9B43@sonru.com> <201303071931.35635.vbart@nginx.com> Message-ID: <20130307154546.GJ15378@mdounin.ru> Hello! On Thu, Mar 07, 2013 at 07:31:35PM +0400, Валентин Бартенев wrote: > On Thursday 07 March 2013 18:54:56 Anatoly Mikhailov wrote: > [...] > > Есть ли какие-то особенности в настройках keepalive на upstream, proxy_pass > > и на самих серверах? В среднем между запросами одного клиента проходит > > 1-20 секунд. Что думаете о такой конфигурации: > > > > [Nginx-A] > > http { > > ssl ? > > # no gzip settings > > keepalive_timeout 70; > > > > upstream backend { > > server 10.0.0.1:8080; # Nginx-B > > server 10.0.0.2:8080; # Nginx-B > > keepalive 70; > > Я бы тут поставил worker_connections at nginx-B * worker_processes at nginx-B / 2. > > Но не зная полностью вашей ситуации - это исключительно "пальцем в небо". Много тут ставить нет смысла - это размер кеша соединений, и общее количество соединений от него никак не зависит. А приведённая формула - плохая, потому как каждый рабочий процесс nginx-A может попытаться сохранить в кеше указанное число соединений. В случае nginx'а плохого не будет (ибо при нехватке соединений - keepalive-соединения автоматически закрываются), но и смысла в этом нет. Я бы рекомендовал полученное число разделить на worker_processes at nginx-A и использовать как верхнюю планку, за которую не следует вылезать. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Mar 7 15:53:10 2013 From: nginx-forum at nginx.us (arty777) Date: Thu, 07 Mar 2013 10:53:10 -0500 Subject: =?UTF-8?B?UmU6INCf0L7RgdC+0LLQtdGC0YPQudGC0LUg0LrQvtC90YTQuNCzIG5naW54INC0?= =?UTF-8?B?0LvRjyDQvtGC0LTQsNGH0Lgg0L7QtNC90L7QstGA0LXQvNC10L3QvdC+IDEw?= =?UTF-8?B?0LorINGE0LDQudC70L7Qsg==?= In-Reply-To: <201303071824.58261.vbart@nginx.com> References: <201303071824.58261.vbart@nginx.com> Message-ID: <1c1eda3b2059b2c572e26d086c1ea188.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Thursday 07 March 2013 16:37:24 arty777 wrote: > > Какие должны быт ьправильные настройки что б работало AIO > (асинхронн) , > > привидите пример конфига правильный, для линукс , с файловой > системой ext4 > > > > А вам он действительно нужен? > > В исходном сообщение вы пишите: "Необходимо максимально снизить ио на > дисковую > стойку ...". > > Если исходить из этой задачи, то AIO вам не нужен. Включение directio > однозначно > увеличит нагрузку на диск. А AIO на линуксе работает только с ним, и > только ещё > более усугубит ситуацию (увеличит нагрузку), увеличив конкуренцию за > диск. > > > У меня ранее стояло 512 , сейчас 4К , и ошибок таких как не было > так и нет > > Что лишний раз подтверждает, что выравнивания 512 вам достаточно. Вообще заккоментировал в конфиге строку #directio_alignment 4K; Еще лучше стало!! Нагрузки диски стали большие выдерживать , супер . Итого конфиг такой : #Вкл aync io aio on; directio 512; # включаем O_DIRECT для файлов, размером 512 kбайт или больше #directio_alignment 4K; output_buffers 1 512k; Я всегда думал что AIO улучшает работу , производительность дисковой подсистемы . Какой же в нем плюс тогда? С таким вариантом конфига как я показал , aio не работает у меня получается? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,216159,237076#msg-237076 From vbart at nginx.com Thu Mar 7 16:03:05 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 7 Mar 2013 20:03:05 +0400 Subject: =?UTF-8?B?UmU6ICDQutCw0YHQutCw0LQg0L/RgNC+0LrRgdC40YDRg9GO0YnQuNGFINGB0LU=?= =?UTF-8?B?0YDQstC10YDQvtCy?= In-Reply-To: <7E9D4728-13B7-4478-AE34-AD53DA87761B@sonru.com> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <201303071931.35635.vbart@nginx.com> <7E9D4728-13B7-4478-AE34-AD53DA87761B@sonru.com> Message-ID: <201303072003.05819.vbart@nginx.com> On Thursday 07 March 2013 19:39:27 Anatoly Mikhailov wrote: [...] > >> upstream unicorn { > >> > >> server unix:/tmp/unicorn.production.main.sock > >> > >> fail_timeout=0; # no timeout here, because Unicorn is stateless itself > >> > >> } > > > > Тут какая-то бессмыслица написана. > > > > Рекомендую прочитать описание параметра "fail_timeout": > > http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#server > > конечно же речь шла о keepalive для Unicorn и мы это с вами уже обсуждали > :) > http://stackoverflow.com/questions/11321790/keepalived-upstream-connection > -to-unicorn-via-socket > Так всё-таки, почитайте описание параметра "fail_timeout", он к keepalive ровно никакого отношения не имеет. =) -- Валентин Бартенев http://nginx.org/en/donation.html From neo at miritec.com Thu Mar 7 16:09:28 2013 From: neo at miritec.com (=?KOI8-R?B?4NLJyiDnz87ewdLP1w==?=) Date: Thu, 7 Mar 2013 18:09:28 +0200 Subject: =?UTF-8?B?0KDQtdCz0LXQutGB0L/QvtCy0YvQuSBzZXJ2ZXJfbmFtZQ==?= Message-ID: Здравствуйте есть инфраструктура /lab/user1/project1 /lab/user1/project1 /lab/user1/project1 /lab/user1/project1 -- NEO83-RIPE -------------- next part -------------- An HTML attachment was scrubbed... URL: From neo at miritec.com Thu Mar 7 16:12:09 2013 From: neo at miritec.com (=?KOI8-R?B?4NLJyiDnz87ewdLP1w==?=) Date: Thu, 7 Mar 2013 18:12:09 +0200 Subject: =?UTF-8?B?RndkOiDQoNC10LPQtdC60YHQv9C+0LLRi9C5IHNlcnZlcl9uYW1l?= In-Reply-To: References: Message-ID: Здравствуйте есть инфраструктура /lab/user1/project1 /lab/user1/project2 /lab/user1/project3 /lab/user1/project4 /lab/user2/someproject1 /lab/user2/someproject2 и т д Есть ли возможность в nginx для каждого user1 создавать один умный server_name и root для работы...что-то типа server { listen 80; server_name $project.user1.lab.domain.com; location / { root /lab/user1/$project; } } Или все же писать скрипты которые будут генерить конфиги? Спасибо! -- NEO83-RIPE -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Thu Mar 7 16:15:06 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 7 Mar 2013 20:15:06 +0400 Subject: =?UTF-8?B?UmU6INCf0L7RgdC+0LLQtdGC0YPQudGC0LUg0LrQvtC90YTQuNCzIG5naW54INC0?= =?UTF-8?B?0LvRjyDQvtGC0LTQsNGH0Lgg0L7QtNC90L7QstGA0LXQvNC10L3QvdC+IDEw?= =?UTF-8?B?0LorINGE0LDQudC70L7Qsg==?= In-Reply-To: <1c1eda3b2059b2c572e26d086c1ea188.NginxMailingListRussian@forum.nginx.org> References: <201303071824.58261.vbart@nginx.com> <1c1eda3b2059b2c572e26d086c1ea188.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130307161506.GK15378@mdounin.ru> Hello! On Thu, Mar 07, 2013 at 10:53:10AM -0500, arty777 wrote: > Валентин Бартенев Wrote: > ------------------------------------------------------- > > On Thursday 07 March 2013 16:37:24 arty777 wrote: > > > Какие должны быт ьправильные настройки что б работало AIO > > (асинхронн) , > > > привидите пример конфига правильный, для линукс , с файловой > > системой ext4 > > > > > > > А вам он действительно нужен? > > > > В исходном сообщение вы пишите: "Необходимо максимально снизить ио на > > дисковую > > стойку ...". > > > > Если исходить из этой задачи, то AIO вам не нужен. Включение directio > > однозначно > > увеличит нагрузку на диск. А AIO на линуксе работает только с ним, и > > только ещё > > более усугубит ситуацию (увеличит нагрузку), увеличив конкуренцию за > > диск. > > > > > У меня ранее стояло 512 , сейчас 4К , и ошибок таких как не было > > так и нет > > > > Что лишний раз подтверждает, что выравнивания 512 вам достаточно. > > > Вообще заккоментировал в конфиге строку #directio_alignment 4K; > > Еще лучше стало!! Нагрузки диски стали большие выдерживать , супер . Закоментировать - это то же самое, что 512. Соответственно имеем бесконечную возможность для улучшения производительности - достаточно менять 512 на 4k и обратно, любое действие у вас улучшает ситуацию. :) > Итого конфиг такой : > #Вкл aync io > aio on; > directio 512; # включаем O_DIRECT для файлов, размером 512 kбайт или > больше > #directio_alignment 4K; > output_buffers 1 512k; > > Я всегда думал что AIO улучшает работу , производительность дисковой > подсистемы . Какой же в нем плюс тогда? > С таким вариантом конфига как я показал , aio не работает у меня получается? AIO - позволяет поднять конкурентность доступа к диску, обеспечивая асинхронную работу с ним, что в свою очередь позволяет использовать дисковую подсистему более эффективно (что совсем не то же самое, что "снизить ио"). При этом на линуксе aio означает необходимость запрета page cache'а (== directio), и в зависимости от исходной эффективности оного кеша - может улучшить или ухудшить ситуацию в целом. Идея о том, что "AIO улучшает" - она скорее всего связана с тем, что если у людей наблюдаются проблемы с дисковой подсистемой - то это обычно означает, что в их случае - эффективность page cache'а низкая, и включение aio ситуацию скорее всего улучшит. -- Maxim Dounin http://nginx.org/en/donation.html From vbart at nginx.com Thu Mar 7 16:23:17 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 7 Mar 2013 20:23:17 +0400 Subject: =?UTF-8?B?UmU6ICDQn9C+0YHQvtCy0LXRgtGD0LnRgtC1INC60L7QvdGE0LjQsyBuZ2lueCA=?= =?UTF-8?B?0LTQu9GPINC+0YLQtNCw0YfQuCDQvtC00L3QvtCy0YDQtdC80LXQvdC90L4g?= =?UTF-8?B?MTDQuisg0YTQsNC50LvQvtCy?= In-Reply-To: <1c1eda3b2059b2c572e26d086c1ea188.NginxMailingListRussian@forum.nginx.org> References: <201303071824.58261.vbart@nginx.com> <1c1eda3b2059b2c572e26d086c1ea188.NginxMailingListRussian@forum.nginx.org> Message-ID: <201303072023.17725.vbart@nginx.com> On Thursday 07 March 2013 19:53:10 arty777 wrote: > > Вообще заккоментировал в конфиге строку #directio_alignment 4K; > Закомментированная/отсутствующая директива "directio_alignment" эквивалентна: directio_alignment 512; Это её значение по умолчанию (см. http://nginx.org/r/directio_alignment/ru ). > Еще лучше стало!! Нагрузки диски стали большие выдерживать , супер . > Бессмысленно измерять нагрузку на диски безотносительно получаемой пропускной способности. У вас нагрузка на диски может возрасти, а объем отдаваемых данных снизиться. > > Итого конфиг такой : > #Вкл aync io > aio on; > directio 512; # включаем O_DIRECT для файлов, размером 512 kбайт > или больше Это было бы так, если бы было написано 512k или 512K. А в данном случае, вы включили O_DIRECT для файлов от 512 *байт*. > #directio_alignment 4K; > output_buffers 1 512k; > > Я всегда думал что AIO улучшает работу , производительность дисковой > подсистемы . Какой же в нем плюс тогда? AIO нужен чтобы nginx не блокировался на чтении с диска, что особенно негативно сказывается на его производительности (nginx-а, а не диска). > С таким вариантом конфига как я показал , aio не работает у меня > получается? > С таким (от 512 байт и выше), пожалуй только AIO с O_DIRECT и используется. -- Валентин Бартенев http://nginx.org/en/donation.html From vbart at nginx.com Thu Mar 7 16:31:06 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 7 Mar 2013 20:31:06 +0400 Subject: =?UTF-8?B?UmU6IEZ3ZDog0KDQtdCz0LXQutGB0L/QvtCy0YvQuSBzZXJ2ZXJfbmFtZQ==?= In-Reply-To: References: Message-ID: <201303072031.06617.vbart@nginx.com> On Thursday 07 March 2013 20:12:09 Юрий Гончаров wrote: > Здравствуйте > > есть инфраструктура > > /lab/user1/project1 > /lab/user1/project2 > /lab/user1/project3 > /lab/user1/project4 > /lab/user2/someproject1 > /lab/user2/someproject2 > > и т д > > Есть ли возможность в nginx для каждого user1 создавать один умный > server_name и root для работы...что-то типа > > server { > listen 80; > server_name $project.user1.lab.domain.com; > location / > { > root /lab/user1/$project; > } > } > > > Или все же писать скрипты которые будут генерить конфиги? > Писать скрипты. -- Валентин Бартенев http://nginx.org/en/donation.html From onokonem at gmail.com Thu Mar 7 17:05:01 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 7 Mar 2013 20:05:01 +0300 Subject: =?UTF-8?B?UmU6IEZ3ZDog0KDQtdCz0LXQutGB0L/QvtCy0YvQuSBzZXJ2ZXJfbmFtZQ==?= In-Reply-To: <201303072031.06617.vbart@nginx.com> References: <201303072031.06617.vbart@nginx.com> Message-ID: > Писать скрипты. А есть ли замеры того, сколько ест одна конфигурация, и другая? Я вот довольно широко регексмы использую (но у меня иначе и никак). From alexey.bondar at gmail.com Thu Mar 7 17:10:35 2013 From: alexey.bondar at gmail.com (Bondar Alexey) Date: Thu, 7 Mar 2013 18:10:35 +0100 Subject: =?UTF-8?B?UmU6INCg0LXQs9C10LrRgdC/0L7QstGL0Lkgc2VydmVyX25hbWU=?= In-Reply-To: References: Message-ID: <17CB9E77-2031-4F9C-814E-FA223DEA7D9B@gmail.com> server { listen 80; server_name ~^(?.+)\.(?.+)\.example\.net$; root /var/www/$user/$project/public; } Как следствие project1.user1.example.net => /var/www/user1/project1/public Или я не понял вопроса? On 7 Mar 2013, at 17:12, Юрий Гончаров wrote: > Здравствуйте > > есть инфраструктура > > /lab/user1/project1 > /lab/user1/project2 > /lab/user1/project3 > /lab/user1/project4 > /lab/user2/someproject1 > /lab/user2/someproject2 > > и т д > > Есть ли возможность в nginx для каждого user1 создавать один умный server_name и root для работы...что-то типа > > server { > listen 80; > server_name $project.user1.lab.domain.com; > location / > { > root /lab/user1/$project; > } > } > > > Или все же писать скрипты которые будут генерить конфиги? > > Спасибо! > > -- > NEO83-RIPE > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4364 bytes Desc: not available URL: From vbart at nginx.com Thu Mar 7 17:15:24 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 7 Mar 2013 21:15:24 +0400 Subject: =?UTF-8?B?UmU6IEZ3ZDog0KDQtdCz0LXQutGB0L/QvtCy0YvQuSBzZXJ2ZXJfbmFtZQ==?= In-Reply-To: References: <201303072031.06617.vbart@nginx.com> Message-ID: <201303072115.24661.vbart@nginx.com> On Thursday 07 March 2013 21:05:01 Daniel Podolsky wrote: > > Писать скрипты. > > А есть ли замеры того, сколько ест одна конфигурация, и другая? Я вот > довольно широко регексмы использую (но у меня иначе и никак). Если я правильно понял вопрос, то это зависит от самой конфигурации и количества модулей, с которыми скомпилирован nginx. Каких-то точных чисел тут быть не может. -- Валентин Бартенев http://nginx.org/en/donation.html From onokonem at gmail.com Thu Mar 7 17:44:28 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 7 Mar 2013 20:44:28 +0300 Subject: =?UTF-8?B?UmU6IEZ3ZDog0KDQtdCz0LXQutGB0L/QvtCy0YvQuSBzZXJ2ZXJfbmFtZQ==?= In-Reply-To: <201303072115.24661.vbart@nginx.com> References: <201303072031.06617.vbart@nginx.com> <201303072115.24661.vbart@nginx.com> Message-ID: >> > Писать скрипты. >> А есть ли замеры того, сколько ест одна конфигурация, и другая? Я вот >> довольно широко регексмы использую (но у меня иначе и никак). > Если я правильно понял вопрос, то это зависит от самой конфигурации > и количества модулей, с которыми скомпилирован nginx. Каких-то точных > чисел тут быть не может. я скорее не про точные числа, а про сравнение производительности конфигурации на регекспах с конфигурацией на статических именах. что-то мне подсказывает, что разбор заголовков - достаточно тяжелая операция, чтобы один регехп на этом фоне просто потерялся. From nginx-forum at nginx.us Fri Mar 8 10:16:21 2013 From: nginx-forum at nginx.us (bozercov) Date: Fri, 08 Mar 2013 05:16:21 -0500 Subject: =?UTF-8?B?0KHRgtGA0LDQvdC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUgdXBzdHJlYW0gc2Vu?= =?UTF-8?B?dCB0b28gYmlnIGhlYWRlcg==?= Message-ID: <4a3f92b2ffbc4b93c9d4d7246146472f.NginxMailingListRussian@forum.nginx.org> При попытке перехода на отдельные страницы выдаёт ошибку 502 и в логах: 2013/03/08 13:03:06 [error] 9287#0: *10 upstream sent too big header while reading response header from upstream, client: 192.168.137.1, server: example.com, request: "GET /news/new HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "example.com", referrer: "http://example.com/news/" Пробывал добавлять fastcgi_buffer_size 256k; fastcgi_buffers 8 16k; Ничего не изменилось. Конфиг целиком server { listen 80; server_name example.com; root /home/developer/dev/projects/example.com/web; error_log /var/log/nginx/example.com.error.log; access_log /var/log/nginx/example.com.access.log; # strip app.php/ prefix if it is present rewrite ^/index\.php/?(.*)$ /$1 permanent; location / { index app_dev.php; try_files $uri @rewriteapp; } location @rewriteapp { rewrite ^(.*)$ /app_dev.php/$1 last; } # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 location ~ ^/.+\.php(/|$) { fastcgi_buffer_size 256k; fastcgi_buffers 8 16k; fastcgi_pass 127.0.0.1:9000; fastcgi_split_path_info ^(.+\.php)(/.*)$; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param HTTPS off; } } Что интересно, так это то, что ошибка возникает только если с хрома заходить. Если зайти с другого, то данная ошибка не появляется. Подскажите, куда копать? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237114,237114#msg-237114 From nginx-forum at nginx.us Fri Mar 8 11:14:40 2013 From: nginx-forum at nginx.us (Namaste) Date: Fri, 08 Mar 2013 06:14:40 -0500 Subject: =?UTF-8?B?0J/RgNC40L3Rg9C00LjRgtC10LvRjNC90L4g0L7QsdC90L7QstC40YLRjCDRgdGC?= =?UTF-8?B?0YDQsNC90LjRhtGDINCyINC60Y3RiNC1?= Message-ID: <597f31f0b2fc51839286d9b6c95a5ea4.NginxMailingListRussian@forum.nginx.org> Привет! Юзаю fastcgi_cache. Можно как-то принудительно обновить в нем определенную страницу? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237117,237117#msg-237117 From vovansystems at gmail.com Fri Mar 8 11:32:47 2013 From: vovansystems at gmail.com (VovansystemS) Date: Fri, 8 Mar 2013 14:32:47 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQuNC90YPQtNC40YLQtdC70YzQvdC+INC+0LHQvdC+0LLQuNGC0Ywg?= =?UTF-8?B?0YHRgtGA0LDQvdC40YbRgyDQsiDQutGN0YjQtQ==?= In-Reply-To: <597f31f0b2fc51839286d9b6c95a5ea4.NginxMailingListRussian@forum.nginx.org> References: <597f31f0b2fc51839286d9b6c95a5ea4.NginxMailingListRussian@forum.nginx.org> Message-ID: Добрый день! Чтобы обновить страницу в кеше, необходимо сначала удалить из кеша устаревшую версию. Для этого необходимо по ключу удалить соотвествующий элемент директивой fastcgi_cache_purge модуля ngx_cache_purge ( http://wiki.nginx.org/CachePurgeChs ). 2013/3/8 Namaste : > Привет! > > Юзаю fastcgi_cache. Можно как-то принудительно обновить в нем определенную > страницу? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237117,237117#msg-237117 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From denis at webmaster.spb.ru Fri Mar 8 11:58:51 2013 From: denis at webmaster.spb.ru (denis) Date: Fri, 08 Mar 2013 15:58:51 +0400 Subject: =?UTF-8?B?UmU6IEZ3ZDog0KDQtdCz0LXQutGB0L/QvtCy0YvQuSBzZXJ2ZXJfbmFtZQ==?= In-Reply-To: References: <201303072031.06617.vbart@nginx.com> <201303072115.24661.vbart@nginx.com> Message-ID: <5139D27B.7080701@webmaster.spb.ru> 07.03.2013 21:44, Daniel Podolsky пишет: > я скорее не про точные числа, а про сравнение производительности > конфигурации на регекспах с конфигурацией на статических именах. > > что-то мне подсказывает, что разбор заголовков - достаточно тяжелая > операция, чтобы один регехп на этом фоне просто потерялся. Скорее наоборот, разбор заголовков достаточно быстрый, а вот регэкспы могут быть тяжелыми. Но это имхо, тут лучше у Сысоева спросить. Просто нужно еще понимать, какая нагрузка на эти проекты, и если даже 100 человек в день - это немного, можно не заморачиваться и делать как удобнее, а если тысячи - лучше написать скрипт-генератор конфига, причём 90% текста там может быть подключаемо через include. Можно комбинировать и часть сайтов подключать напрямую, часть через регэкспы, но помнить некоторые особенности их обработки, я с этим сталкивался ( http://dragonflybsd.blogspot.ru/2012/07/nginx-regex-servername.html ) From vbart at nginx.com Fri Mar 8 13:47:57 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 8 Mar 2013 17:47:57 +0400 Subject: =?UTF-8?B?UmU6IEZ3ZDog0KDQtdCz0LXQutGB0L/QvtCy0YvQuSBzZXJ2ZXJfbmFtZQ==?= In-Reply-To: References: <201303072115.24661.vbart@nginx.com> Message-ID: <201303081747.57914.vbart@nginx.com> On Thursday 07 March 2013 21:44:28 Daniel Podolsky wrote: > >> > Писать скрипты. > >> > >> А есть ли замеры того, сколько ест одна конфигурация, и другая? Я вот > >> довольно широко регексмы использую (но у меня иначе и никак). > > > > Если я правильно понял вопрос, то это зависит от самой конфигурации > > и количества модулей, с которыми скомпилирован nginx. Каких-то точных > > чисел тут быть не может. > > я скорее не про точные числа, а про сравнение производительности > конфигурации на регекспах с конфигурацией на статических именах. > > что-то мне подсказывает, что разбор заголовков - достаточно тяжелая > операция, чтобы один регехп на этом фоне просто потерялся. Один регэксп у вас повлечет кучу логики с переменными из него. Речь идет не о том, что быстрее, а о том, что не нужно программировать на конфигах и поддерживать несколько простых конфигураций проще, чем одну с кучей сложной логики. -- Валентин Бартенев http://nginx.org/en/donation.html From vbart at nginx.com Fri Mar 8 13:53:30 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 8 Mar 2013 17:53:30 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQuNC90YPQtNC40YLQtdC70YzQvdC+INC+0LHQvdC+0LLQuNGC0Ywg?= =?UTF-8?B?0YHRgtGA0LDQvdC40YbRgyDQsiDQutGN0YjQtQ==?= In-Reply-To: <597f31f0b2fc51839286d9b6c95a5ea4.NginxMailingListRussian@forum.nginx.org> References: <597f31f0b2fc51839286d9b6c95a5ea4.NginxMailingListRussian@forum.nginx.org> Message-ID: <201303081753.30332.vbart@nginx.com> On Friday 08 March 2013 15:14:40 Namaste wrote: > Привет! > > Юзаю fastcgi_cache. Можно как-то принудительно обновить в нем определенную > страницу? > См. директиву proxy_cache_bypass. http://nginx.org/r/proxy_cache_bypass/ru -- Валентин Бартенев http://nginx.org/en/donation.html From vbart at nginx.com Fri Mar 8 14:13:09 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 8 Mar 2013 18:13:09 +0400 Subject: =?UTF-8?B?UmU6ICDQodGC0YDQsNC90L3QvtC1INC/0L7QstC10LTQtdC90LjQtSB1cHN0cmVh?= =?UTF-8?B?bSBzZW50IHRvbyBiaWcgaGVhZGVy?= In-Reply-To: <4a3f92b2ffbc4b93c9d4d7246146472f.NginxMailingListRussian@forum.nginx.org> References: <4a3f92b2ffbc4b93c9d4d7246146472f.NginxMailingListRussian@forum.nginx.org> Message-ID: <201303081813.09290.vbart@nginx.com> On Friday 08 March 2013 14:16:21 bozercov wrote: > При попытке перехода на отдельные страницы выдаёт ошибку 502 и в логах: > > 2013/03/08 13:03:06 [error] 9287#0: *10 upstream sent too big header while > reading response header from upstream, client: 192.168.137.1, server: > example.com, request: "GET /news/new HTTP/1.1", upstream: > "fastcgi://127.0.0.1:9000", host: "example.com", referrer: > "http://example.com/news/" > > Пробывал добавлять > fastcgi_buffer_size 256k; > fastcgi_buffers 8 16k; > Ничего не изменилось. > Конфиг целиком > server { > listen 80; > > server_name example.com; > root /home/developer/dev/projects/example.com/web; > > error_log /var/log/nginx/example.com.error.log; > access_log /var/log/nginx/example.com.access.log; > > > # strip app.php/ prefix if it is present > rewrite ^/index\.php/?(.*)$ /$1 permanent; > > location / { > index app_dev.php; > try_files $uri @rewriteapp; > } > > location @rewriteapp { > rewrite ^(.*)$ /app_dev.php/$1 last; > } > > # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 > location ~ ^/.+\.php(/|$) { > fastcgi_buffer_size 256k; > fastcgi_buffers 8 16k; > fastcgi_pass 127.0.0.1:9000; > fastcgi_split_path_info ^(.+\.php)(/.*)$; > include fastcgi_params; > fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; > fastcgi_param HTTPS off; > } > } > > > Что интересно, так это то, что ошибка возникает только если с хрома > заходить. Если зайти с другого, то данная ошибка не появляется. > > Подскажите, куда копать? > Видимо ваш бэкенд в этом случае выдает заголовок ещё больше чем 256 Кб. -- Валентин Бартенев http://nginx.org/en/donation.html From vovansystems at gmail.com Fri Mar 8 15:02:01 2013 From: vovansystems at gmail.com (VovansystemS) Date: Fri, 8 Mar 2013 18:02:01 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQuNC90YPQtNC40YLQtdC70YzQvdC+INC+0LHQvdC+0LLQuNGC0Ywg?= =?UTF-8?B?0YHRgtGA0LDQvdC40YbRgyDQsiDQutGN0YjQtQ==?= In-Reply-To: <201303081753.30332.vbart@nginx.com> References: <597f31f0b2fc51839286d9b6c95a5ea4.NginxMailingListRussian@forum.nginx.org> <201303081753.30332.vbart@nginx.com> Message-ID: > См. директиву proxy_cache_bypass. > http://nginx.org/r/proxy_cache_bypass/ru а я всегда ошибчно полагал, что такой ответ не будет помещён в кэш независимо от директивы proxy_no_cache. только теперь понял, что ответ будет браться не из кэша, но сам закэшируется, спасибо. так что мой вариант приведённый выше конечно хоть рабочий, но его не стоит использовать в данном случае. 2013/3/8 Валентин Бартенев : > On Friday 08 March 2013 15:14:40 Namaste wrote: >> Привет! >> >> Юзаю fastcgi_cache. Можно как-то принудительно обновить в нем определенную >> страницу? >> > > См. директиву proxy_cache_bypass. > > http://nginx.org/r/proxy_cache_bypass/ru > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From postmaster at softsearch.ru Fri Mar 8 15:19:55 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 8 Mar 2013 19:19:55 +0400 Subject: =?UTF-8?B?UmVbMl06INCf0YDQuNC90YPQtNC40YLQtdC70YzQvdC+INC+0LHQvdC+0LLQuNGC?= =?UTF-8?B?0Ywg0YHRgtGA0LDQvdC40YbRgyDQsiDQutGN0YjQtQ==?= In-Reply-To: References: <597f31f0b2fc51839286d9b6c95a5ea4.NginxMailingListRussian@forum.nginx.org> <201303081753.30332.vbart@nginx.com> Message-ID: <50302274.20130308191955@softsearch.ru> Здравствуйте, VovansystemS. >> См. директиву proxy_cache_bypass. >> http://nginx.org/r/proxy_cache_bypass/ru > а я всегда ошибчно полагал, что такой ответ не будет помещён в кэш > независимо от директивы proxy_no_cache. только теперь понял, что > ответ будет браться не из кэша, но сам закэшируется, спасибо. Жаль, что эта мысль не отражена в документации, ибо допетрить до того, что через proxy_cache_bypass можно элементы кэша удалять - это совсем не тривиальный ход мыслей. -- С уважением, Михаил mailto:postmaster at softsearch.ru From postmaster at softsearch.ru Fri Mar 8 16:05:15 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 8 Mar 2013 20:05:15 +0400 Subject: =?UTF-8?B?UmVbMl06INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YE=?= =?UTF-8?B?0LXRgNCy0LXRgNC+0LI=?= In-Reply-To: References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <201303071354.22491.vbart@nginx.com> <92C91BDB-9821-4741-A737-4117621044B2@sonru.com> <201303071541.43901.vbart@nginx.com> Message-ID: <1839738546.20130308200515@softsearch.ru> Здравствуйте, Anatoly. > вопрос в том, как правильно ее отдавать - > через 2 nginx-а или деплоить статику на балансировщик? Статику можно кэшировать на Nginx-A. Если её не много, то вся влезет в оперативку. Если много, то будет с диска тянуться. Если диска не хватит по скорости, то воткните SSD и отдавайте с него. Из Вашей схемы я понял, что на Nginx-A занят только процессор, так что было бы разумно использовать остальные простаивающие ресурсы сервера (память и диск) с пользой. -- С уважением, Михаил mailto:postmaster at softsearch.ru From onokonem at gmail.com Fri Mar 8 16:48:42 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Fri, 8 Mar 2013 19:48:42 +0300 Subject: =?UTF-8?B?UmU6IEZ3ZDog0KDQtdCz0LXQutGB0L/QvtCy0YvQuSBzZXJ2ZXJfbmFtZQ==?= In-Reply-To: <201303081747.57914.vbart@nginx.com> References: <201303072115.24661.vbart@nginx.com> <201303081747.57914.vbart@nginx.com> Message-ID: > Один регэксп у вас повлечет кучу логики с переменными из него. Или нет. Если группа(ы) из регекспа используются только для установки root - конфиг только читабельнее станет от их применения. Другое дело, что матчинг с группировкой может оказаться все же существенно медленнее выбора по дереву. Провести, что ли, самому соответствующие тесты?.. Взять тысячу сайтов, и прогнать миллион запросов, через один конфиг и через другой. И померять загрузку... > Речь идет не о том, что быстрее, а о том, что не нужно программировать на > конфигах и поддерживать несколько простых конфигураций проще, чем одну с кучей > сложной логики. Нужно, или нет - это проектом определяется. У меня, к примеру, список сайтов меняется ежеминутно, без преувеличения. И мне статическую конфигурацию ну никак не поддержать (на самом деле - можно, конечно, но получится простыня уже руками совершенно не исправимая). From anatoly at sonru.com Fri Mar 8 17:16:48 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Fri, 8 Mar 2013 17:16:48 +0000 Subject: =?UTF-8?B?UmU6INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YHQtdGA?= =?UTF-8?B?0LLQtdGA0L7Qsg==?= In-Reply-To: <1839738546.20130308200515@softsearch.ru> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <201303071354.22491.vbart@nginx.com> <92C91BDB-9821-4741-A737-4117621044B2@sonru.com> <201303071541.43901.vbart@nginx.com> <1839738546.20130308200515@softsearch.ru> Message-ID: <86539228-CA06-4524-8F76-784644B53506@sonru.com> On Mar 8, 2013, at 4:05 PM, Михаил Монашёв wrote: > Здравствуйте, Anatoly. > >> вопрос в том, как правильно ее отдавать - >> через 2 nginx-а или деплоить статику на балансировщик? > > Статику можно кэшировать на Nginx-A. Если её не много, то вся влезет в > оперативку. Если много, то будет с диска тянуться. Если диска не > хватит по скорости, то воткните SSD и отдавайте с него. Из Вашей схемы > я понял, что на Nginx-A занят только процессор, так что было бы > разумно использовать остальные простаивающие ресурсы сервера (память и > диск) с пользой. open_file_cache? Анатолий > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Fri Mar 8 17:49:53 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 8 Mar 2013 21:49:53 +0400 Subject: =?UTF-8?B?UmU6IEZ3ZDog0KDQtdCz0LXQutGB0L/QvtCy0YvQuSBzZXJ2ZXJfbmFtZQ==?= In-Reply-To: References: <201303081747.57914.vbart@nginx.com> Message-ID: <201303082149.53911.vbart@nginx.com> On Friday 08 March 2013 20:48:42 Daniel Podolsky wrote: > > Один регэксп у вас повлечет кучу логики с переменными из него. > > Или нет. Если группа(ы) из регекспа используются только для установки > root - конфиг только читабельнее станет от их применения. > > Другое дело, что матчинг с группировкой может оказаться все же > существенно медленнее выбора по дереву. > > Провести, что ли, самому соответствующие тесты?.. Взять тысячу сайтов, > и прогнать миллион запросов, через один конфиг и через другой. И > померять загрузку... > Это бессмысленно. Регулярное выражение вида: ^([^.]+)\.([^.]+)\.example\.com$ скорее всего будет быстрее, чем поиск по дереву из тысячи доменов. В любом случае, на фоне всех остальных операций - это неизмеримо малая величина. К примеру, на моем мобильном i3-350m указанное регулярное выражение выполняется в среднем за 400 наносекунд без использования JIT, и менее чем за 100 наносекунд с JIT. -- Валентин Бартенев http://nginx.org/en/donation.html From onokonem at gmail.com Fri Mar 8 18:32:14 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Fri, 8 Mar 2013 21:32:14 +0300 Subject: =?UTF-8?B?UmU6IEZ3ZDog0KDQtdCz0LXQutGB0L/QvtCy0YvQuSBzZXJ2ZXJfbmFtZQ==?= In-Reply-To: <201303082149.53911.vbart@nginx.com> References: <201303081747.57914.vbart@nginx.com> <201303082149.53911.vbart@nginx.com> Message-ID: > В любом случае, на фоне всех остальных операций - это неизмеримо малая > величина. К примеру, на моем мобильном i3-350m указанное регулярное > выражение выполняется в среднем за 400 наносекунд без использования JIT, > и менее чем за 100 наносекунд с JIT. Ну вот и я что-то такое подозревал, хоть и поленился померять. Спасибо! Итого - регулярные выражения в конфиге применять можно и нужно, если ты хорошо понимаешь, как они работают, и готов сам разбираться с проблемами, если конфиг, который ты написал, работает не так, как ты ожидаешь. From postmaster at softsearch.ru Fri Mar 8 19:26:03 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 8 Mar 2013 23:26:03 +0400 Subject: =?UTF-8?B?UmVbMl06INC60LDRgdC60LDQtCDQv9GA0L7QutGB0LjRgNGD0Y7RidC40YUg0YE=?= =?UTF-8?B?0LXRgNCy0LXRgNC+0LI=?= In-Reply-To: <86539228-CA06-4524-8F76-784644B53506@sonru.com> References: <08C45AFF-BC6F-48EB-916F-9529F925E340@sonru.com> <201303071354.22491.vbart@nginx.com> <92C91BDB-9821-4741-A737-4117621044B2@sonru.com> <201303071541.43901.vbart@nginx.com> <1839738546.20130308200515@softsearch.ru> <86539228-CA06-4524-8F76-784644B53506@sonru.com> Message-ID: <1371250796.20130308232603@softsearch.ru> Здравствуйте, Anatoly. >>> вопрос в том, как правильно ее отдавать - >>> через 2 nginx-а или деплоить статику на балансировщик? >> >> Статику можно кэшировать на Nginx-A. Если её не много, то вся влезет в >> оперативку. Если много, то будет с диска тянуться. Если диска не >> хватит по скорости, то воткните SSD и отдавайте с него. Из Вашей схемы >> я понял, что на Nginx-A занят только процессор, так что было бы >> разумно использовать остальные простаивающие ресурсы сервера (память и >> диск) с пользой. > open_file_cache? Нет, proxy_cache . -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Sat Mar 9 02:46:36 2013 From: nginx-forum at nginx.us (Namaste) Date: Fri, 08 Mar 2013 21:46:36 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQuNC90YPQtNC40YLQtdC70YzQvdC+INC+0LHQvdC+0LLQuNGC0Ywg?= =?UTF-8?B?0YHRgtGA0LDQvdC40YbRgyDQsiDQutGN0YjQtQ==?= In-Reply-To: <201303081753.30332.vbart@nginx.com> References: <201303081753.30332.vbart@nginx.com> Message-ID: Спасибо! Попробую. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237117,237145#msg-237145 From nginx-forum at nginx.us Sat Mar 9 02:53:28 2013 From: nginx-forum at nginx.us (Namaste) Date: Fri, 08 Mar 2013 21:53:28 -0500 Subject: =?UTF-8?Q?=24request_uri_=D0=B2_lowercase?= Message-ID: Привет! В некоторых локейшенах использую fastcgi_cache с ключом $scheme$host$request_uri$request_method; Как я понимаю для каждого из таких $request_uri: test.html, Test.html, TEST.html - будет создаваться отдельный файл в кэше. можно как-то это исправить - перевести $request_uri в lowercase? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237146,237146#msg-237146 From nginx-forum at nginx.us Sat Mar 9 09:16:07 2013 From: nginx-forum at nginx.us (bozercov) Date: Sat, 09 Mar 2013 04:16:07 -0500 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IHVwc3RyZWFt?= =?UTF-8?B?IHNlbnQgdG9vIGJpZyBoZWFkZXI=?= In-Reply-To: <201303081813.09290.vbart@nginx.com> References: <201303081813.09290.vbart@nginx.com> Message-ID: <792018226d8c30233ced0d789b83e09b.NginxMailingListRussian@forum.nginx.org> увеличил, сейчас уже не 502 ошибка, а хроме Ошибка 325 (net::ERR_RESPONSE_HEADERS_TOO_BIG): Неизвестная ошибка. В другим браузерах все работает. Похоже nginx тут не причем. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237114,237154#msg-237154 From nefer05 at gmail.com Sat Mar 9 09:56:26 2013 From: nefer05 at gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=) Date: Sat, 9 Mar 2013 13:56:26 +0400 Subject: =?UTF-8?Q?Re=3A_=24request_uri_=D0=B2_lowercase?= In-Reply-To: References: Message-ID: Прошу прощения что вклиниваюсь, но зачем вы такие URL генерите? 2013/3/9 Namaste > Привет! > > В некоторых локейшенах использую fastcgi_cache с ключом > $scheme$host$request_uri$request_method; > > Как я понимаю для каждого из таких $request_uri: test.html, Test.html, > TEST.html - будет создаваться отдельный файл в кэше. > можно как-то это исправить - перевести $request_uri в lowercase? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,237146,237146#msg-237146 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nefer05 at gmail.com Sat Mar 9 09:59:56 2013 From: nefer05 at gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=) Date: Sat, 9 Mar 2013 13:59:56 +0400 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IHVwc3RyZWFt?= =?UTF-8?B?IHNlbnQgdG9vIGJpZyBoZWFkZXI=?= In-Reply-To: <792018226d8c30233ced0d789b83e09b.NginxMailingListRussian@forum.nginx.org> References: <201303081813.09290.vbart@nginx.com> <792018226d8c30233ced0d789b83e09b.NginxMailingListRussian@forum.nginx.org> Message-ID: nginx тут точно не при чем, если вы им заголовки не генерите. К тому же он изначально говорил что апстрим ему отдает слишком дофига. tcpdum'ом снимите что апстрим возвращает и крутите бэкэнд. 2013/3/9 bozercov > увеличил, сейчас уже не 502 ошибка, а хроме Ошибка 325 > (net::ERR_RESPONSE_HEADERS_TOO_BIG): Неизвестная ошибка. В другим браузерах > все работает. Похоже nginx тут не причем. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,237114,237154#msg-237154 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Mar 9 14:39:58 2013 From: nginx-forum at nginx.us (Namaste) Date: Sat, 09 Mar 2013 09:39:58 -0500 Subject: =?UTF-8?Q?Re=3A_=24request_uri_=D0=B2_lowercase?= In-Reply-To: References: Message-ID: <376565ef68a56e0898a5949f9364f268.NginxMailingListRussian@forum.nginx.org> Да нет. На самом деле нормальное написание url'а - одно. Например /Test-page.htm - таким его генерю я и таким его видно в ссылке с других страниц сайта. Просто замечаю, что иногда пытаются скачать /test-page.htm. Вот и подумалось, что если кому-то захочется пошалить, можно пытаться качать страницы с разным написанием урла - страница из кэша браться не будет, будет расти нагрузка на сервер и будет расти размер кэша. Я могу конечно проверять написание урла с написанием соответсвующего поля в базе, но зачем мне лишние запросы к базе? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237155,237157#msg-237157 From swood at fotofor.biz Sat Mar 9 15:57:18 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Sat, 9 Mar 2013 19:57:18 +0400 Subject: =?UTF-8?Q?Re=3A_=24request_uri_=D0=B2_lowercase?= In-Reply-To: <376565ef68a56e0898a5949f9364f268.NginxMailingListRussian@forum.nginx.org> References: <376565ef68a56e0898a5949f9364f268.NginxMailingListRussian@forum.nginx.org> Message-ID: Можно попробовать использовать mod_lua для этих целей. Скрипт будет в две строчки. 9 марта 2013 г., 18:39 пользователь Namaste написал: > Да нет. На самом деле нормальное написание url'а - одно. Например > /Test-page.htm - таким его генерю я и таким его видно в ссылке с других > страниц сайта. Просто замечаю, что иногда пытаются скачать /test-page.htm. > Вот и подумалось, что если кому-то захочется пошалить, можно пытаться > качать > страницы с разным написанием урла - страница из кэша браться не будет, > будет > расти нагрузка на сервер и будет расти размер кэша. > Я могу конечно проверять написание урла с написанием соответсвующего поля в > базе, но зачем мне лишние запросы к базе? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,237155,237157#msg-237157 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at webmaster.spb.ru Sat Mar 9 19:18:32 2013 From: denis at webmaster.spb.ru (denis) Date: Sat, 09 Mar 2013 23:18:32 +0400 Subject: =?UTF-8?Q?Re=3A_=24request_uri_=D0=B2_lowercase?= In-Reply-To: References: <376565ef68a56e0898a5949f9364f268.NginxMailingListRussian@forum.nginx.org> Message-ID: <513B8B08.3060100@webmaster.spb.ru> 09.03.2013 19:57, Anton Kiryushkin пишет: > Можно попробовать использовать mod_lua для этих целей. Скрипт будет в > две строчки. > для апача? и почему не embedded perl? From swood at fotofor.biz Sat Mar 9 23:06:05 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Sun, 10 Mar 2013 03:06:05 +0400 Subject: =?UTF-8?Q?Re=3A_=24request_uri_=D0=B2_lowercase?= In-Reply-To: <513B8B08.3060100@webmaster.spb.ru> References: <376565ef68a56e0898a5949f9364f268.NginxMailingListRussian@forum.nginx.org> <513B8B08.3060100@webmaster.spb.ru> Message-ID: Для nginx. Почему, потому что mod_lua асинхронный. 9 марта 2013 г., 23:18 пользователь denis написал: > 09.03.2013 19:57, Anton Kiryushkin пишет: > > Можно попробовать использовать mod_lua для этих целей. Скрипт будет в две >> строчки. >> >> для апача? и почему не embedded perl? > > > ______________________________**_________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/**mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Sun Mar 10 17:16:16 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 10 Mar 2013 21:16:16 +0400 Subject: =?UTF-8?Q?Re=3A_=24request_uri_=D0=B2_lowercase?= In-Reply-To: References: Message-ID: <1881379486.20130310211616@softsearch.ru> Здравствуйте, Namaste. > В некоторых локейшенах использую fastcgi_cache с ключом > $scheme$host$request_uri$request_method; > Как я понимаю для каждого из таких $request_uri: test.html, Test.html, > TEST.html - будет создаваться отдельный файл в кэше. > можно как-то это исправить - перевести $request_uri в lowercase? на встроенном перле попробуйте. функция в перле называется lc(). -- С уважением, Михаил mailto:postmaster at softsearch.ru From onokonem at gmail.com Sun Mar 10 17:32:57 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Sun, 10 Mar 2013 21:32:57 +0400 Subject: =?UTF-8?Q?Re=3A_=24request_uri_=D0=B2_lowercase?= In-Reply-To: References: <376565ef68a56e0898a5949f9364f268.NginxMailingListRussian@forum.nginx.org> <513B8B08.3060100@webmaster.spb.ru> Message-ID: > Для nginx. Почему, потому что mod_lua асинхронный. В каком это смысле он асинхронный? From nefer05 at gmail.com Sun Mar 10 18:10:47 2013 From: nefer05 at gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=) Date: Sun, 10 Mar 2013 22:10:47 +0400 Subject: =?UTF-8?Q?Re=3A_=24request_uri_=D0=B2_lowercase?= In-Reply-To: <376565ef68a56e0898a5949f9364f268.NginxMailingListRussian@forum.nginx.org> References: <376565ef68a56e0898a5949f9364f268.NginxMailingListRussian@forum.nginx.org> Message-ID: Если у вас нет такой страницы - откуда возьмется кэш? 2013/3/9 Namaste > Да нет. На самом деле нормальное написание url'а - одно. Например > /Test-page.htm - таким его генерю я и таким его видно в ссылке с других > страниц сайта. Просто замечаю, что иногда пытаются скачать /test-page.htm. > Вот и подумалось, что если кому-то захочется пошалить, можно пытаться > качать > страницы с разным написанием урла - страница из кэша браться не будет, > будет > расти нагрузка на сервер и будет расти размер кэша. > Я могу конечно проверять написание урла с написанием соответсвующего поля в > базе, но зачем мне лишние запросы к базе? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,237155,237157#msg-237157 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Mon Mar 11 07:10:24 2013 From: nginx-forum at nginx.us (Modigar) Date: Mon, 11 Mar 2013 03:10:24 -0400 Subject: =?UTF-8?B?V2ViU29ja2V0INC/0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1?= Message-ID: <2526f223e06230fd7b01123da1628783.NginxMailingListRussian@forum.nginx.org> Необходимо спроксировать вебсокет через nginx по следующей схеме: Клиент -> HTTPS (WSS) -> nginx -> Local Server (WS). Т.е. если описать словами, то необходимо авторизироваться по SSL (в т.ч. и вебсокету) на nginx, а последний в свою очередь должен спроксировать вебсокет клиента на локальный вебсокет сервер без SSL. вопросы: 1. Возможно ли такое? 2. Как это сделать? 3. Если не возможно, то как быть с сертификатом для локального вебсокет сервера? 4. Как реализовать это в рамках одной машины (nginx, локальный вебсокет сервер и клиент на одной машине стоят), и при этом убедиться, что nginx проксирует? PS: извините, если вопросы глупые, просто это не моя стезя. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237205,237205#msg-237205 From russjura at gmail.com Mon Mar 11 07:28:34 2013 From: russjura at gmail.com (=?KOI8-R?B?4NLJyg==?=) Date: Mon, 11 Mar 2013 10:28:34 +0300 Subject: =?UTF-8?B?UmU6IFdlYlNvY2tldCDQv9GA0L7QutGB0LjRgNC+0LLQsNC90LjQtQ==?= In-Reply-To: <2526f223e06230fd7b01123da1628783.NginxMailingListRussian@forum.nginx.org> References: <2526f223e06230fd7b01123da1628783.NginxMailingListRussian@forum.nginx.org> Message-ID: Правильно ли я понял? что у тебя уважаемый двойной тоннель? 1 - между нгинкс, и клиентом, второй между клиентом и локальным сервером (сквозь тоннель) со вторичной аторизацией? 11 марта 2013 г., 10:10 пользователь Modigar написал: > Необходимо спроксировать вебсокет через nginx по следующей схеме: > Клиент -> HTTPS (WSS) -> nginx -> Local Server (WS). > Т.е. если описать словами, то необходимо авторизироваться по SSL (в т.ч. и > вебсокету) на nginx, а последний в свою очередь должен спроксировать > вебсокет клиента на локальный вебсокет сервер без SSL. > вопросы: > 1. Возможно ли такое? > 2. Как это сделать? > 3. Если не возможно, то как быть с сертификатом для локального вебсокет > сервера? > 4. Как реализовать это в рамках одной машины (nginx, локальный вебсокет > сервер и клиент на одной машине стоят), и при этом убедиться, что nginx > проксирует? > PS: извините, если вопросы глупые, просто это не моя стезя. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,237205,237205#msg-237205 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Mon Mar 11 07:42:15 2013 From: nginx-forum at nginx.us (Modigar) Date: Mon, 11 Mar 2013 03:42:15 -0400 Subject: =?UTF-8?B?UmU6IFdlYlNvY2tldCDQv9GA0L7QutGB0LjRgNC+0LLQsNC90LjQtQ==?= In-Reply-To: References: Message-ID: <90e6b68e6fc57822f7f05b8d561e207e.NginxMailingListRussian@forum.nginx.org> Не совсем правильно. Мне нужна одна авторизация на nginx по HTTPS и WSS, т.е. (если я правильно подбираю слова) nginx должен будет к моему локальному серверу подключиться уже через WS. Или с другой стороны если задачу описать: клиент должен открыть у себя WSS соединение, а попасть через nginx на мой локальный сервер уже с WS соединением. Такое вообще возможно? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237205,237209#msg-237209 From nginx-forum at nginx.us Mon Mar 11 08:55:16 2013 From: nginx-forum at nginx.us (ast) Date: Mon, 11 Mar 2013 04:55:16 -0400 Subject: =?UTF-8?B?UmU6IFdlYlNvY2tldCDQv9GA0L7QutGB0LjRgNC+0LLQsNC90LjQtQ==?= In-Reply-To: <90e6b68e6fc57822f7f05b8d561e207e.NginxMailingListRussian@forum.nginx.org> References: <90e6b68e6fc57822f7f05b8d561e207e.NginxMailingListRussian@forum.nginx.org> Message-ID: Если я вас правильно понял, то вот ваш конфиг. server { listen 443; ssl on; server_name example.com; ssl_certificate /etc/tunnel/your.pem; ssl_certificate_key /etc/tunnel/your.key; ssl_session_timeout 10m; ssl_ciphers RC4:HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; ssl_session_cache builtin; location / { proxy_pass http://localhost:8090; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237205,237213#msg-237213 From russjura at gmail.com Mon Mar 11 08:57:35 2013 From: russjura at gmail.com (=?KOI8-R?B?4NLJyg==?=) Date: Mon, 11 Mar 2013 11:57:35 +0300 Subject: =?UTF-8?B?UmU6IFdlYlNvY2tldCDQv9GA0L7QutGB0LjRgNC+0LLQsNC90LjQtQ==?= In-Reply-To: <90e6b68e6fc57822f7f05b8d561e207e.NginxMailingListRussian@forum.nginx.org> References: <90e6b68e6fc57822f7f05b8d561e207e.NginxMailingListRussian@forum.nginx.org> Message-ID: Тогда не вижу проблемы, используйте обыкновенный реверсивный прокси, nginx проксирует и кеширует данные с локального сервера. Аська у вас есть? давайте напрямик пообщаемся? 11 марта 2013 г., 10:42 пользователь Modigar написал: > Не совсем правильно. Мне нужна одна авторизация на nginx по HTTPS и WSS, > т.е. (если я правильно подбираю слова) nginx должен будет к моему > локальному > серверу подключиться уже через WS. > Или с другой стороны если задачу описать: клиент должен открыть у себя WSS > соединение, а попасть через nginx на мой локальный сервер уже с WS > соединением. > Такое вообще возможно? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,237205,237209#msg-237209 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Mon Mar 11 09:08:31 2013 From: nginx-forum at nginx.us (Modigar) Date: Mon, 11 Mar 2013 05:08:31 -0400 Subject: =?UTF-8?B?UmU6IFdlYlNvY2tldCDQv9GA0L7QutGB0LjRgNC+0LLQsNC90LjQtQ==?= In-Reply-To: References: Message-ID: russjura Wrote: ------------------------------------------------------- > Аська у вас есть? давайте напрямик пообщаемся? А ПМ-а тут нет? 167118СемьДевятьВосемь Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237205,237215#msg-237215 From ru at nginx.com Mon Mar 11 09:14:46 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Mon, 11 Mar 2013 13:14:46 +0400 Subject: =?UTF-8?B?UmU6IFdlYlNvY2tldCDQv9GA0L7QutGB0LjRgNC+0LLQsNC90LjQtQ==?= In-Reply-To: <2526f223e06230fd7b01123da1628783.NginxMailingListRussian@forum.nginx.org> References: <2526f223e06230fd7b01123da1628783.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130311091446.GC50312@lo0.su> On Mon, Mar 11, 2013 at 03:10:24AM -0400, Modigar wrote: > Необходимо спроксировать вебсокет через nginx по следующей схеме: > Клиент -> HTTPS (WSS) -> nginx -> Local Server (WS). > Т.е. если описать словами, то необходимо авторизироваться по SSL (в т.ч. и > вебсокету) на nginx, а последний в свою очередь должен спроксировать > вебсокет клиента на локальный вебсокет сервер без SSL. > вопросы: > 1. Возможно ли такое? Да, почему нет. > 2. Как это сделать? Настроить HTTPS: http://nginx.org/ru/docs/http/configuring_https_servers.html Настроить проксирование WebSocket: http://nginx.org/ru/docs/http/websocket.html > 3. Если не возможно, то как быть с сертификатом для локального вебсокет > сервера? > 4. Как реализовать это в рамках одной машины (nginx, локальный вебсокет > сервер и клиент на одной машине стоят), и при этом убедиться, что nginx > проксирует? http { server { listen 8000 ssl; ssl_certificate cert.pem; ssl_certificate_key cert.key; location = /test { proxy_pass http://echo.websocket.org/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } } } http://www.websocket.org/echo.html Введите там адрес вашего настроенного сервера. Я с вышеприведенной конфигурацией тестировал так: wss://127.0.0.1:8000/test. From nginx-forum at nginx.us Mon Mar 11 09:24:38 2013 From: nginx-forum at nginx.us (recived) Date: Mon, 11 Mar 2013 05:24:38 -0400 Subject: could not build the proxy_headers_hash Message-ID: <5aff1faa461aa8ce317b0bf309a58cd2.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Не могу понять как решить проблему с ошибкой: nginx: [emerg] could not build the proxy_headers_hash, you should increase either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size: 64 (nginx/1.1.19) Подскажите пожалуйста. ------------------------------------------------------------------------------------------------ nginx.conf ------------------------------------------------------------------------------------------------ user www-data; worker_processes 4; pid /var/run/nginx.pid; events { worker_connections 768; # multi_accept on; } http { ## # Basic Settings ## sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; # server_tokens off; include /etc/nginx/mime.types; default_type application/octet-stream; server_names_hash_bucket_size 64; server_names_hash_max_size 512; ## # Logging Settings ## log_format main '$host $remote_addr [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"'; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; ## # Gzip Settings ## gzip on; gzip_disable "msie6"; ## # Virtual Host Configs ## include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; } ------------------------------------------------ mysite.tpl ------------------------------------------------ server { listen 80; server_name mysite.tpl; access_log /var/www/mysite.tpl/logs/access_ng.log; error_log /var/wwwsite/mysite.tpl/logs/error_ng.log; location ~* \.(gif|png|css|zip|swf|ico|flv|jpg)$ { root /var/wwwsite/mysite.tpl/www/; #index index.html index.php; access_log off; expires max; gzip on; gzip_comp_level 5; gzip_vary on; gzip_static on; gzip_types text/css text/plain application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript text/x-js application/x-shockwave-flash; gzip_min_length 1024; gzip_disable "msie6"; gzip_proxied any; } location / { proxy_pass http://192.168.4.250:82/; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-for $remote_addr; proxy_set_header Host $host; proxy_connect_timeout 60; proxy_send_timeout 90; proxy_read_timeout 90; proxy_redirect off; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237218,237218#msg-237218 From ru at nginx.com Mon Mar 11 10:08:38 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Mon, 11 Mar 2013 14:08:38 +0400 Subject: could not build the proxy_headers_hash In-Reply-To: <5aff1faa461aa8ce317b0bf309a58cd2.NginxMailingListRussian@forum.nginx.org> References: <5aff1faa461aa8ce317b0bf309a58cd2.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130311100838.GD50312@lo0.su> On Mon, Mar 11, 2013 at 05:24:38AM -0400, recived wrote: > Здравствуйте. Не могу понять как решить проблему с ошибкой: > nginx: [emerg] could not build the proxy_headers_hash, you should increase > either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size: > 64 > (nginx/1.1.19) > Подскажите пожалуйста. У вас дважды задана передача заголовка X-Forwarded-For на проксируемый сервер, из-за этого и ошибка. (Сообщение об ошибке возможно следует сделать более явным.) > ------------------------------------------------------------------------------------------------ > nginx.conf > ------------------------------------------------------------------------------------------------ > user www-data; > worker_processes 4; > pid /var/run/nginx.pid; > > events { > worker_connections 768; > # multi_accept on; > } > > http { > ## > # Basic Settings > ## > sendfile on; > tcp_nopush on; > tcp_nodelay on; > keepalive_timeout 65; > types_hash_max_size 2048; > # server_tokens off; > > include /etc/nginx/mime.types; > default_type application/octet-stream; > server_names_hash_bucket_size 64; > server_names_hash_max_size 512; > ## > # Logging Settings > ## > log_format main '$host $remote_addr [$time_local] "$request" $status > $body_bytes_sent "$http_referer" "$http_user_agent"'; > access_log /var/log/nginx/access.log; > error_log /var/log/nginx/error.log; > > ## > # Gzip Settings > ## > > gzip on; > gzip_disable "msie6"; > > ## > # Virtual Host Configs > ## > include /etc/nginx/conf.d/*.conf; > include /etc/nginx/sites-enabled/*; > } > > ------------------------------------------------ > mysite.tpl > ------------------------------------------------ > server { > listen 80; > server_name mysite.tpl; > access_log /var/www/mysite.tpl/logs/access_ng.log; > error_log /var/wwwsite/mysite.tpl/logs/error_ng.log; > > location ~* \.(gif|png|css|zip|swf|ico|flv|jpg)$ { > root /var/wwwsite/mysite.tpl/www/; > #index index.html index.php; > access_log off; > expires max; > > gzip on; > gzip_comp_level 5; > gzip_vary on; > gzip_static on; > gzip_types text/css text/plain application/json application/x-javascript > text/xml application/xml application/xml+rss text/javascript > application/javascript text/x-js application/x-shockwave-flash; > gzip_min_length 1024; > gzip_disable "msie6"; > gzip_proxied any; > > } > location / { > proxy_pass http://192.168.4.250:82/; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header X-Forwarded-for $remote_addr; > proxy_set_header Host $host; > proxy_connect_timeout 60; > proxy_send_timeout 90; > proxy_read_timeout 90; > proxy_redirect off; > } > } From nginx-forum at nginx.us Mon Mar 11 10:36:54 2013 From: nginx-forum at nginx.us (recived) Date: Mon, 11 Mar 2013 06:36:54 -0400 Subject: could not build the proxy_headers_hash In-Reply-To: <20130311100838.GD50312@lo0.su> References: <20130311100838.GD50312@lo0.su> Message-ID: <5b3e2989165f04e63edf1852c3f48b04.NginxMailingListRussian@forum.nginx.org> Спасибо помогло. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237218,237221#msg-237221 From mdounin at mdounin.ru Mon Mar 11 11:06:24 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 11 Mar 2013 15:06:24 +0400 Subject: could not build the proxy_headers_hash In-Reply-To: <20130311100838.GD50312@lo0.su> References: <5aff1faa461aa8ce317b0bf309a58cd2.NginxMailingListRussian@forum.nginx.org> <20130311100838.GD50312@lo0.su> Message-ID: <20130311110624.GS15378@mdounin.ru> Hello! On Mon, Mar 11, 2013 at 02:08:38PM +0400, Ruslan Ermilov wrote: > On Mon, Mar 11, 2013 at 05:24:38AM -0400, recived wrote: > > Здравствуйте. Не могу понять как решить проблему с ошибкой: > > nginx: [emerg] could not build the proxy_headers_hash, you should increase > > either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size: > > 64 > > (nginx/1.1.19) > > Подскажите пожалуйста. > > У вас дважды задана передача заголовка X-Forwarded-For на > проксируемый сервер, из-за этого и ошибка. (Сообщение об > ошибке возможно следует сделать более явным.) Два одинаковых заголовка - это, вообще говоря, не ошибка, а вполне допустимая в некоторых ситуациях конструкция. Ты, впрочем, вероятно это и без меня знаешь. :) Другой вопрос, что в хеш пытаться засунуть один и тот же заголовок дважды - особого смысла нет, и в такой ситуации можно было бы и не ругаться вообще. Но вообще сообщение - правильное, установка proxy_headers_hash_bucket_size 128; ситуацию вполне лечит. Ну и ссылку на всякий случай дам, вдруг кому пригодится: http://nginx.org/ru/docs/hash.html [...] -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Tue Mar 12 06:07:34 2013 From: nginx-forum at nginx.us (Modigar) Date: Tue, 12 Mar 2013 02:07:34 -0400 Subject: =?UTF-8?B?UmU6IFdlYlNvY2tldCDQv9GA0L7QutGB0LjRgNC+0LLQsNC90LjQtQ==?= In-Reply-To: <20130311091446.GC50312@lo0.su> References: <20130311091446.GC50312@lo0.su> Message-ID: Получилось настроить таким образом: http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 443 ssl; # порт https server_name localhost; # ваш сайт ssl_certificate /usr/local/nginx/sert/cert.pem; ssl_certificate_key /usr/local/nginx/sert/cert.key; if ( $scheme = "http" ) { rewrite ^/(.*)$ https://$host/$1 permanent; } location / { root html; index index.html index.htm; } location = /websocket { proxy_pass http://127.0.0.1:8086; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } proxy_read_timeout 32000s; } В фаерфоксе все соединяется и работает, только на первое подключение выдал предупреждение о том что сертификат левый, поставил галочку доверять и дальше пускает без проблем. А вот в Хроме проблемы - не соединяется ни в какую, т.е. https://localhost:443 - страница не доступна. В Хроме добавил вручную сертификат свой и выставил все галочки на доверие ему. Эффекта нет. ВебКит обертка от Qt - загружает станицу если игнорировать SSL ошибки, но по вебсокету не соединяет. Что делать? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237205,237247#msg-237247 From mdounin at mdounin.ru Tue Mar 12 09:52:59 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 12 Mar 2013 13:52:59 +0400 Subject: =?UTF-8?B?UmU6IFdlYlNvY2tldCDQv9GA0L7QutGB0LjRgNC+0LLQsNC90LjQtQ==?= In-Reply-To: References: <20130311091446.GC50312@lo0.su> Message-ID: <20130312095259.GI15378@mdounin.ru> Hello! On Tue, Mar 12, 2013 at 02:07:34AM -0400, Modigar wrote: > Получилось настроить таким образом: > http { > include mime.types; > default_type application/octet-stream; > sendfile on; > keepalive_timeout 65; > > server { > listen 443 ssl; # порт https > server_name localhost; # ваш сайт > > ssl_certificate /usr/local/nginx/sert/cert.pem; > ssl_certificate_key /usr/local/nginx/sert/cert.key; > if ( $scheme = "http" ) { > rewrite ^/(.*)$ https://$host/$1 permanent; > } > > location / { > root html; > index index.html index.htm; > } > location = /websocket { > proxy_pass http://127.0.0.1:8086; > proxy_http_version 1.1; > proxy_set_header Upgrade $http_upgrade; > proxy_set_header Connection "upgrade"; > } > > proxy_read_timeout 32000s; > } > > В фаерфоксе все соединяется и работает, только на первое подключение выдал > предупреждение о том что сертификат левый, поставил галочку доверять и > дальше пускает без проблем. > А вот в Хроме проблемы - не соединяется ни в какую, т.е. > https://localhost:443 - страница не доступна. > В Хроме добавил вручную сертификат свой и выставил все галочки на доверие > ему. Эффекта нет. > ВебКит обертка от Qt - загружает станицу если игнорировать SSL ошибки, но по > вебсокету не соединяет. > Что делать? Для начала - научиться конфигурировать ssl так, чтобы ошибок и предупреждений - не было. Простейший способ - взять бесплатный сертификат для вашего домена где-нибудь на startssl.com. Ну или выкинуть ssl из конструкции. Только потом - пытаться что-то настраивать дальше. -- Maxim Dounin http://nginx.org/en/donation.html From igor at sysoev.ru Tue Mar 12 10:01:03 2013 From: igor at sysoev.ru (Igor Sysoev) Date: Tue, 12 Mar 2013 14:01:03 +0400 Subject: =?UTF-8?B?UmU6IFdlYlNvY2tldCDQv9GA0L7QutGB0LjRgNC+0LLQsNC90LjQtQ==?= In-Reply-To: References: <20130311091446.GC50312@lo0.su> Message-ID: <6C489123-BEC1-4DFF-9F0B-381A48BBDE61@sysoev.ru> On Mar 12, 2013, at 10:07 , Modigar wrote: > server { > listen 443 ssl; # порт https > server_name localhost; # ваш сайт > > ssl_certificate /usr/local/nginx/sert/cert.pem; > ssl_certificate_key /usr/local/nginx/sert/cert.key; Вот это: > if ( $scheme = "http" ) { > rewrite ^/(.*)$ https://$host/$1 permanent; > } бессмыслица. Нужно так: error_page 497 =301 http://$host$request_uri; -- Igor Sysoev http://nginx.com/support.html From lego12239 at yandex.ru Tue Mar 12 10:59:44 2013 From: lego12239 at yandex.ru (Oleg) Date: Tue, 12 Mar 2013 14:59:44 +0400 Subject: rewrite & $remote_user Message-ID: <20130312105944.GA23025@localhost> Здравствуйте. Есть следующая конфигурация: location /test { auth_basic "test zone"; auth_basic_user_file /var/www/test/.htpasswd; root /var/www; rewrite ^/test/?$ /test/user/$remote_user/f redirect; } Хочется, что бы после аутентификации пользователя редиректило на его страницу. Порядок (сначало аутентификация, потом перенаправление) работает как подразумевается, а, вот, подстановка $remote_user не работает. В браузере http://host/test даёт http://host/test/user//f. Если использовать, для примера, $remote_addr, то подстановка работает как надо. Не подскажет ли кто-нибудь в чём может быть дело? Спасибо. P.S. nginx 1.2.1 в Debian squeeze из backports. From vbart at nginx.com Tue Mar 12 14:45:08 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 12 Mar 2013 18:45:08 +0400 Subject: rewrite & $remote_user In-Reply-To: <20130312105944.GA23025@localhost> References: <20130312105944.GA23025@localhost> Message-ID: <201303121845.08941.vbart@nginx.com> On Tuesday 12 March 2013 14:59:44 Oleg wrote: > Здравствуйте. > > Есть следующая конфигурация: > > location /test { > auth_basic "test zone"; > auth_basic_user_file /var/www/test/.htpasswd; > root /var/www; > > rewrite ^/test/?$ /test/user/$remote_user/f redirect; > } > > Хочется, что бы после аутентификации пользователя редиректило на его > страницу. Порядок (сначало аутентификация, потом перенаправление) работает > как подразумевается, а, вот, подстановка $remote_user не работает. В > браузере http://host/test даёт http://host/test/user//f. Если > использовать, для примера, $remote_addr, то подстановка работает как надо. > Не подскажет ли кто-нибудь в чём может быть дело? > Дело в том, что rewrite работает до auth_basic. -- Валентин Бартенев http://nginx.org/en/donation.html From denis at webmaster.spb.ru Tue Mar 12 15:27:52 2013 From: denis at webmaster.spb.ru (denis) Date: Tue, 12 Mar 2013 19:27:52 +0400 Subject: rewrite & $remote_user In-Reply-To: <201303121845.08941.vbart@nginx.com> References: <20130312105944.GA23025@localhost> <201303121845.08941.vbart@nginx.com> Message-ID: <513F4978.8090006@webmaster.spb.ru> 12.03.2013 18:45, Валентин Бартенев пишет: > > Дело в том, что rewrite работает до auth_basic. а где можно посмотреть схему, кто когда работает? кроме исходников. From gmm at csdoc.com Tue Mar 12 15:50:38 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Tue, 12 Mar 2013 17:50:38 +0200 Subject: rewrite & $remote_user In-Reply-To: <513F4978.8090006@webmaster.spb.ru> References: <20130312105944.GA23025@localhost> <201303121845.08941.vbart@nginx.com> <513F4978.8090006@webmaster.spb.ru> Message-ID: <513F4ECE.5000309@csdoc.com> On 12.03.2013 17:27, denis wrote: >> Дело в том, что rewrite работает до auth_basic. > а где можно посмотреть схему, кто когда работает? кроме исходников. кстати да, очень много вопросов и непонимания как раз из-за того, что практически никто кроме разработчиков не знает что когда работает, на какой "фазе". и этой очень важной информации в документации нет... -- Best regards, Gena From lego12239 at yandex.ru Tue Mar 12 15:50:03 2013 From: lego12239 at yandex.ru (Oleg) Date: Tue, 12 Mar 2013 19:50:03 +0400 Subject: rewrite & $remote_user In-Reply-To: <201303121845.08941.vbart@nginx.com> References: <20130312105944.GA23025@localhost> <201303121845.08941.vbart@nginx.com> Message-ID: <20130312155003.GA15339@localhost> On Tue, Mar 12, 2013 at 06:45:08PM +0400, Валентин Бартенев wrote: > Дело в том, что rewrite работает до auth_basic. Но, если я ещё не ввёл пользователя/пароль, то меня не редиректит _до_ запроса пользователя/пароля. В браузере конечный uri я вижу после ввода пользователя/пароля. From vbart at nginx.com Tue Mar 12 15:58:59 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 12 Mar 2013 19:58:59 +0400 Subject: rewrite & $remote_user In-Reply-To: <513F4978.8090006@webmaster.spb.ru> References: <20130312105944.GA23025@localhost> <201303121845.08941.vbart@nginx.com> <513F4978.8090006@webmaster.spb.ru> Message-ID: <201303121958.59850.vbart@nginx.com> On Tuesday 12 March 2013 19:27:52 denis wrote: > 12.03.2013 18:45, Валентин Бартенев пишет: > > Дело в том, что rewrite работает до auth_basic. > > а где можно посмотреть схему, кто когда работает? кроме исходников. > Схемы пока нет. Но тут можно почитать немного об этом: http://www.aosabook.org/en/nginx.html -- Валентин Бартенев http://nginx.org/en/donation.html From vbart at nginx.com Tue Mar 12 16:09:43 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 12 Mar 2013 20:09:43 +0400 Subject: rewrite & $remote_user In-Reply-To: <20130312155003.GA15339@localhost> References: <20130312105944.GA23025@localhost> <201303121845.08941.vbart@nginx.com> <20130312155003.GA15339@localhost> Message-ID: <201303122009.43857.vbart@nginx.com> On Tuesday 12 March 2013 19:50:03 Oleg wrote: > On Tue, Mar 12, 2013 at 06:45:08PM +0400, Валентин Бартенев wrote: > > Дело в том, что rewrite работает до auth_basic. > > Но, если я ещё не ввёл пользователя/пароль, то меня не редиректит _до_ > запроса пользователя/пароля. В браузере конечный uri я вижу после ввода > пользователя/пароля. > Особенности работы браузера. Возможно, что он показывает модальное окно с запросом пароля до того, как меняет содержимое адресной строки. -- Валентин Бартенев http://nginx.org/en/donation.html From igor at sysoev.ru Tue Mar 12 16:43:33 2013 From: igor at sysoev.ru (Igor Sysoev) Date: Tue, 12 Mar 2013 20:43:33 +0400 Subject: rewrite & $remote_user In-Reply-To: <20130312105944.GA23025@localhost> References: <20130312105944.GA23025@localhost> Message-ID: <59B7B994-318C-49B2-9FC2-434BE79F3764@sysoev.ru> On Mar 12, 2013, at 14:59 , Oleg wrote: > Здравствуйте. > > Есть следующая конфигурация: > > location /test { > auth_basic "test zone"; > auth_basic_user_file /var/www/test/.htpasswd; > root /var/www; > > rewrite ^/test/?$ /test/user/$remote_user/f redirect; > } > > Хочется, что бы после аутентификации пользователя редиректило на его > страницу. Порядок (сначало аутентификация, потом перенаправление) работает > как подразумевается, а, вот, подстановка $remote_user не работает. В браузере > http://host/test даёт http://host/test/user//f. Если использовать, для примера, > $remote_addr, то подстановка работает как надо. location /test { auth_basic "test zone"; auth_basic_user_file /var/www/test/.htpasswd; root /var/www; location = /test { return 301 http://$host/test/user/$remote_user/f; } location = /test/ { return 301 http://$host/test/user/$remote_user/f; } } -- Igor Sysoev http://nginx.com/services.html From lego12239 at yandex.ru Tue Mar 12 18:50:37 2013 From: lego12239 at yandex.ru (Oleg) Date: Tue, 12 Mar 2013 22:50:37 +0400 Subject: rewrite & $remote_user In-Reply-To: <59B7B994-318C-49B2-9FC2-434BE79F3764@sysoev.ru> References: <20130312105944.GA23025@localhost> <59B7B994-318C-49B2-9FC2-434BE79F3764@sysoev.ru> Message-ID: <20130312185037.GA32106@localhost> On Tue, Mar 12, 2013 at 08:43:33PM +0400, Igor Sysoev wrote: > location /test { > auth_basic "test zone"; > auth_basic_user_file /var/www/test/.htpasswd; > root /var/www; > > location = /test { > return 301 http://$host/test/user/$remote_user/f; > } > > location = /test/ { > return 301 http://$host/test/user/$remote_user/f; > } > } Хех. То же самое. From nginx-forum at nginx.us Wed Mar 13 09:08:30 2013 From: nginx-forum at nginx.us (stitrace) Date: Wed, 13 Mar 2013 05:08:30 -0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDQutGN0YjQtdC5?= In-Reply-To: References: Message-ID: <67e145e594042d539815a1593b1acd7c.NginxMailingListRussian@forum.nginx.org> Разобрался, прошу прощения, банальная опечатка. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237281,237285#msg-237285 From vadim.lazovskiy at gmail.com Wed Mar 13 09:10:49 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Wed, 13 Mar 2013 13:10:49 +0400 Subject: =?UTF-8?B?0KHRgtGA0LDQvdC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUgdHJ5X2ZpbGVz?= Message-ID: Конфиг: location /images/ { alias /disks/links/v-links/; error_page 404 /notfound.jpg; location ~ ^/images/thumbs/(?.*)$ { try_files $image_path =404; image_filter resize $resize_width -; } } Версия: # /usr/local/nginx/sbin/nginx -V nginx version: nginx/1.2.7 built by gcc 4.6.2 (SUSE Linux) TLS SNI support enabled configure arguments: --prefix=/usr/local/nginx --error-log-path=/var/log/nginx/error_log --http-log-path=/var/log/nginx/access_log --http-client-body-temp-path=/var/nginx/client_body_temp --http-fastcgi-temp-path=/var/nginx/fastcgi_temp --pid-path=/var/run/nginx.pid --user=wwwrun --group=www --with-http_stub_status_module --with-cc-opt='-O3 -march=native -mtune=native' --with-http_ssl_module --with-http_dav_module --with-http_image_filter_module --add-module=../masterzen-nginx-upload-progress-module-82b35fc --add-module=../nginx_upload_module-2.2.0 --with-debug Результат: 2013/03/13 13:04:15 [debug] 21424#0: *19130 test location: "images/" 2013/03/13 13:04:15 [debug] 21424#0: *19130 test location: ~ "^/images/thumbs/(?.*)$" 2013/03/13 13:04:15 [debug] 21424#0: *19130 http regex set $image_path to "Ходячие Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking Dead).jpg" 2013/03/13 13:04:15 [debug] 21424#0: *19130 using configuration "^/images/thumbs/(?.*)$" 2013/03/13 13:04:15 [debug] 21424#0: *19130 http cl:-1 max:4294967296 2013/03/13 13:04:15 [debug] 21424#0: *19130 rewrite phase: 2 2013/03/13 13:04:15 [debug] 21424#0: *19130 rewrite phase: 3 2013/03/13 13:04:15 [debug] 21424#0: *19130 post rewrite phase: 4 2013/03/13 13:04:15 [debug] 21424#0: *19130 generic phase: 5 2013/03/13 13:04:15 [debug] 21424#0: *19130 generic phase: 6 2013/03/13 13:04:15 [debug] 21424#0: *19130 access phase: 7 2013/03/13 13:04:15 [debug] 21424#0: *19130 access phase: 8 2013/03/13 13:04:15 [debug] 21424#0: *19130 post access phase: 9 2013/03/13 13:04:15 [debug] 21424#0: *19130 try files phase: 10 2013/03/13 13:04:15 [debug] 21424#0: *19130 http script var: "Ходячие Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking Dead).jpg" 2013/03/13 13:04:15 [debug] 21424#0: *19130 trying to use file: "Ходячие Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking Dead).jpg" "/disks/links/v-links/Ходячие Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking Dead).jpg" 2013/03/13 13:04:15 [debug] 21424#0: *19130 try file uri: "Ходячие Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking Dead).jpg" 2013/03/13 13:04:15 [debug] 21424#0: *19130 content phase: 11 2013/03/13 13:04:15 [debug] 21424#0: *19130 content phase: 12 2013/03/13 13:04:15 [debug] 21424#0: *19130 content phase: 13 2013/03/13 13:04:15 [debug] 21424#0: *19130 content phase: 14 2013/03/13 13:04:15 [debug] 21424#0: *19130 http filename: "/disks/links/v-links/Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking Dead).jpg" 2013/03/13 13:04:15 [debug] 21424#0: *19130 add cleanup: 000000000077C558 2013/03/13 13:04:15 [error] 21424#0: *19130 open() "/disks/links/v-links/Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking Dead).jpg" failed (2: No such file or directory), client: 10.0.43.213, server: fs2.karelia.pro, request: "GET /images/thumbs/%E8%CF%C4%D1%DE%C9%C5%20%ED%C5%D2%D4%D7%C5%C3%D9%20%28The%20Walking%20Dead%29/%E8%CF%C4%D1%DE%C9%C5%20%ED%C5%D2%D4%D7%C5%C3%D9%20%28The%20Walking%20Dead%29.jpg?width=200 HTTP/1.1", host: "fs2.example.com" Вопрос такой, куда делось слово "Ходячие"? И как узнать что происходило в контент-фазах 11-14? Спасибо. -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.lazovskiy at gmail.com Wed Mar 13 09:20:08 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Wed, 13 Mar 2013 13:20:08 +0400 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IHRyeV9maWxl?= =?UTF-8?B?cw==?= In-Reply-To: References: Message-ID: Прошу прощения, здравствуйте забыл :) 2013/3/13 Vadim Lazovskiy > Конфиг: > > location /images/ { > alias /disks/links/v-links/; > error_page 404 /notfound.jpg; > > location ~ ^/images/thumbs/(?.*)$ { > try_files $image_path =404; > > image_filter resize $resize_width -; > } > } > > Версия: > > # /usr/local/nginx/sbin/nginx -V > nginx version: nginx/1.2.7 > built by gcc 4.6.2 (SUSE Linux) > TLS SNI support enabled > configure arguments: --prefix=/usr/local/nginx > --error-log-path=/var/log/nginx/error_log > --http-log-path=/var/log/nginx/access_log > --http-client-body-temp-path=/var/nginx/client_body_temp > --http-fastcgi-temp-path=/var/nginx/fastcgi_temp > --pid-path=/var/run/nginx.pid --user=wwwrun --group=www > --with-http_stub_status_module --with-cc-opt='-O3 -march=native > -mtune=native' --with-http_ssl_module --with-http_dav_module > --with-http_image_filter_module > --add-module=../masterzen-nginx-upload-progress-module-82b35fc > --add-module=../nginx_upload_module-2.2.0 --with-debug > > Результат: > > 2013/03/13 13:04:15 [debug] 21424#0: *19130 test location: "images/" > 2013/03/13 13:04:15 [debug] 21424#0: *19130 test location: ~ > "^/images/thumbs/(?.*)$" > 2013/03/13 13:04:15 [debug] 21424#0: *19130 http regex set $image_path to > "Ходячие Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking > Dead).jpg" > 2013/03/13 13:04:15 [debug] 21424#0: *19130 using configuration > "^/images/thumbs/(?.*)$" > 2013/03/13 13:04:15 [debug] 21424#0: *19130 http cl:-1 max:4294967296 > 2013/03/13 13:04:15 [debug] 21424#0: *19130 rewrite phase: 2 > 2013/03/13 13:04:15 [debug] 21424#0: *19130 rewrite phase: 3 > 2013/03/13 13:04:15 [debug] 21424#0: *19130 post rewrite phase: 4 > 2013/03/13 13:04:15 [debug] 21424#0: *19130 generic phase: 5 > 2013/03/13 13:04:15 [debug] 21424#0: *19130 generic phase: 6 > 2013/03/13 13:04:15 [debug] 21424#0: *19130 access phase: 7 > 2013/03/13 13:04:15 [debug] 21424#0: *19130 access phase: 8 > 2013/03/13 13:04:15 [debug] 21424#0: *19130 post access phase: 9 > 2013/03/13 13:04:15 [debug] 21424#0: *19130 try files phase: 10 > 2013/03/13 13:04:15 [debug] 21424#0: *19130 http script var: "Ходячие > Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking Dead).jpg" > 2013/03/13 13:04:15 [debug] 21424#0: *19130 trying to use file: "Ходячие > Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking Dead).jpg" > "/disks/links/v-links/Ходячие Мертвецы (The Walking Dead)/Ходячие Мертвецы > (The Walking Dead).jpg" > 2013/03/13 13:04:15 [debug] 21424#0: *19130 try file uri: "Ходячие > Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking Dead).jpg" > 2013/03/13 13:04:15 [debug] 21424#0: *19130 content phase: 11 > 2013/03/13 13:04:15 [debug] 21424#0: *19130 content phase: 12 > 2013/03/13 13:04:15 [debug] 21424#0: *19130 content phase: 13 > 2013/03/13 13:04:15 [debug] 21424#0: *19130 content phase: 14 > 2013/03/13 13:04:15 [debug] 21424#0: *19130 http filename: > "/disks/links/v-links/Мертвецы (The Walking Dead)/Ходячие Мертвецы (The > Walking Dead).jpg" > 2013/03/13 13:04:15 [debug] 21424#0: *19130 add cleanup: 000000000077C558 > 2013/03/13 13:04:15 [error] 21424#0: *19130 open() > "/disks/links/v-links/Мертвецы (The Walking Dead)/Ходячие Мертвецы (The > Walking Dead).jpg" failed (2: No such file or directory), client: > 10.0.43.213, server: fs2.karelia.pro, request: "GET > /images/thumbs/%E8%CF%C4%D1%DE%C9%C5%20%ED%C5%D2%D4%D7%C5%C3%D9%20%28The%20Walking%20Dead%29/%E8%CF%C4%D1%DE%C9%C5%20%ED%C5%D2%D4%D7%C5%C3%D9%20%28The%20Walking%20Dead%29.jpg?width=200 > HTTP/1.1", host: "fs2.example.com" > > Вопрос такой, куда делось слово "Ходячие"? > > И как узнать что происходило в контент-фазах 11-14? > > Спасибо. > > -- > Best Regards, > Vadim Lazovskiy > -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.lazovskiy at gmail.com Wed Mar 13 09:38:42 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Wed, 13 Mar 2013 13:38:42 +0400 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IHRyeV9maWxl?= =?UTF-8?B?cw==?= In-Reply-To: References: Message-ID: - try_files $image_path =404; + alias /disks/links/v-links/$image_path; так заработало. Просто для общего развития, не могли бы пояснить, что было не так? 2013/3/13 Vadim Lazovskiy > Прошу прощения, здравствуйте забыл :) > > > 2013/3/13 Vadim Lazovskiy > >> Конфиг: >> >> location /images/ { >> alias /disks/links/v-links/; >> error_page 404 /notfound.jpg; >> >> location ~ ^/images/thumbs/(?.*)$ { >> try_files $image_path =404; >> >> image_filter resize $resize_width -; >> } >> } >> >> Версия: >> >> # /usr/local/nginx/sbin/nginx -V >> nginx version: nginx/1.2.7 >> built by gcc 4.6.2 (SUSE Linux) >> TLS SNI support enabled >> configure arguments: --prefix=/usr/local/nginx >> --error-log-path=/var/log/nginx/error_log >> --http-log-path=/var/log/nginx/access_log >> --http-client-body-temp-path=/var/nginx/client_body_temp >> --http-fastcgi-temp-path=/var/nginx/fastcgi_temp >> --pid-path=/var/run/nginx.pid --user=wwwrun --group=www >> --with-http_stub_status_module --with-cc-opt='-O3 -march=native >> -mtune=native' --with-http_ssl_module --with-http_dav_module >> --with-http_image_filter_module >> --add-module=../masterzen-nginx-upload-progress-module-82b35fc >> --add-module=../nginx_upload_module-2.2.0 --with-debug >> >> Результат: >> >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 test location: "images/" >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 test location: ~ >> "^/images/thumbs/(?.*)$" >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 http regex set $image_path to >> "Ходячие Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking >> Dead).jpg" >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 using configuration >> "^/images/thumbs/(?.*)$" >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 http cl:-1 max:4294967296 >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 rewrite phase: 2 >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 rewrite phase: 3 >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 post rewrite phase: 4 >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 generic phase: 5 >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 generic phase: 6 >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 access phase: 7 >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 access phase: 8 >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 post access phase: 9 >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 try files phase: 10 >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 http script var: "Ходячие >> Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking Dead).jpg" >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 trying to use file: "Ходячие >> Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking Dead).jpg" >> "/disks/links/v-links/Ходячие Мертвецы (The Walking Dead)/Ходячие Мертвецы >> (The Walking Dead).jpg" >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 try file uri: "Ходячие >> Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking Dead).jpg" >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 content phase: 11 >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 content phase: 12 >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 content phase: 13 >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 content phase: 14 >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 http filename: >> "/disks/links/v-links/Мертвецы (The Walking Dead)/Ходячие Мертвецы (The >> Walking Dead).jpg" >> 2013/03/13 13:04:15 [debug] 21424#0: *19130 add cleanup: 000000000077C558 >> 2013/03/13 13:04:15 [error] 21424#0: *19130 open() >> "/disks/links/v-links/Мертвецы (The Walking Dead)/Ходячие Мертвецы (The >> Walking Dead).jpg" failed (2: No such file or directory), client: >> 10.0.43.213, server: fs2.karelia.pro, request: "GET >> /images/thumbs/%E8%CF%C4%D1%DE%C9%C5%20%ED%C5%D2%D4%D7%C5%C3%D9%20%28The%20Walking%20Dead%29/%E8%CF%C4%D1%DE%C9%C5%20%ED%C5%D2%D4%D7%C5%C3%D9%20%28The%20Walking%20Dead%29.jpg?width=200 >> HTTP/1.1", host: "fs2.example.com" >> >> Вопрос такой, куда делось слово "Ходячие"? >> >> И как узнать что происходило в контент-фазах 11-14? >> >> Спасибо. >> >> -- >> Best Regards, >> Vadim Lazovskiy >> > > > > -- > Best Regards, > Vadim Lazovskiy > -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.vasilishin at kpi.ua Wed Mar 13 09:43:26 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Wed, 13 Mar 2013 11:43:26 +0200 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IHRyeV9maWxl?= =?UTF-8?B?cw==?= In-Reply-To: References: Message-ID: <51404A3E.8080603@kpi.ua> 13.03.2013 11:38, Vadim Lazovskiy пишет: > - try_files $image_path =404; > + alias /disks/links/v-links/$image_path; > > так заработало. > > Просто для общего развития, не могли бы пояснить, что было не так? А самому по дебаг логу не понятно? В случае try_files 2 раза вставляется $image_path From vadim.lazovskiy at gmail.com Wed Mar 13 09:48:15 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Wed, 13 Mar 2013 13:48:15 +0400 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IHRyeV9maWxl?= =?UTF-8?B?cw==?= In-Reply-To: <51404A3E.8080603@kpi.ua> References: <51404A3E.8080603@kpi.ua> Message-ID: Нет, 2013/03/13 13:04:15 [debug] 21424#0: *19130 trying to use file: "Ходячие Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking Dead).jpg" "/disks/links/v-links/Ходячие Мертвецы (The Walking Dead)/Ходячие Мертвецы (The Walking Dead).jpg" Путь корректный. Папка и файл. И файл по данному пути есть. 13 марта 2013 г., 13:43 пользователь Андрей Василишин написал: > 13.03.2013 11:38, Vadim Lazovskiy пишет: > > - try_files $image_path =404; >> + alias /disks/links/v-links/$image_**path; >> >> так заработало. >> >> Просто для общего развития, не могли бы пояснить, что было не так? >> > > > > А самому по дебаг логу не понятно? > В случае try_files 2 раза вставляется $image_path > > ______________________________**_________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/**mailman/listinfo/nginx-ru -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Mar 13 11:33:45 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 13 Mar 2013 15:33:45 +0400 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IHRyeV9maWxl?= =?UTF-8?B?cw==?= In-Reply-To: References: Message-ID: <20130313113344.GX15378@mdounin.ru> Hello! On Wed, Mar 13, 2013 at 01:38:42PM +0400, Vadim Lazovskiy wrote: > - try_files $image_path =404; > + alias /disks/links/v-links/$image_path; > > так заработало. > > Просто для общего развития, не могли бы пояснить, что было не так? alias + try_files = проблемы http://trac.nginx.org/nginx/ticket/97 Судя по логу - видимо строка "Ходящие " была заменена на значение alias, как соответствующая совпадению URI location /images/ (note: и там и там - 8 байт). С учётом того, что try_files проверял другой путь, - это явно баг, видимо тесно связанный с последним из приведённых case'ов по ссылке выше. -- Maxim Dounin http://nginx.org/en/donation.html From vadim.lazovskiy at gmail.com Wed Mar 13 11:48:13 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Wed, 13 Mar 2013 15:48:13 +0400 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IHRyeV9maWxl?= =?UTF-8?B?cw==?= In-Reply-To: <20130313113344.GX15378@mdounin.ru> References: <20130313113344.GX15378@mdounin.ru> Message-ID: Спасибо за разъяснения! 13 марта 2013 г., 15:33 пользователь Maxim Dounin написал: > Hello! > > On Wed, Mar 13, 2013 at 01:38:42PM +0400, Vadim Lazovskiy wrote: > > > - try_files $image_path =404; > > + alias /disks/links/v-links/$image_path; > > > > так заработало. > > > > Просто для общего развития, не могли бы пояснить, что было не так? > > alias + try_files = проблемы > http://trac.nginx.org/nginx/ticket/97 > > Судя по логу - видимо строка "Ходящие " была заменена на значение > alias, как соответствующая совпадению URI location /images/ (note: > и там и там - 8 байт). С учётом того, что try_files проверял > другой путь, - это явно баг, видимо тесно связанный с последним > из приведённых case'ов по ссылке выше. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From swood at fotofor.biz Wed Mar 13 14:25:15 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Wed, 13 Mar 2013 18:25:15 +0400 Subject: =?UTF-8?B?0J/QtdGA0LXQt9Cw0L/Rg9GB0Log0LrRjdGILdC80LXQvdC10LTQttC10YDQsA==?= Message-ID: Всем привет. Возник вопрос с тем, как перезапустить только процесс кэш-менеджера, не трогая основной процесс и работающих воркеров? -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Wed Mar 13 14:40:25 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 13 Mar 2013 18:40:25 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: References: Message-ID: <1197148954.20130313184025@softsearch.ru> Здравствуйте, Anton. http://nginx.org/ru/docs/control.html -- С уважением, Михаил mailto:postmaster at softsearch.ru From swood at fotofor.biz Wed Mar 13 14:43:25 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Wed, 13 Mar 2013 18:43:25 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: <1197148954.20130313184025@softsearch.ru> References: <1197148954.20130313184025@softsearch.ru> Message-ID: А где там про кэш-менеджер? 2013/3/13 Михаил Монашёв > Здравствуйте, Anton. > > http://nginx.org/ru/docs/control.html > > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Mar 13 14:53:59 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 13 Mar 2013 18:53:59 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: References: Message-ID: <20130313145359.GB15378@mdounin.ru> Hello! On Wed, Mar 13, 2013 at 06:25:15PM +0400, Anton Kiryushkin wrote: > Возник вопрос с тем, как перезапустить только процесс кэш-менеджера, не > трогая основной процесс и работающих воркеров? Никак. -- Maxim Dounin http://nginx.org/en/donation.html From andrey at kopeyko.ru Wed Mar 13 15:24:11 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Wed, 13 Mar 2013 19:24:11 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: <20130313145359.GB15378@mdounin.ru> References: <20130313145359.GB15378@mdounin.ru> Message-ID: <51409A1B.6040001@kopeyko.ru> 13.03.2013 18:53, Maxim Dounin пишет: > Hello! > > On Wed, Mar 13, 2013 at 06:25:15PM +0400, Anton Kiryushkin wrote: > >> Возник вопрос с тем, как перезапустить только процесс кэш-менеджера, не >> трогая основной процесс и работающих воркеров? > > Никак. Почему же никак - upgrade на лету даст, насколько я понимаю, желаемый эффект. Правда, ценой перезапуска воркеров без прерывания обслуживания клиентов, переоткрытия логов, и т.д. и т.п. .... -- Best regards, Andrey Kopeyko From swood at fotofor.biz Wed Mar 13 15:25:20 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Wed, 13 Mar 2013 19:25:20 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: <51409A1B.6040001@kopeyko.ru> References: <20130313145359.GB15378@mdounin.ru> <51409A1B.6040001@kopeyko.ru> Message-ID: Вот воркеров как раз и не хочется перезапускать, так как это очень большие накладные затраты по ресурсам. 13 марта 2013 г., 19:24 пользователь Andrey Kopeyko написал: > 13.03.2013 18:53, Maxim Dounin пишет: > > Hello! >> >> On Wed, Mar 13, 2013 at 06:25:15PM +0400, Anton Kiryushkin wrote: >> >> Возник вопрос с тем, как перезапустить только процесс кэш-менеджера, не >>> трогая основной процесс и работающих воркеров? >>> >> >> Никак. >> > > Почему же никак - upgrade на лету даст, насколько я понимаю, желаемый > эффект. Правда, ценой перезапуска воркеров без прерывания обслуживания > клиентов, переоткрытия логов, и т.д. и т.п. .... > > > -- > Best regards, > Andrey Kopeyko > > > ______________________________**_________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/**mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey at kopeyko.ru Wed Mar 13 15:28:31 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Wed, 13 Mar 2013 19:28:31 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: References: <20130313145359.GB15378@mdounin.ru> <51409A1B.6040001@kopeyko.ru> Message-ID: <51409B1F.1000904@kopeyko.ru> 13.03.2013 19:25, Anton Kiryushkin пишет: > Вот воркеров как раз и не хочется перезапускать, так как это очень > большие накладные затраты по ресурсам. Чем же таким тяжелым ваши воркеры занимаются на старте? > 13 марта 2013 г., 19:24 пользователь Andrey Kopeyko > написал: > > 13.03.2013 18:53, Maxim Dounin пишет: > > Hello! > > On Wed, Mar 13, 2013 at 06:25:15PM +0400, Anton Kiryushkin wrote: > > Возник вопрос с тем, как перезапустить только процесс > кэш-менеджера, не > трогая основной процесс и работающих воркеров? > > > Никак. > > > Почему же никак - upgrade на лету даст, насколько я понимаю, > желаемый эффект. Правда, ценой перезапуска воркеров без прерывания > обслуживания клиентов, переоткрытия логов, и т.д. и т.п. .... > > -- Best regards, Andrey Kopeyko From swood at fotofor.biz Wed Mar 13 16:04:38 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Wed, 13 Mar 2013 20:04:38 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: <51409B1F.1000904@kopeyko.ru> References: <20130313145359.GB15378@mdounin.ru> <51409A1B.6040001@kopeyko.ru> <51409B1F.1000904@kopeyko.ru> Message-ID: Просто очень много подключения к ним. Очень много. 13 марта 2013 г., 19:28 пользователь Andrey Kopeyko написал: > 13.03.2013 19:25, Anton Kiryushkin пишет: > > Вот воркеров как раз и не хочется перезапускать, так как это очень >> большие накладные затраты по ресурсам. >> > > Чем же таким тяжелым ваши воркеры занимаются на старте? > > 13 марта 2013 г., 19:24 пользователь Andrey Kopeyko > > написал: >> >> >> 13.03.2013 18:53, Maxim Dounin пишет: >> >> Hello! >> >> On Wed, Mar 13, 2013 at 06:25:15PM +0400, Anton Kiryushkin wrote: >> >> Возник вопрос с тем, как перезапустить только процесс >> кэш-менеджера, не >> трогая основной процесс и работающих воркеров? >> >> >> Никак. >> >> >> Почему же никак - upgrade на лету даст, насколько я понимаю, >> желаемый эффект. Правда, ценой перезапуска воркеров без прерывания >> обслуживания клиентов, переоткрытия логов, и т.д. и т.п. .... >> >> >> > > -- > Best regards, > Andrey Kopeyko > > ______________________________**_________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/**mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at webmaster.spb.ru Wed Mar 13 16:12:19 2013 From: denis at webmaster.spb.ru (denis) Date: Wed, 13 Mar 2013 20:12:19 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: References: <20130313145359.GB15378@mdounin.ru> <51409A1B.6040001@kopeyko.ru> <51409B1F.1000904@kopeyko.ru> Message-ID: <5140A563.3050101@webmaster.spb.ru> 13.03.2013 20:04, Anton Kiryushkin пишет: > Просто очень много подключения к ним. Очень много. > Вы не путаете reload и restart случаем? reload вполне себе лёгкий, с плавным перезапуском From gmm at csdoc.com Wed Mar 13 16:17:34 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Wed, 13 Mar 2013 18:17:34 +0200 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: References: Message-ID: <5140A69E.3030005@csdoc.com> On 13.03.2013 16:25, Anton Kiryushkin wrote: > Возник вопрос с тем, как перезапустить только процесс кэш-менеджера, не > трогая основной процесс и работающих воркеров? зачем его перезапускать, в его работе есть какие-то проблемы? может быть имеет смысл пофиксить проблему из-за чего он падает, тогда и вручную ничего перезапускать не надо будет? -- Best regards, Gena From swood at fotofor.biz Wed Mar 13 18:41:02 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Wed, 13 Mar 2013 22:41:02 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: <5140A69E.3030005@csdoc.com> References: <5140A69E.3030005@csdoc.com> Message-ID: Нет, reload не путается с restart. К тому же не забывайте, что при reload, создаются две копии рабочих процессов. Это может быть достаточно серьезной нагрузкой на сервер, которую не хочется лишний раз запускать. Перезапуск же кэш-менеджера может быть полезен, например, для изменения параметров кэширования. То есть, изменили параметры кэширования, перезапустили соответствующую службу, или дали команду перечитать конфиг. 13 марта 2013 г., 20:17 пользователь Gena Makhomed написал: > On 13.03.2013 16:25, Anton Kiryushkin wrote: > > Возник вопрос с тем, как перезапустить только процесс кэш-менеджера, не >> трогая основной процесс и работающих воркеров? >> > > зачем его перезапускать, в его работе есть какие-то проблемы? > может быть имеет смысл пофиксить проблему из-за чего он падает, > тогда и вручную ничего перезапускать не надо будет? > > -- > Best regards, > Gena > > > ______________________________**_________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/**mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From onokonem at gmail.com Wed Mar 13 18:52:07 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 13 Mar 2013 22:52:07 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: References: <5140A69E.3030005@csdoc.com> Message-ID: > К тому же не забывайте, что при reload, создаются две копии рабочих > процессов. Это может быть достаточно серьезной нагрузкой на сервер, которую > не хочется лишний раз запускать. Нагрузку на сервер создают не рабочие процессы (их же не тысячи, и даже не сотни), а соединения, которых от релоада больше не становится. From postmaster at softsearch.ru Wed Mar 13 21:32:03 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 14 Mar 2013 01:32:03 +0400 Subject: =?UTF-8?B?UmVbMl06INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LY=?= =?UTF-8?B?0LXRgNCw?= In-Reply-To: References: <5140A69E.3030005@csdoc.com> Message-ID: <1839408209.20130314013203@softsearch.ru> Здравствуйте, Daniel. >> К тому же не забывайте, что при reload, создаются две копии рабочих >> процессов. Это может быть достаточно серьезной нагрузкой на сервер, >> которую не хочется лишний раз запускать. > Нагрузку на сервер создают не рабочие процессы (их же не тысячи, и > даже не сотни), а соединения, которых от релоада больше не > становится. На самом деле проблема такая есть. При релоаде старые процессы ещё кушают память, и новым может её перестать хватать, если памяти впритык. А несколько реалоадов подряд вообще всю память съедят. Не знаю, какой случай у топикстартера, но видимо сильно экстремальный, раз он релоад боится делать и видимо раздача видео в плееры или почта, раз рестарт не приемлем. -- С уважением, Михаил mailto:postmaster at softsearch.ru From swood at fotofor.biz Wed Mar 13 22:05:59 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Thu, 14 Mar 2013 02:05:59 +0400 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQn9C10YDQtdC30LDQv9GD0YHQuiDQutGN0Ygt0LzQtdC90LU=?= =?UTF-8?B?0LTQttC10YDQsA==?= In-Reply-To: <1839408209.20130314013203@softsearch.ru> References: <5140A69E.3030005@csdoc.com> <1839408209.20130314013203@softsearch.ru> Message-ID: Да, Михаил. У нас именно такая ситуация. Раздаем очень много разного статического контента. И несколько раз приходится думать перед тем, как сказать reload. Собственно поэтому и созникает вопрос, отраженный в топике. Да и в принципе ответ уже получен. Спасибо. 14 марта 2013 г., 1:32 пользователь Михаил Монашёв написал: > Здравствуйте, Daniel. > > >> К тому же не забывайте, что при reload, создаются две копии рабочих > >> процессов. Это может быть достаточно серьезной нагрузкой на сервер, > >> которую не хочется лишний раз запускать. > > Нагрузку на сервер создают не рабочие процессы (их же не тысячи, и > > даже не сотни), а соединения, которых от релоада больше не > > становится. > > На самом деле проблема такая есть. При релоаде старые процессы ещё > кушают память, и новым может её перестать хватать, если памяти > впритык. А несколько реалоадов подряд вообще всю память съедят. > > Не знаю, какой случай у топикстартера, но видимо сильно экстремальный, > раз он релоад боится делать и видимо раздача видео в плееры или почта, > раз рестарт не приемлем. > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From onokonem at gmail.com Thu Mar 14 06:21:26 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 14 Mar 2013 10:21:26 +0400 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQn9C10YDQtdC30LDQv9GD0YHQuiDQutGN0Ygt0LzQtdC90LU=?= =?UTF-8?B?0LTQttC10YDQsA==?= In-Reply-To: <1839408209.20130314013203@softsearch.ru> References: <5140A69E.3030005@csdoc.com> <1839408209.20130314013203@softsearch.ru> Message-ID: > При релоаде старые процессы ещё > кушают память, и новым может её перестать хватать, если памяти > впритык. Я прошу прощения за то, что мусмолю тему, которую сам топик-стартер считает закрытой. Но мне непонятен механизм возникновения. Не хватает тех жалких нескольких метров, что ест собственно воркер? Или воркер при старте выделяет буфера, и памяти не хватает на их двойной комплект? Или соединения поступают быстрее, чем обычно успевают обрабатываться, и при релоаде в обработке может оказаться двойное от максимума их количество? From denis at webmaster.spb.ru Thu Mar 14 06:51:45 2013 From: denis at webmaster.spb.ru (denis) Date: Thu, 14 Mar 2013 10:51:45 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: References: <5140A69E.3030005@csdoc.com> <1839408209.20130314013203@softsearch.ru> Message-ID: <51417381.40407@webmaster.spb.ru> 14.03.2013 2:05, Anton Kiryushkin пишет: > Да, Михаил. У нас именно такая ситуация. Раздаем очень много разного > статического контента. И несколько раз приходится думать перед тем, > как сказать reload. Собственно поэтому и созникает вопрос, отраженный > в топике. Да и в принципе ответ уже получен. Спасибо. > А у вас нет системы балансировки нагрузки? И всё раздаётся с 1 машины? В правильной системе ведь отказ 1 ноды не должен создать проблем.. Видимо, вам надо писать свой модуль для управления кэшем или просто под свои задачи допиливать nginx. From swood at fotofor.biz Thu Mar 14 09:06:02 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Thu, 14 Mar 2013 13:06:02 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: <51417381.40407@webmaster.spb.ru> References: <5140A69E.3030005@csdoc.com> <1839408209.20130314013203@softsearch.ru> <51417381.40407@webmaster.spb.ru> Message-ID: Отвечаю по-порядку. 1. На нашей нагрузке на nginx, процесс может съедать и гигабайт. 2. Соединения происходят очень быстро и в громадном числе, будем исчислять их миллионами в секунду. 3. Сервер конечно же не один. Но каждый из них обрабатывает большое число запросов. И потерять хотя бы один из них на небольшой промежуток времени очень тяжело. 14 марта 2013 г., 10:51 пользователь denis написал: > 14.03.2013 2:05, Anton Kiryushkin пишет: > > Да, Михаил. У нас именно такая ситуация. Раздаем очень много разного >> статического контента. И несколько раз приходится думать перед тем, как >> сказать reload. Собственно поэтому и созникает вопрос, отраженный в топике. >> Да и в принципе ответ уже получен. Спасибо. >> >> А у вас нет системы балансировки нагрузки? И всё раздаётся с 1 машины? В > правильной системе ведь отказ 1 ноды не должен создать проблем.. > Видимо, вам надо писать свой модуль для управления кэшем или просто под > свои задачи допиливать nginx. > > > ______________________________**_________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/**mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From onokonem at gmail.com Thu Mar 14 10:09:42 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 14 Mar 2013 14:09:42 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: References: <5140A69E.3030005@csdoc.com> <1839408209.20130314013203@softsearch.ru> <51417381.40407@webmaster.spb.ru> Message-ID: > 1. На нашей нагрузке на nginx, процесс может съедать и гигабайт. То, что он съедает под нагрузкой - не очень важно. Важно - сколько он занимает на старте, еще не приняв ни одного соединения. Потому как старый воркер должен успеть соединения обработать и завершиться, освободив память, раньше, чем новый раздуется достаточно. Или не успевает? > 2. Соединения происходят очень быстро и в громадном числе, будем исчислять > их миллионами в секунду. Важно не абсолютное количество, а скорость обработки. Вы успеваете обработать все входящие соединения, и часть дропается? > 3. Сервер конечно же не один. Но каждый из них обрабатывает большое число > запросов. И потерять хотя бы один из них на небольшой промежуток времени > очень тяжело. В учебнике написано - один элемент из кластера должен изыматься безболезненно. Иначе не обеспечивается отказоустойчивость. From swood at fotofor.biz Thu Mar 14 10:43:19 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Thu, 14 Mar 2013 14:43:19 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: References: <5140A69E.3030005@csdoc.com> <1839408209.20130314013203@softsearch.ru> <51417381.40407@webmaster.spb.ru> Message-ID: Да, мы успеваем обработать каждый запрос. Да, они не успевают завершиться, освободив память. Да, если это необходимо, то сервер можно изъять из кластера. Но вопрос как раз и был в том, что сервер из кластера не изымать для перезапуска или reload-а nginx, а спокойно перезапустить нужную нам службу. Разговор уже идет в сторону - мы научим вас как делать правильно? Спасибо, это не требуется. 14 марта 2013 г., 14:09 пользователь Daniel Podolsky написал: > > 1. На нашей нагрузке на nginx, процесс может съедать и гигабайт. > То, что он съедает под нагрузкой - не очень важно. Важно - сколько он > занимает на старте, еще не приняв ни одного соединения. Потому как > старый воркер должен успеть соединения обработать и завершиться, > освободив память, раньше, чем новый раздуется достаточно. Или не > успевает? > > > 2. Соединения происходят очень быстро и в громадном числе, будем > исчислять > > их миллионами в секунду. > Важно не абсолютное количество, а скорость обработки. Вы успеваете > обработать все входящие соединения, и часть дропается? > > > 3. Сервер конечно же не один. Но каждый из них обрабатывает большое число > > запросов. И потерять хотя бы один из них на небольшой промежуток времени > > очень тяжело. > В учебнике написано - один элемент из кластера должен изыматься > безболезненно. Иначе не обеспечивается отказоустойчивость. > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From onokonem at gmail.com Thu Mar 14 10:59:14 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 14 Mar 2013 14:59:14 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: References: <5140A69E.3030005@csdoc.com> <1839408209.20130314013203@softsearch.ru> <51417381.40407@webmaster.spb.ru> Message-ID: > Разговор уже идет в сторону - мы научим вас как делать правильно? Спасибо, > это не требуется. Ни в коем случае! Есть проблема, с которой я не сталкивался (но могу же и столкнуться когда-нибудь), и корня которой я не понимаю. Вот я и спрашиваю - что к чему. Если позволите - еще один вопрос. Если вы успеваете обрабатывать все соединения - старый воркер по любому должен терять вес быстрее, чем новый - набирать. Но этого не происходит, как я понял. Почему? From citrin at citrin.ru Thu Mar 14 11:11:55 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Thu, 14 Mar 2013 15:11:55 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: References: <5140A69E.3030005@csdoc.com> <1839408209.20130314013203@softsearch.ru> <51417381.40407@webmaster.spb.ru> Message-ID: <5141B07B.9020102@citrin.ru> On 03/14/13 14:59, Daniel Podolsky wrote: > Если вы успеваете обрабатывать все соединения - старый воркер по > любому должен терять вес быстрее, чем новый - набирать. Но этого не > происходит, как я понял. Почему? Особенность большинства реализация malloc - после free помять возвращается в пул OS не сразу: в худшем случае после завершения процесса, в лучшем когда освободится большой непрерывный участок памяти. В случае nginx память перед выходом скорее всего будет фрагментирована, и небольшое число завершающихся соединений будут мешать вернуть другим процессам относительно большой объем памяти. Но в современных условиях проще иметь на сервере двух или трехкратный запас памяти. Полезно не только для безболезненных reload, но и для кэширования файлов средствами VM (включая файлы в кеше). Если же у вас в серверах уже стоит по 32Gb памяти и больше, но nginx её всю съедает, возможно стоит поразбираться зачем ему так много надо, и если получится - покрутить настройки, чтобы он кушал меньше. From nginx-forum at nginx.us Thu Mar 14 13:02:23 2013 From: nginx-forum at nginx.us (reaper) Date: Thu, 14 Mar 2013 09:02:23 -0400 Subject: =?UTF-8?B?0YDQtdCz0LXQutGB0L8g0LIgc2VydmVyIG5hbWU=?= Message-ID: <5822b310a86badb824ced0059c9afa6a.NginxMailingListRussian@forum.nginx.org> пытаюсь скопировать из примера server_name ~^www\d\.example\.net$; на curl -H 'Host: www0.example.net' http://127.0.0.1/ не реагирует. если вписывать каждый из 0, 1...9 отдельно, все работает как должно. ошибок при перезагрузке нет, в логе только вот такое 2013/03/14 12:40:34 [error] 21703#0: *162689 open() "/var/www/js/common.js" failed (2: No such file or directory), client: 127.0.0.1, server: localhost, request: "GET /js/common.js HTTP/1.1", host: "www0.example.net" nginx 1.2.7 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237350,237350#msg-237350 From nginx-forum at nginx.us Thu Mar 14 13:10:06 2013 From: nginx-forum at nginx.us (anon) Date: Thu, 14 Mar 2013 09:10:06 -0400 Subject: =?UTF-8?Q?server_name_=22=22_444_=D0=B8_200?= Message-ID: <64eabca7607e77eb4ca1f1cf9b07a53b.NginxMailingListRussian@forum.nginx.org> Привет. Хочется сделать исключение в таком server. Что бы на /check отвечало 200, а остальных ботов в 444. Как лучше? server { listen *:80 default; server_name _ ""; location = /check{ return 200; } return 444; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237351,237351#msg-237351 From vbart at nginx.com Thu Mar 14 15:08:43 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 14 Mar 2013 19:08:43 +0400 Subject: =?UTF-8?Q?Re=3A_server_name_=22=22_444_=D0=B8_200?= In-Reply-To: <64eabca7607e77eb4ca1f1cf9b07a53b.NginxMailingListRussian@forum.nginx.org> References: <64eabca7607e77eb4ca1f1cf9b07a53b.NginxMailingListRussian@forum.nginx.org> Message-ID: <201303141908.43951.vbart@nginx.com> On Thursday 14 March 2013 17:10:06 anon wrote: > Привет. > > Хочется сделать исключение в таком server. Что бы на /check отвечало 200, а > остальных ботов в 444. Как лучше? > > server { > listen *:80 default; > server_name _ ""; Символ подчеркивания тут зачем? > location = /check{ > return 200; > } > return 444; > > } > -- Валентин Бартенев http://nginx.org/en/donation.html From mdounin at mdounin.ru Thu Mar 14 15:10:50 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 14 Mar 2013 19:10:50 +0400 Subject: =?UTF-8?Q?Re=3A_server_name_=22=22_444_=D0=B8_200?= In-Reply-To: <64eabca7607e77eb4ca1f1cf9b07a53b.NginxMailingListRussian@forum.nginx.org> References: <64eabca7607e77eb4ca1f1cf9b07a53b.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130314151050.GK15378@mdounin.ru> Hello! On Thu, Mar 14, 2013 at 09:10:06AM -0400, anon wrote: > Привет. > > Хочется сделать исключение в таком server. Что бы на /check отвечало 200, а > остальных ботов в 444. Как лучше? > > server { > listen *:80 default; > server_name _ ""; > location = /check{ > return 200; > } > return 444; > > } Лучше так: location / { return 444; } location = /check { return 200; } -- Maxim Dounin http://nginx.org/en/donation.html From vbart at nginx.com Thu Mar 14 15:11:04 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 14 Mar 2013 19:11:04 +0400 Subject: =?UTF-8?B?UmU6INGA0LXQs9C10LrRgdC/INCyIHNlcnZlciBuYW1l?= In-Reply-To: <5822b310a86badb824ced0059c9afa6a.NginxMailingListRussian@forum.nginx.org> References: <5822b310a86badb824ced0059c9afa6a.NginxMailingListRussian@forum.nginx.org> Message-ID: <201303141911.04646.vbart@nginx.com> On Thursday 14 March 2013 17:02:23 reaper wrote: > пытаюсь скопировать из примера > > server_name ~^www\d\.example\.net$; > Это единственный server_name или есть ещё где-то другие? -- Валентин Бартенев http://nginx.org/en/donation.html > на curl -H 'Host: www0.example.net' http://127.0.0.1/ не реагирует. если > вписывать каждый из 0, 1...9 отдельно, все работает как должно. ошибок при > перезагрузке нет, в логе только вот такое > > 2013/03/14 12:40:34 [error] 21703#0: *162689 open() "/var/www/js/common.js" > failed (2: No such file or directory), client: 127.0.0.1, server: > localhost, request: "GET /js/common.js HTTP/1.1", host: "www0.example.net" > > nginx 1.2.7 > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,237350,237350#msg-237350 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Thu Mar 14 15:18:22 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 14 Mar 2013 19:18:22 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LfQsNC/0YPRgdC6INC60Y3RiC3QvNC10L3QtdC00LbQtdGA?= =?UTF-8?B?0LA=?= In-Reply-To: References: <5140A69E.3030005@csdoc.com> Message-ID: <201303141918.22239.vbart@nginx.com> On Wednesday 13 March 2013 22:41:02 Anton Kiryushkin wrote: > Нет, reload не путается с restart. К тому же не забывайте, что при reload, > создаются две копии рабочих процессов. Это может быть достаточно серьезной > нагрузкой на сервер, которую не хочется лишний раз запускать. > > Перезапуск же кэш-менеджера может быть полезен, например, для изменения > параметров кэширования. То есть, изменили параметры кэширования, > перезапустили соответствующую службу, или дали команду перечитать конфиг. > Большинство параметров кэширования в первую очередь влияют на рабочие процессы. Кэш-менеджер занимается лишь мелкой утилитарной деятельностью - слежкой за объемом кэша на жестком диске. -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Mar 14 17:11:08 2013 From: nginx-forum at nginx.us (botbot) Date: Thu, 14 Mar 2013 13:11:08 -0400 Subject: rewtite /back/struct => /back/index.php/struct Message-ID: <9ae85634841d55ef982ac20662c61e38.NginxMailingListRussian@forum.nginx.org> Нужно переводить ссылку вида site.ru/back/struct в site.ru/back/index.php/struct и отдавать в пхп. Пытаюсь написать конфиг под подобное поведение, но ничего не получается. В апаче было просто: .htaccess файл в директорию back и текстом RewriteRule ^(.*)$ index.php [L,QSA]. В nginx способ до сих пор не нашёл. Вот, например, один из вариантов: location /back { if (!-e $request_filename) { rewrite ^/(.*) /back/index.php/$1; } location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(/.+)$; # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini # With php5-cgi alone: # fastcgi_pass 127.0.0.1:9000; # With php5-fpm: fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; include fastcgi_params; } } Выдаёт 500-ю ошибку. Помогите, пожалуйста. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237371,237371#msg-237371 From nginx-forum at nginx.us Thu Mar 14 19:41:33 2013 From: nginx-forum at nginx.us (anon) Date: Thu, 14 Mar 2013 15:41:33 -0400 Subject: =?UTF-8?Q?Re=3A_server_name_=22=22_444_=D0=B8_200?= In-Reply-To: <201303141908.43951.vbart@nginx.com> References: <201303141908.43951.vbart@nginx.com> Message-ID: <57615da2e74aec55a5d5bd783ea8838d.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Thursday 14 March 2013 17:10:06 anon wrote: > > Привет. > > > > Хочется сделать исключение в таком server. Что бы на /check отвечало > 200, а > > остальных ботов в 444. Как лучше? > > > > server { > > listen *:80 default; > > server_name _ ""; > > Символ подчеркивания тут зачем? > > > location = /check{ > > return 200; > > } > > return 444; > > > > } > > > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Спасибо. На счет символа подчеркивания, то вот отсюда у Игоря подсмотрено. http://forum.nginx.org/read.php?2,9695,12089#msg-12089 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237355,237375#msg-237375 From nginx-forum at nginx.us Thu Mar 14 19:44:02 2013 From: nginx-forum at nginx.us (anon) Date: Thu, 14 Mar 2013 15:44:02 -0400 Subject: =?UTF-8?Q?Re=3A_server_name_=22=22_444_=D0=B8_200?= In-Reply-To: <57615da2e74aec55a5d5bd783ea8838d.NginxMailingListRussian@forum.nginx.org> References: <201303141908.43951.vbart@nginx.com> <57615da2e74aec55a5d5bd783ea8838d.NginxMailingListRussian@forum.nginx.org> Message-ID: <7174863b95c75fcb12a91717b9fb7fd4.NginxMailingListRussian@forum.nginx.org> > > location = /check{ > > return 200; > > } > > return 444; > > > > } Все равно возвращает 444. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237355,237376#msg-237376 From vbart at nginx.com Thu Mar 14 20:13:02 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 15 Mar 2013 00:13:02 +0400 Subject: =?UTF-8?Q?Re=3A_server_name_=22=22_444_=D0=B8_200?= In-Reply-To: <7174863b95c75fcb12a91717b9fb7fd4.NginxMailingListRussian@forum.nginx.org> References: <201303141908.43951.vbart@nginx.com> <57615da2e74aec55a5d5bd783ea8838d.NginxMailingListRussian@forum.nginx.org> <7174863b95c75fcb12a91717b9fb7fd4.NginxMailingListRussian@forum.nginx.org> Message-ID: <201303150013.02068.vbart@nginx.com> On Thursday 14 March 2013 23:44:02 anon wrote: > > > location = /check{ > > > return 200; > > > } > > > return 444; > > > > > > } > > Все равно возвращает 444. > Естественно, читайте: http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html начиная с фразы: "Директивы модуля ngx_http_rewrite_module обрабатываются в следующем порядке" Как исправить, Максим вам уже подсказал: location / { return 444; } location = /check { return 200; } -- Валентин Бартенев http://nginx.org/en/donation.html From vbart at nginx.com Thu Mar 14 20:18:47 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 15 Mar 2013 00:18:47 +0400 Subject: =?UTF-8?Q?Re=3A_server_name_=22=22_444_=D0=B8_200?= In-Reply-To: <57615da2e74aec55a5d5bd783ea8838d.NginxMailingListRussian@forum.nginx.org> References: <201303141908.43951.vbart@nginx.com> <57615da2e74aec55a5d5bd783ea8838d.NginxMailingListRussian@forum.nginx.org> Message-ID: <201303150018.47152.vbart@nginx.com> On Thursday 14 March 2013 23:41:33 anon wrote: > Валентин Бартенев Wrote: > ------------------------------------------------------- > > > On Thursday 14 March 2013 17:10:06 anon wrote: > > > Привет. > > > > > > Хочется сделать исключение в таком server. Что бы на /check отвечало > > > > 200, а > > > > > остальных ботов в 444. Как лучше? > > > > > > server { > > > > > > listen *:80 default; > > > > > > server_name _ ""; > > > > Символ подчеркивания тут зачем? > > > > > location = /check{ > > > > > > return 200; > > > > > > } > > > > > > return 444; > > > > > > } > > > > -- > > Валентин Бартенев > > http://nginx.org/en/donation.html > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Спасибо. На счет символа подчеркивания, то вот отсюда у Игоря подсмотрено. > > http://forum.nginx.org/read.php?2,9695,12089#msg-12089 > Там просто процитирована конфигурация персонажа "cdan18po". -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri Mar 15 11:46:38 2013 From: nginx-forum at nginx.us (anon) Date: Fri, 15 Mar 2013 07:46:38 -0400 Subject: =?UTF-8?Q?Re=3A_server_name_=22=22_444_=D0=B8_200?= In-Reply-To: <201303150018.47152.vbart@nginx.com> References: <201303150018.47152.vbart@nginx.com> Message-ID: <6834fe110cf1f25497edadf02c9cc2c1.NginxMailingListRussian@forum.nginx.org> Понял по всем пунктам. Спасибо Валентин Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237355,237398#msg-237398 From onokonem at gmail.com Fri Mar 15 13:59:49 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Fri, 15 Mar 2013 17:59:49 +0400 Subject: keep-alive: lost requests Message-ID: Добрый день! Имеем сервер nginx 1.2.7 (на 1.3.12 тоже воспроизводится). Имеем самописный upload progress. Все как обычно - файл заливается, яваскрипт раз в секунду опрашивает сервер. Если включить keep alive - в какой-то момент запросы начинают пропадать, довольно интересным образом: запрос по существующему соединению уезжает на сервер (отслеживал tcpdump), но на обработку в воркер не попадает (отслеживал по debug логу). Последний запрос к прогрессу уезжает обычно по тому же соединению, что передавался файл, и пропадает с вероятностью 90%. При отключении keep alive запросы пропадать перестают. Что бы это могло быть? Куда глядеть, как отлаживать? Не то, чтобы мне так уперся этот alive, меня раздражает то, что я не понимаю, что происходит. Спасибо. С уважением, Даниил Подольский. From nginx-forum at nginx.us Fri Mar 15 15:58:41 2013 From: nginx-forum at nginx.us (poiuty) Date: Fri, 15 Mar 2013 11:58:41 -0400 Subject: =?UTF-8?B?bGlzdGVuLCDQvdC1INC30LDQv9GD0YHQutCw0LXRgtGB0Y8gbmdpbngsINC90LUg?= =?UTF-8?B?0LLRi9Cy0L7QtNC40YIg0L7RiNC40LHQutGDLg==?= Message-ID: Сегодня перезагрузил nginx. И в итоге ничего не получил (обычно он пишет Restarting nginx: nginx. или Starting nginx: nginx.) В этот раз просто: # /etc/init.d/nginx start http://poiuty.ru/img/7e7b1ff394ea6735398d1a12cd57.png nginx не стартанул. Начал смотреть nginx.conf. Методом тыка нашел виртуальный хост. Если комментирую listen x.x.x.x; То nginx нормально стартует. Пробовал /etc/init.d/nginx conftest - ничего. Пробовал включить error_log /var/log/nginx/lol.log debug; - не стартует и не пишет ничего в log. В других логах аналогично ничего не нашел. В nginx.conf все server{} имеют одинаковую структуру. Дублей этого server{} нет. server { server_name test.ru www.test.ru; #listen x.x.x.x; disable_symlinks if_not_owner from=$root_path; set $root_path /var/www/test/data/www/site.ru; location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ { root $root_path; access_log /var/www/nginx-logs/test isp; access_log /var/www/httpd-logs/site.ru.access.log ; error_page 404 = @fallback; } location / { proxy_pass http://x.x.x.x::81; proxy_redirect http://x.x.x.x::81/ /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; } location ~* ^/(webstat|awstats|webmail|myadmin|pgadmin)/ { proxy_pass http://x.x.x.x::81; proxy_redirect http://x.x.x.x::81/ /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; } location @fallback { proxy_pass http://x.x.x.x:81; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; } include /usr/local/ispmgr/etc/nginx.inc; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237403,237403#msg-237403 From mdounin at mdounin.ru Fri Mar 15 16:39:04 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 15 Mar 2013 20:39:04 +0400 Subject: =?UTF-8?B?UmU6IGxpc3Rlbiwg0L3QtSDQt9Cw0L/Rg9GB0LrQsNC10YLRgdGPIG5naW54LCA=?= =?UTF-8?B?0L3QtSDQstGL0LLQvtC00LjRgiDQvtGI0LjQsdC60YMu?= In-Reply-To: References: Message-ID: <20130315163904.GC15378@mdounin.ru> Hello! On Fri, Mar 15, 2013 at 11:58:41AM -0400, poiuty wrote: > Сегодня перезагрузил nginx. И в итоге ничего не получил (обычно он пишет > Restarting nginx: nginx. или Starting nginx: nginx.) > В этот раз просто: # /etc/init.d/nginx start > http://poiuty.ru/img/7e7b1ff394ea6735398d1a12cd57.png > > nginx не стартанул. > > > Начал смотреть nginx.conf. Методом тыка нашел виртуальный хост. > Если комментирую listen x.x.x.x; То nginx нормально стартует. > > Пробовал /etc/init.d/nginx conftest - ничего. > Пробовал включить error_log /var/log/nginx/lol.log debug; - не стартует и не > пишет ничего в log. > В других логах аналогично ничего не нашел. Причины - должны писаться в логи на глобальном уровне, смотреть в nginx.conf Ну и в терминал по хорошему должно бы писаться, но видимо ваш init-скрипт всю полезную информацию спрятал. Скорее всего - у вас либо описаны listen-сокеты в конфиге, которые конфликтуют между собой (линукс очень трепетно относится к попыткам слушать на одном и том же порту разные адреса), либо просто конфликт по listen-сокетам с другим приложением. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri Mar 15 16:48:02 2013 From: nginx-forum at nginx.us (poiuty) Date: Fri, 15 Mar 2013 12:48:02 -0400 Subject: =?UTF-8?B?UmU6IGxpc3Rlbiwg0L3QtSDQt9Cw0L/Rg9GB0LrQsNC10YLRgdGPIG5naW54LCA=?= =?UTF-8?B?0L3QtSDQstGL0LLQvtC00LjRgiDQvtGI0LjQsdC60YMu?= In-Reply-To: <20130315163904.GC15378@mdounin.ru> References: <20130315163904.GC15378@mdounin.ru> Message-ID: <2de8cd1971a750fdaca2531a50b9317a.NginxMailingListRussian@forum.nginx.org> Сокетов в конфиге нет. ISPmanager прописывает виртуальный хост шаблоном(пример я скинул выше) Я проверял (netstat) другие приложения не используют 80 порт. Проблема в том, что он вообще ничего не пишет. И не запускается. Я смотрю логи в /var/log/nginx/ Если я например займу порт - init.d будет ругаться в консоль. failed (98: Address already in use) OS Debia 6, nginx с репозитория dotdeb.org Как можно отдебажить и получить ошибку? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237403,237405#msg-237405 From mdounin at mdounin.ru Fri Mar 15 17:01:04 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 15 Mar 2013 21:01:04 +0400 Subject: =?UTF-8?B?UmU6IGxpc3Rlbiwg0L3QtSDQt9Cw0L/Rg9GB0LrQsNC10YLRgdGPIG5naW54LCA=?= =?UTF-8?B?0L3QtSDQstGL0LLQvtC00LjRgiDQvtGI0LjQsdC60YMu?= In-Reply-To: <2de8cd1971a750fdaca2531a50b9317a.NginxMailingListRussian@forum.nginx.org> References: <20130315163904.GC15378@mdounin.ru> <2de8cd1971a750fdaca2531a50b9317a.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130315170103.GE15378@mdounin.ru> Hello! On Fri, Mar 15, 2013 at 12:48:02PM -0400, poiuty wrote: > Сокетов в конфиге нет. ISPmanager прописывает виртуальный хост > шаблоном(пример я скинул выше) > Я проверял (netstat) другие приложения не используют 80 порт. > > Проблема в том, что он вообще ничего не пишет. И не запускается. Я смотрю > логи в /var/log/nginx/ Куда пишутся логи - надо смотреть в конфиге (либо смотреть --error-log-path в выводе nginx -V). Попытки найти файлы на ощупь - могут и не привести к желаемому результату. > Если я например займу порт - init.d будет ругаться в консоль. > failed (98: Address already in use) > > OS Debia 6, nginx с репозитория dotdeb.org > > Как можно отдебажить и получить ошибку? Я стесняюсь спросить - а что показывает nginx -V? Наличие сторонних модулей может приводить чуть более чем к любому поведению. Вообще я бы рекомендовал взять официальный пакет с http://nginx.org/ru/download.html. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri Mar 15 17:03:55 2013 From: nginx-forum at nginx.us (poiuty) Date: Fri, 15 Mar 2013 13:03:55 -0400 Subject: =?UTF-8?B?UmU6IGxpc3Rlbiwg0L3QtSDQt9Cw0L/Rg9GB0LrQsNC10YLRgdGPIG5naW54LCA=?= =?UTF-8?B?0L3QtSDQstGL0LLQvtC00LjRgiDQvtGI0LjQsdC60YMu?= In-Reply-To: <20130315170103.GE15378@mdounin.ru> References: <20130315170103.GE15378@mdounin.ru> Message-ID: <211222f37c1f29a0a6ab1f9af2eb40db.NginxMailingListRussian@forum.nginx.org> Окей, сейчас подключу оф репо и поставлю снова. Далее отпишусь. # nginx -V nginx version: nginx/1.2.7 TLS SNI support enabled configure arguments: --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-pcre-jit --with-debug --with-file-aio --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_secure_link_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/usr/src/nginx/source/nginx-1.2.7/debian/modules/nginx-auth-pam --add-module=/usr/src/nginx/source/nginx-1.2.7/debian/modules/nginx-dav-ext-module --add-module=/usr/src/nginx/source/nginx-1.2.7/debian/modules/nginx-echo --add-module=/usr/src/nginx/source/nginx-1.2.7/debian/modules/nginx-upstream-fair --add-module=/usr/src/nginx/source/nginx-1.2.7/debian/modules/nginx-syslog --add-module=/usr/src/nginx/source/nginx-1.2.7/debian/modules/nginx-cache-purge --add-module=/usr/src/nginx/source/nginx-1.2.7/debian/modules/ngx_http_pinba_module --add-module=/usr/src/nginx/source/nginx-1.2.7/debian/modules/ngx_http_substitutions_filter_module Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237403,237408#msg-237408 From nginx-forum at nginx.us Fri Mar 15 17:22:47 2013 From: nginx-forum at nginx.us (poiuty) Date: Fri, 15 Mar 2013 13:22:47 -0400 Subject: =?UTF-8?B?UmU6IGxpc3Rlbiwg0L3QtSDQt9Cw0L/Rg9GB0LrQsNC10YLRgdGPIG5naW54LCA=?= =?UTF-8?B?0L3QtSDQstGL0LLQvtC00LjRgiDQvtGI0LjQsdC60YMu?= In-Reply-To: <211222f37c1f29a0a6ab1f9af2eb40db.NginxMailingListRussian@forum.nginx.org> References: <20130315170103.GE15378@mdounin.ru> <211222f37c1f29a0a6ab1f9af2eb40db.NginxMailingListRussian@forum.nginx.org> Message-ID: <47abfa4ce4c25775f8f5cf79b9ef837d.NginxMailingListRussian@forum.nginx.org> Maxim, спасибо. Поставил с оф репо. Запустил. Получил ошибку. nginx: [emerg] could not build the server_names_hash, you should increase either server_names_hash_max_size: 512 or server_names_hash_bucket_size: 64 Дописал в http{ ... server_names_hash_max_size 512; server_names_hash_bucket_size 128; ... } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237403,237410#msg-237410 From nginx-forum at nginx.us Sun Mar 17 13:03:04 2013 From: nginx-forum at nginx.us (nurdus) Date: Sun, 17 Mar 2013 09:03:04 -0400 Subject: 500 read timeout Message-ID: Доброго времени суток. Не давно установил nginx и начались проблемы, знаю что из-за кривизны рук, а точнее отсутствие опыта. На сайте вызывается скрипт который может выполняться до 5 минут. Скрипт вызывается через cron, если вызывает через адресную строку в браузере всё отрабатывается нормально. в настройках прописаны: keepalive_timeout 600; proxy_read_timeout 600; proxy_send_timeout 600; client_header_timeout 10m; client_body_timeout 10m; send_timeout 10m; Заранее большое спасибо :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237458,237458#msg-237458 From lego12239 at yandex.ru Sun Mar 17 14:21:59 2013 From: lego12239 at yandex.ru (Oleg) Date: Sun, 17 Mar 2013 18:21:59 +0400 Subject: nginx.org links Message-ID: <20130317142159.GA1534@localhost> Всем привет. Вот интересная ссылка для http://nginx.org/en/links.html - http://www.grid.net.ru/nginx/nginx-modules.html . From onokonem at gmail.com Sun Mar 17 15:26:04 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Sun, 17 Mar 2013 19:26:04 +0400 Subject: keep-alive: lost requests In-Reply-To: References: Message-ID: Коллеги, скажите хотя бы - где еще копнуть? Обычно мне хватало debug лога для просветления, но тут... Как это может быть, что соединение есть, и данные приехали, а в дебаг-логе ни следа? 2013/3/15 Daniel Podolsky : > Добрый день! > > Имеем сервер nginx 1.2.7 (на 1.3.12 тоже воспроизводится). > > Имеем самописный upload progress. Все как обычно - файл заливается, > яваскрипт раз в секунду опрашивает сервер. > > Если включить keep alive - в какой-то момент запросы начинают > пропадать, довольно интересным образом: > запрос по существующему соединению уезжает на сервер (отслеживал > tcpdump), но на обработку в воркер не попадает (отслеживал по debug > логу). > > Последний запрос к прогрессу уезжает обычно по тому же соединению, что > передавался файл, и пропадает с вероятностью 90%. > > При отключении keep alive запросы пропадать перестают. > > Что бы это могло быть? Куда глядеть, как отлаживать? Не то, чтобы мне > так уперся этот alive, меня раздражает то, что я не понимаю, что > происходит. > > Спасибо. > > С уважением, > Даниил Подольский. From pavel2000 at ngs.ru Sun Mar 17 17:27:01 2013 From: pavel2000 at ngs.ru (Pavel V.) Date: Mon, 18 Mar 2013 00:27:01 +0700 Subject: 500 read timeout In-Reply-To: References: Message-ID: <01738477.20130318002701@ngs.ru> Здравствуйте, nurdus. > Не давно установил nginx и начались проблемы, знаю что из-за кривизны рук, а > точнее отсутствие опыта. > На сайте вызывается скрипт который может выполняться до 5 минут. Скрипт > вызывается через cron, если вызывает через адресную строку в браузере всё > отрабатывается нормально. 1) Вот и вызывайте его через крон, напрямую через php интерпретатор, а не через веб-сервера. Наши программисты переучились, переучили скрипты, теперь все счастливы. 2) Вы так и не сказали, что за проблемы начались. Проверьте еще раз, сколько выполняется ваш скрипт. -- С уважением, Pavel mailto:pavel2000 at ngs.ru From nginx-forum at nginx.us Sun Mar 17 18:10:29 2013 From: nginx-forum at nginx.us (nurdus) Date: Sun, 17 Mar 2013 14:10:29 -0400 Subject: 500 read timeout In-Reply-To: <01738477.20130318002701@ngs.ru> References: <01738477.20130318002701@ngs.ru> Message-ID: Проблема "500 read timeout" :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237458,237462#msg-237462 From mdounin at mdounin.ru Sun Mar 17 23:12:18 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 18 Mar 2013 03:12:18 +0400 Subject: 500 read timeout In-Reply-To: References: <01738477.20130318002701@ngs.ru> Message-ID: <20130317231218.GU15378@mdounin.ru> Hello! On Sun, Mar 17, 2013 at 02:10:29PM -0400, nurdus wrote: > Проблема "500 read timeout" :) Поскольку nginx такого не пишет никогда, логично предположить, что проблема - не в nginx'е. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Sun Mar 17 23:15:20 2013 From: nginx-forum at nginx.us (nurdus) Date: Sun, 17 Mar 2013 19:15:20 -0400 Subject: 500 read timeout In-Reply-To: <20130317231218.GU15378@mdounin.ru> References: <20130317231218.GU15378@mdounin.ru> Message-ID: <5124d824477a69838046aa40f78a6056.NginxMailingListRussian@forum.nginx.org> Спасибо, будем тогда искать причину. :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237458,237469#msg-237469 From mdounin at mdounin.ru Sun Mar 17 23:16:39 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 18 Mar 2013 03:16:39 +0400 Subject: keep-alive: lost requests In-Reply-To: References: Message-ID: <20130317231639.GV15378@mdounin.ru> Hello! On Sun, Mar 17, 2013 at 07:26:04PM +0400, Daniel Podolsky wrote: > Коллеги, скажите хотя бы - где еще копнуть? > > Обычно мне хватало debug лога для просветления, но тут... Как это > может быть, что соединение есть, и данные приехали, а в дебаг-логе ни > следа? Чтение - заблокировано, и данные висят в буфере сокета и никому до них нет дела. Если используется свой код - поставить nginx в такую позу достаточно легко. > > 2013/3/15 Daniel Podolsky : > > Добрый день! > > > > Имеем сервер nginx 1.2.7 (на 1.3.12 тоже воспроизводится). > > > > Имеем самописный upload progress. Все как обычно - файл заливается, > > яваскрипт раз в секунду опрашивает сервер. > > > > Если включить keep alive - в какой-то момент запросы начинают > > пропадать, довольно интересным образом: > > запрос по существующему соединению уезжает на сервер (отслеживал > > tcpdump), но на обработку в воркер не попадает (отслеживал по debug > > логу). > > > > Последний запрос к прогрессу уезжает обычно по тому же соединению, что > > передавался файл, и пропадает с вероятностью 90%. > > > > При отключении keep alive запросы пропадать перестают. > > > > Что бы это могло быть? Куда глядеть, как отлаживать? Не то, чтобы мне > > так уперся этот alive, меня раздражает то, что я не понимаю, что > > происходит. > > > > Спасибо. > > > > С уважением, > > Даниил Подольский. > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://nginx.org/en/donation.html From lego12239 at yandex.ru Mon Mar 18 09:26:23 2013 From: lego12239 at yandex.ru (Oleg) Date: Mon, 18 Mar 2013 13:26:23 +0400 Subject: ngx_palloc() vs ngx_pnalloc() Message-ID: <20130318092623.GA30538@localhost> Всем привет. Я так понимаю разница между ними в том, что одна функция выравнивает место в памяти, а другая нет, так? Когда какую лучше использовать? From mdounin at mdounin.ru Mon Mar 18 10:22:06 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 18 Mar 2013 14:22:06 +0400 Subject: ngx_palloc() vs ngx_pnalloc() In-Reply-To: <20130318092623.GA30538@localhost> References: <20130318092623.GA30538@localhost> Message-ID: <20130318102206.GX15378@mdounin.ru> Hello! On Mon, Mar 18, 2013 at 01:26:23PM +0400, Oleg wrote: > Всем привет. > > Я так понимаю разница между ними в том, что одна функция выравнивает место > в памяти, а другая нет, так? Когда какую лучше использовать? В общем случае - ngx_palloc(). В случае выделения памяти под строки, где выравнивание не важно - можно использовать ngx_pnalloc(), это позволяет сэкономить немного памяти, особенно если таких выделений много. -- Maxim Dounin http://nginx.org/en/donation.html From lego12239 at yandex.ru Mon Mar 18 10:31:20 2013 From: lego12239 at yandex.ru (Oleg) Date: Mon, 18 Mar 2013 14:31:20 +0400 Subject: ngx_palloc() vs ngx_pnalloc() In-Reply-To: <20130318102206.GX15378@mdounin.ru> References: <20130318092623.GA30538@localhost> <20130318102206.GX15378@mdounin.ru> Message-ID: <20130318103120.GB3579@localhost> On Mon, Mar 18, 2013 at 02:22:06PM +0400, Maxim Dounin wrote: > Hello! > > On Mon, Mar 18, 2013 at 01:26:23PM +0400, Oleg wrote: > > > Всем привет. > > > > Я так понимаю разница между ними в том, что одна функция выравнивает место > > в памяти, а другая нет, так? Когда какую лучше использовать? > > В общем случае - ngx_palloc(). В случае выделения памяти под > строки, где выравнивание не важно - можно использовать > ngx_pnalloc(), это позволяет сэкономить немного памяти, особенно > если таких выделений много. О, да. У меня как раз строки. Понятно. Спасибо. P.S. Камментов бы по-больше в сорцах. From vovansystems at gmail.com Mon Mar 18 10:50:54 2013 From: vovansystems at gmail.com (VovansystemS) Date: Mon, 18 Mar 2013 13:50:54 +0300 Subject: =?UTF-8?B?0YTRgNC10LnQvNGE0L7RgNC6ICsg0L7RgtC00LXQu9GM0L3Ri9C1IHBocC3RhNCw?= =?UTF-8?B?0LnQu9GL?= Message-ID: Добрый день. Подскажите как грамотнее написать конфиг для сайта, который использует фреймворк и несколько отдельно лежащих php сценариев. иерархия примерно такая: /application/ /system/ /modules/ /static/ /upload/ /customphp1/ /customphp2/ .. /customphp30/ index.php где customphp - папка с произвольным названием внутри которой находятся php файлы, которые можно запускать при прямом обращении к ним из браузера. таких папок может быть достаточно много. Пока планирую так: для самого фреймворка стандартно: location / { try_files $uri $uri/ @drupal; } location @drupal { fastcgi_pass ...; fastcgi_param SCRIPT_FILENAME /path/to/index.php; fastcgi_param SCRIPT_NAME /index.php; fastcgi_param QUERY_STRING q=$uri&$args; ... прочие fastcgi_param } Но при обращении к файлам /somedir/not-to-be-viewed.php - nginx будет отдавать их прямо в браузер.. Можно перечислить папки фреймворка и закрыть к ним доступ например так: location ~ ^/(application|system|modules)/ { deny all; } Запуск php из папок со статикой тоже запрещаем: location ~* ^/(?:uploads|static)/.*\.php$ { deny all; } А вот как правильно реализовать возможность запускать отдельно лежащаие php сценарии - перечислять вручную таким образом? location ~* /customphp1/(?:.*)\.php {} Как лучше сделать и что поправить? From lego12239 at yandex.ru Mon Mar 18 13:24:25 2013 From: lego12239 at yandex.ru (Oleg) Date: Mon, 18 Mar 2013 17:24:25 +0400 Subject: =?UTF-8?B?0L/QvtGA0Y/QtNC+0Log0L/RgNC+0YXQvtC20LTQtdC90LjRjyBodHRwLdGE0LA=?= =?UTF-8?B?0Lcg0YHQtdGA0LLQtdGA0LA=?= Message-ID: <20130318132425.GA30673@localhost> Привет всем. Фазы сервера: typedef enum { NGX_HTTP_POST_READ_PHASE = 0, NGX_HTTP_SERVER_REWRITE_PHASE, NGX_HTTP_FIND_CONFIG_PHASE, NGX_HTTP_REWRITE_PHASE, NGX_HTTP_POST_REWRITE_PHASE, NGX_HTTP_PREACCESS_PHASE, NGX_HTTP_ACCESS_PHASE, NGX_HTTP_POST_ACCESS_PHASE, NGX_HTTP_TRY_FILES_PHASE, NGX_HTTP_CONTENT_PHASE, NGX_HTTP_LOG_PHASE } ngx_http_phases; проходят в порядке их перечисления? From mdounin at mdounin.ru Mon Mar 18 13:40:42 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 18 Mar 2013 17:40:42 +0400 Subject: =?UTF-8?B?UmU6INC/0L7RgNGP0LTQvtC6INC/0YDQvtGF0L7QttC00LXQvdC40Y8gaHR0cC0=?= =?UTF-8?B?0YTQsNC3INGB0LXRgNCy0LXRgNCw?= In-Reply-To: <20130318132425.GA30673@localhost> References: <20130318132425.GA30673@localhost> Message-ID: <20130318134042.GB15378@mdounin.ru> Hello! On Mon, Mar 18, 2013 at 05:24:25PM +0400, Oleg wrote: > Привет всем. > > Фазы сервера: > > typedef enum { > NGX_HTTP_POST_READ_PHASE = 0, > > NGX_HTTP_SERVER_REWRITE_PHASE, > > NGX_HTTP_FIND_CONFIG_PHASE, > NGX_HTTP_REWRITE_PHASE, > NGX_HTTP_POST_REWRITE_PHASE, > > NGX_HTTP_PREACCESS_PHASE, > > NGX_HTTP_ACCESS_PHASE, > NGX_HTTP_POST_ACCESS_PHASE, > > NGX_HTTP_TRY_FILES_PHASE, > NGX_HTTP_CONTENT_PHASE, > > NGX_HTTP_LOG_PHASE > } ngx_http_phases; > > проходят в порядке их перечисления? Да. (Называется это обычно "фазы обработки запроса".) -- Maxim Dounin http://nginx.org/en/donation.html From lego12239 at yandex.ru Mon Mar 18 14:34:53 2013 From: lego12239 at yandex.ru (Oleg) Date: Mon, 18 Mar 2013 18:34:53 +0400 Subject: =?UTF-8?B?UmU6INC/0L7RgNGP0LTQvtC6INC/0YDQvtGF0L7QttC00LXQvdC40Y8gaHR0cC0=?= =?UTF-8?B?0YTQsNC3INGB0LXRgNCy0LXRgNCw?= In-Reply-To: <20130318134042.GB15378@mdounin.ru> References: <20130318132425.GA30673@localhost> <20130318134042.GB15378@mdounin.ru> Message-ID: <20130318143453.GA23958@localhost> On Mon, Mar 18, 2013 at 05:40:42PM +0400, Maxim Dounin wrote: > Hello! > > On Mon, Mar 18, 2013 at 05:24:25PM +0400, Oleg wrote: > > > Привет всем. > > > > Фазы сервера: > > > > typedef enum { > > NGX_HTTP_POST_READ_PHASE = 0, > > > > NGX_HTTP_SERVER_REWRITE_PHASE, > > > > NGX_HTTP_FIND_CONFIG_PHASE, > > NGX_HTTP_REWRITE_PHASE, > > NGX_HTTP_POST_REWRITE_PHASE, > > > > NGX_HTTP_PREACCESS_PHASE, > > > > NGX_HTTP_ACCESS_PHASE, > > NGX_HTTP_POST_ACCESS_PHASE, > > > > NGX_HTTP_TRY_FILES_PHASE, > > NGX_HTTP_CONTENT_PHASE, > > > > NGX_HTTP_LOG_PHASE > > } ngx_http_phases; > > > > проходят в порядке их перечисления? > > Да. > > (Называется это обычно "фазы обработки запроса".) Т.е. сделать редирект в конфиге на основе результата аутентификации не получится, я правильно понимаю? Например, надо сделать в случае неудачной аутентификации редирект на страницу с логином/паролем: location = /login { # тут страница для аутентификации и редиректом на /user/$USERNAME в случае # удачи. fastcgi_pass 127.0.0.1:9000; include fastcgi_params; fastcgi_param SERVER_NAME $http_host; } location /user/user1 { # аутентификация по cookie, полученном в локации /login auth_cookie "CGISESSID"; auth_cookie_path "/tmp"; # cookie кончился if ( $auth_cookie_fail ) { return 302 http://$host/login; } proxy_pass http://127.0.0.2:2001/; include proxy_params; } $auth_cookie_fail устанавливается модулем auth_cookie. Я так понимаю, так не получится? From mdounin at mdounin.ru Mon Mar 18 14:53:22 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 18 Mar 2013 18:53:22 +0400 Subject: =?UTF-8?B?UmU6INC/0L7RgNGP0LTQvtC6INC/0YDQvtGF0L7QttC00LXQvdC40Y8gaHR0cC0=?= =?UTF-8?B?0YTQsNC3INGB0LXRgNCy0LXRgNCw?= In-Reply-To: <20130318143453.GA23958@localhost> References: <20130318132425.GA30673@localhost> <20130318134042.GB15378@mdounin.ru> <20130318143453.GA23958@localhost> Message-ID: <20130318145322.GD15378@mdounin.ru> Hello! On Mon, Mar 18, 2013 at 06:34:53PM +0400, Oleg wrote: > On Mon, Mar 18, 2013 at 05:40:42PM +0400, Maxim Dounin wrote: > > Hello! > > > > On Mon, Mar 18, 2013 at 05:24:25PM +0400, Oleg wrote: > > > > > Привет всем. > > > > > > Фазы сервера: > > > > > > typedef enum { > > > NGX_HTTP_POST_READ_PHASE = 0, > > > > > > NGX_HTTP_SERVER_REWRITE_PHASE, > > > > > > NGX_HTTP_FIND_CONFIG_PHASE, > > > NGX_HTTP_REWRITE_PHASE, > > > NGX_HTTP_POST_REWRITE_PHASE, > > > > > > NGX_HTTP_PREACCESS_PHASE, > > > > > > NGX_HTTP_ACCESS_PHASE, > > > NGX_HTTP_POST_ACCESS_PHASE, > > > > > > NGX_HTTP_TRY_FILES_PHASE, > > > NGX_HTTP_CONTENT_PHASE, > > > > > > NGX_HTTP_LOG_PHASE > > > } ngx_http_phases; > > > > > > проходят в порядке их перечисления? > > > > Да. > > > > (Называется это обычно "фазы обработки запроса".) > > Т.е. сделать редирект в конфиге на основе результата аутентификации не > получится, я правильно понимаю? > Например, надо сделать в случае неудачной аутентификации редирект на страницу > с логином/паролем: > > location = /login { > # тут страница для аутентификации и редиректом на /user/$USERNAME в случае > # удачи. > fastcgi_pass 127.0.0.1:9000; > include fastcgi_params; > fastcgi_param SERVER_NAME $http_host; > } > location /user/user1 { > # аутентификация по cookie, полученном в локации /login > auth_cookie "CGISESSID"; > auth_cookie_path "/tmp"; > > # cookie кончился > if ( $auth_cookie_fail ) { > return 302 http://$host/login; > } > > proxy_pass http://127.0.0.2:2001/; > include proxy_params; > } > > $auth_cookie_fail устанавливается модулем auth_cookie. Я так понимаю, так > не получится? Совершенно верно. -- Maxim Dounin http://nginx.org/en/donation.html From lego12239 at yandex.ru Mon Mar 18 15:38:07 2013 From: lego12239 at yandex.ru (Oleg) Date: Mon, 18 Mar 2013 19:38:07 +0400 Subject: =?UTF-8?B?UmU6INC/0L7RgNGP0LTQvtC6INC/0YDQvtGF0L7QttC00LXQvdC40Y8gaHR0cC0=?= =?UTF-8?B?0YTQsNC3INGB0LXRgNCy0LXRgNCw?= In-Reply-To: <20130318145322.GD15378@mdounin.ru> References: <20130318132425.GA30673@localhost> <20130318134042.GB15378@mdounin.ru> <20130318143453.GA23958@localhost> <20130318145322.GD15378@mdounin.ru> Message-ID: <20130318153807.GA16652@localhost> On Mon, Mar 18, 2013 at 06:53:22PM +0400, Maxim Dounin wrote: > Hello! > > > Например, надо сделать в случае неудачной аутентификации редирект на страницу > > с логином/паролем: > > > > location = /login { > > # тут страница для аутентификации и редиректом на /user/$USERNAME в случае > > # удачи. > > fastcgi_pass 127.0.0.1:9000; > > include fastcgi_params; > > fastcgi_param SERVER_NAME $http_host; > > } > > location /user/user1 { > > # аутентификация по cookie, полученном в локации /login > > auth_cookie "CGISESSID"; > > auth_cookie_path "/tmp"; > > > > # cookie кончился > > if ( $auth_cookie_fail ) { > > return 302 http://$host/login; > > } > > > > proxy_pass http://127.0.0.2:2001/; > > include proxy_params; > > } > > > > $auth_cookie_fail устанавливается модулем auth_cookie. Я так понимаю, так > > не получится? > > Совершенно верно. А http-redirect может только модуль фазы NGX_HTTP_CONTENT_PHASE слать или с фазы NGX_HTTP_ACCESS_PHASE тоже можно слать перенаправления? И ещё вопрос. Здесь - http://www.evanmiller.org/nginx-modules-guide.html - написано, что хэндлер контента может быть только один и вешается так: clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module); clcf->handler = ngx_http_circle_gif_handler; Про хэндлеры фаз обработки запроса там, кстати, я ничего не нашёл. Вопрос в чём. Можно ли повесить несколько handler'ов содержимого через фазу обработки запроса NGX_HTTP_CONTENT_PHASE? И можно ли это сделать так, что бы он вызывался гарантировано до proxy_pass? Тогда, я могу там делать http-redirect на основе переменных, допустим. From mdounin at mdounin.ru Mon Mar 18 16:00:55 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 18 Mar 2013 20:00:55 +0400 Subject: =?UTF-8?B?UmU6INC/0L7RgNGP0LTQvtC6INC/0YDQvtGF0L7QttC00LXQvdC40Y8gaHR0cC0=?= =?UTF-8?B?0YTQsNC3INGB0LXRgNCy0LXRgNCw?= In-Reply-To: <20130318153807.GA16652@localhost> References: <20130318132425.GA30673@localhost> <20130318134042.GB15378@mdounin.ru> <20130318143453.GA23958@localhost> <20130318145322.GD15378@mdounin.ru> <20130318153807.GA16652@localhost> Message-ID: <20130318160054.GF15378@mdounin.ru> Hello! On Mon, Mar 18, 2013 at 07:38:07PM +0400, Oleg wrote: > On Mon, Mar 18, 2013 at 06:53:22PM +0400, Maxim Dounin wrote: > > Hello! > > > > > Например, надо сделать в случае неудачной аутентификации редирект на страницу > > > с логином/паролем: > > > > > > location = /login { > > > # тут страница для аутентификации и редиректом на /user/$USERNAME в случае > > > # удачи. > > > fastcgi_pass 127.0.0.1:9000; > > > include fastcgi_params; > > > fastcgi_param SERVER_NAME $http_host; > > > } > > > location /user/user1 { > > > # аутентификация по cookie, полученном в локации /login > > > auth_cookie "CGISESSID"; > > > auth_cookie_path "/tmp"; > > > > > > # cookie кончился > > > if ( $auth_cookie_fail ) { > > > return 302 http://$host/login; > > > } > > > > > > proxy_pass http://127.0.0.2:2001/; > > > include proxy_params; > > > } > > > > > > $auth_cookie_fail устанавливается модулем auth_cookie. Я так понимаю, так > > > не получится? > > > > Совершенно верно. > > А http-redirect может только модуль фазы NGX_HTTP_CONTENT_PHASE слать или с > фазы NGX_HTTP_ACCESS_PHASE тоже можно слать перенаправления? Можно из любой фазы (но может требовать дополнительных приседаний). > И ещё вопрос. Здесь - http://www.evanmiller.org/nginx-modules-guide.html - > написано, что хэндлер контента может быть только один и вешается так: > > clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module); > clcf->handler = ngx_http_circle_gif_handler; Так вешаются content-обработчики, вызываемые для данного location'а. Такие обработчики делать - проще всего, и в большинстве случаев именно они и нужны. Опять же, такие обработчики - никак не влияют на обработку запросов в других location'ах. Именно так работает proxy_pass (+ memcached, fastcgi, uwsgi, scgi), empty_gif, stub_status, perl и т.п. Но это не всё, что бывает в content-фазе. Если clcf->handler не стоит, или отказался от обработки запроса, то последовательно вызываются модули content-фазы, такие как random_index, index, autoindex, static. > Про хэндлеры фаз обработки запроса там, кстати, я ничего не нашёл. > Вопрос в чём. Можно ли повесить несколько handler'ов содержимого через > фазу обработки запроса NGX_HTTP_CONTENT_PHASE? И можно ли это сделать так, > что бы он вызывался гарантировано до proxy_pass? > Тогда, я могу там делать http-redirect на основе переменных, допустим. Нет, так работать не будет. Если стоит clcf->handler - то на обротчики content-фазы смотреть никто не будет. Если вам нужно своим модулем проверить результат работы модуля access-фазы, то это надо делать в access-фазе же (и при этом убедившись, что satisfy стоит в all). Загляните в ngx_http_core_module.c, там всё более или менее понятно. -- Maxim Dounin http://nginx.org/en/donation.html From lego12239 at yandex.ru Mon Mar 18 16:40:15 2013 From: lego12239 at yandex.ru (Oleg) Date: Mon, 18 Mar 2013 20:40:15 +0400 Subject: =?UTF-8?B?UmU6INC/0L7RgNGP0LTQvtC6INC/0YDQvtGF0L7QttC00LXQvdC40Y8gaHR0cC0=?= =?UTF-8?B?0YTQsNC3INGB0LXRgNCy0LXRgNCw?= In-Reply-To: <20130318160054.GF15378@mdounin.ru> References: <20130318132425.GA30673@localhost> <20130318134042.GB15378@mdounin.ru> <20130318143453.GA23958@localhost> <20130318145322.GD15378@mdounin.ru> <20130318153807.GA16652@localhost> <20130318160054.GF15378@mdounin.ru> Message-ID: <20130318164015.GA25453@localhost> On Mon, Mar 18, 2013 at 08:00:55PM +0400, Maxim Dounin wrote: > Hello! > > > А http-redirect может только модуль фазы NGX_HTTP_CONTENT_PHASE слать или с > > фазы NGX_HTTP_ACCESS_PHASE тоже можно слать перенаправления? > > Можно из любой фазы (но может требовать дополнительных > приседаний). Хм, думал есть какой-либо "правильный" способ, так сказать. > > И ещё вопрос. Здесь - http://www.evanmiller.org/nginx-modules-guide.html - > > написано, что хэндлер контента может быть только один и вешается так: > > > > clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module); > > clcf->handler = ngx_http_circle_gif_handler; > > Так вешаются content-обработчики, вызываемые для данного > location'а. Такие обработчики делать - проще всего, и в > большинстве случаев именно они и нужны. Опять же, такие > обработчики - никак не влияют на обработку запросов в других > location'ах. Именно так работает proxy_pass (+ memcached, > fastcgi, uwsgi, scgi), empty_gif, stub_status, perl и т.п. > > Но это не всё, что бывает в content-фазе. Если clcf->handler не > стоит, или отказался от обработки запроса, то последовательно > вызываются модули content-фазы, такие как random_index, index, > autoindex, static. > > > Про хэндлеры фаз обработки запроса там, кстати, я ничего не нашёл. > > Вопрос в чём. Можно ли повесить несколько handler'ов содержимого через > > фазу обработки запроса NGX_HTTP_CONTENT_PHASE? И можно ли это сделать так, > > что бы он вызывался гарантировано до proxy_pass? > > Тогда, я могу там делать http-redirect на основе переменных, допустим. > > Нет, так работать не будет. Если стоит clcf->handler - то на > обротчики content-фазы смотреть никто не будет. Если вам нужно > своим модулем проверить результат работы модуля access-фазы, то > это надо делать в access-фазе же (и при этом убедившись, что > satisfy стоит в all). Большое спасибо за разъяснения. Думаю городить ещё модуль нет смысла в моём случае. Надо всё в одном модуле делать. > Загляните в ngx_http_core_module.c, там всё более или менее > понятно. Спасибо за указание направления. Попытаюсь там что-нибудь накопать. From onokonem at gmail.com Mon Mar 18 18:34:59 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Mon, 18 Mar 2013 22:34:59 +0400 Subject: keep-alive: lost requests In-Reply-To: <20130317231639.GV15378@mdounin.ru> References: <20130317231639.GV15378@mdounin.ru> Message-ID: > Чтение - заблокировано, и данные висят в буфере сокета и никому до > них нет дела. Если используется свой код - поставить nginx в > такую позу достаточно легко. А как это ловить и отлаживать? И почему отключение keep alive меняет ситуацию? Вроде бы - заблокированный на чтении сокет закрывать должно быть некому. Код там свой только перловый, и блокирующих операций в нем нет. Хочу понять, на каком месте случается блокировка. From mdounin at mdounin.ru Mon Mar 18 18:49:47 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 18 Mar 2013 22:49:47 +0400 Subject: keep-alive: lost requests In-Reply-To: References: <20130317231639.GV15378@mdounin.ru> Message-ID: <20130318184946.GG15378@mdounin.ru> Hello! On Mon, Mar 18, 2013 at 10:34:59PM +0400, Daniel Podolsky wrote: > > Чтение - заблокировано, и данные висят в буфере сокета и никому до > > них нет дела. Если используется свой код - поставить nginx в > > такую позу достаточно легко. > А как это ловить и отлаживать? Смотреть внимательно на флаги c->read в разных точках, в частности - при уходе в keepalive. > И почему отключение keep alive меняет ситуацию? Вроде бы - > заблокированный на чтении сокет закрывать должно быть некому. Почему? Его просто закроют, когда будет отправлен ответ. > Код там свой только перловый, и блокирующих операций в нем нет. Хочу > понять, на каком месте случается блокировка. Под "чтение заблокировано" выше следует понимать то, что nginx не пытается читать из сокета. Обычно для этого применяется специальный обработчик ngx_http_block_reading(), но получить тот же эффект методом неаккуратного обращения с кодом внутри nginx'а, особенно при использовании edge triggered методов обработки соединений, сложности не представляет. (Самописный upload progress на перле? Вообще-то он такого не умеет...) -- Maxim Dounin http://nginx.org/en/donation.html From lego12239 at yandex.ru Mon Mar 18 18:49:59 2013 From: lego12239 at yandex.ru (Oleg) Date: Mon, 18 Mar 2013 22:49:59 +0400 Subject: =?UTF-8?B?UmU6INC/0L7RgNGP0LTQvtC6INC/0YDQvtGF0L7QttC00LXQvdC40Y8gaHR0cC0=?= =?UTF-8?B?0YTQsNC3INGB0LXRgNCy0LXRgNCw?= In-Reply-To: <20130318160054.GF15378@mdounin.ru> References: <20130318132425.GA30673@localhost> <20130318134042.GB15378@mdounin.ru> <20130318143453.GA23958@localhost> <20130318145322.GD15378@mdounin.ru> <20130318153807.GA16652@localhost> <20130318160054.GF15378@mdounin.ru> Message-ID: <20130318184959.GA15239@localhost> On Mon, Mar 18, 2013 at 08:00:55PM +0400, Maxim Dounin wrote: > Hello! > > > А http-redirect может только модуль фазы NGX_HTTP_CONTENT_PHASE слать или с > > фазы NGX_HTTP_ACCESS_PHASE тоже можно слать перенаправления? > > Можно из любой фазы (но может требовать дополнительных > приседаний). Так. Попробовал по-быстрому сделать перенаправление. Никаких приседаний не заметил, по крайней мере для фазы NGX_HTTP_ACCESS_PHASE. Может, чего-то не учёл, конечно, но сделал в лоб: h = r->headers_out.location; if ( h == NULL ) { h = ngx_list_push(&r->headers_out.headers); if ( h == NULL ) return NGX_ERROR; h->key.data = "Location"; h->key.len = sizeof("Location") - 1; r->headers_out.location = h; } h->value.data = "http://ya.ru"; h->value.len = sizeof("http://ya.ru") - 1; h->hash = 1; r->headers_out.status = NGX_HTTP_TEMPORARY_REDIRECT; ngx_http_send_header(r); return NGX_OK; Работает нормально. From onokonem at gmail.com Mon Mar 18 19:01:14 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Mon, 18 Mar 2013 23:01:14 +0400 Subject: keep-alive: lost requests In-Reply-To: <20130318184946.GG15378@mdounin.ru> References: <20130317231639.GV15378@mdounin.ru> <20130318184946.GG15378@mdounin.ru> Message-ID: > (Самописный upload progress на перле? Вообще-то он такого не > умеет...) А что тут уметь? хендлер от временного файла есть, заголовок content-length есть, размер stat отдает. From nginx-forum at nginx.us Tue Mar 19 00:16:22 2013 From: nginx-forum at nginx.us (Sarymian) Date: Mon, 18 Mar 2013 20:16:22 -0400 Subject: nginx init script error debian 6 Message-ID: <75cff233204a5002cf497690a0e6dd6b.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Собрал nginx из исходников в Debian 6. Работает все ок, создал файл /etc/init.d/nginx (755 chmod) При выполнение любой команды выдает ошибку: /etc/init.d/nginx: 1: #!/bin/sh: not found В notepad++ преобразовал в utf-8 (хотя и так был utf-8), и переносы строк преобразовал в unix формат. Подскажите пожалуйста в чем проблема? Содержимое /etc/init.d/nginx : #!/bin/sh ### BEGIN INIT INFO # Provides: nginx # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: nginx init.d dash script for Ubuntu <=9.10. # Description: nginx init.d dash script for Ubuntu <=9.10. ### END INIT INFO #------------------------------------------------------------------------------ # nginx - this Debian Almquist shell (dash) script, starts and stops the nginx # daemon for ubuntu 9.10 and lesser version numbered releases. # # description: Nginx is an HTTP(S) server, HTTP(S) reverse \ # proxy and IMAP/POP3 proxy server. This \ # script will manage the initiation of the \ # server and it's process state. # # processname: nginx # config: /usr/local/nginx/conf/nginx.conf # pidfile: /acronymlabs/server/nginx.pid # Provides: nginx # # Author: Jason Giedymin # . # # Version: 2.0 02-NOV-2009 jason.giedymin AT gmail.com # Notes: nginx init.d dash script for Ubuntu <=9.10. # # This script's project home is: # http://code.google.com/p/nginx-init-ubuntu/ # #------------------------------------------------------------------------------ # MIT X11 License #------------------------------------------------------------------------------ # # Copyright (c) 2009 Jason Giedymin, http://Amuxbit.com formerly # http://AcronymLabs.com # # Permission is hereby granted, free of charge, to any person obtaining # a copy of this software and associated documentation files (the # "Software"), to deal in the Software without restriction, including # without limitation the rights to use, copy, modify, merge, publish, # distribute, sublicense, and/or sell copies of the Software, and to # permit persons to whom the Software is furnished to do so, subject to # the following conditions: # # The above copyright notice and this permission notice shall be # included in all copies or substantial portions of the Software. # # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, # EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF # MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND # NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE # LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION # OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION # WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. #------------------------------------------------------------------------------ #------------------------------------------------------------------------------ # Functions #------------------------------------------------------------------------------ . /lib/lsb/init-functions #------------------------------------------------------------------------------ # Consts #------------------------------------------------------------------------------ PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin DAEMON=/usr/local/sbin/nginx PS="nginx" PIDNAME="nginx" #lets you do $PS-slave PIDFILE=$PIDNAME.pid #pid file PIDSPATH=/var/run DESCRIPTION="Nginx Server..." RUNAS=root #user to run as SCRIPT_OK=0 #ala error codes SCRIPT_ERROR=1 #ala error codes TRUE=1 #boolean FALSE=0 #boolean lockfile=/var/lock/subsys/nginx NGINX_CONF_FILE="/usr/local/nginx/conf/nginx.conf" #------------------------------------------------------------------------------ # Simple Tests #------------------------------------------------------------------------------ #test if nginx is a file and executable test -x $DAEMON || exit 0 # Include nginx defaults if available if [ -f /etc/default/nginx ] ; then . /etc/default/nginx fi #set exit condition #set -e #------------------------------------------------------------------------------ # Functions #------------------------------------------------------------------------------ setFilePerms(){ if [ -f $PIDSPATH/$PIDFILE ]; then chmod 400 $PIDSPATH/$PIDFILE fi } configtest() { $DAEMON -t -c $NGINX_CONF_FILE } getPSCount() { return `pgrep -f $PS | wc -l` } isRunning() { if [ $1 ]; then pidof_daemon $1 PID=$? if [ $PID -gt 0 ]; then return 1 else return 0 fi else pidof_daemon PID=$? if [ $PID -gt 0 ]; then return 1 else return 0 fi fi } #courtesy of php-fpm wait_for_pid () { try=0 while test $try -lt 35 ; do case "$1" in 'created') if [ -f "$2" ] ; then try='' break fi ;; 'removed') if [ ! -f "$2" ] ; then try='' break fi ;; esac #echo -n . try=`expr $try + 1` sleep 1 done } status(){ isRunning isAlive=$? if [ "${isAlive}" -eq $TRUE ]; then echo "$PIDNAME found running with processes: `pidof $PS`" else echo "$PIDNAME is NOT running." fi } removePIDFile(){ if [ $1 ]; then if [ -f $1 ]; then rm -f $1 fi else #Do default removal if [ -f $PIDSPATH/$PIDFILE ]; then rm -f $PIDSPATH/$PIDFILE fi fi } start() { log_daemon_msg "Starting $DESCRIPTION" isRunning isAlive=$? if [ "${isAlive}" -eq $TRUE ]; then log_end_msg $SCRIPT_ERROR else start-stop-daemon --start --quiet --chuid $RUNAS --pidfile $PIDSPATH/$PIDFILE --exec $DAEMON \ -- -c $NGINX_CONF_FILE setFilePerms log_end_msg $SCRIPT_OK fi } stop() { log_daemon_msg "Stopping $DESCRIPTION" isRunning isAlive=$? if [ "${isAlive}" -eq $TRUE ]; then start-stop-daemon --stop --quiet --pidfile $PIDSPATH/$PIDFILE wait_for_pid 'removed' $PIDSPATH/$PIDFILE if [ -n "$try" ] ; then log_end_msg $SCRIPT_ERROR else removePIDFile log_end_msg $SCRIPT_OK fi else log_end_msg $SCRIPT_ERROR fi } reload() { configtest || return $? log_daemon_msg "Reloading (via HUP) $DESCRIPTION" isRunning if [ $? -eq $TRUE ]; then `killall -HUP $PS` #to be safe log_end_msg $SCRIPT_OK else log_end_msg $SCRIPT_ERROR fi } quietupgrade() { log_daemon_msg "Peforming Quiet Upgrade $DESCRIPTION" isRunning isAlive=$? if [ "${isAlive}" -eq $TRUE ]; then kill -USR2 `cat $PIDSPATH/$PIDFILE` kill -WINCH `cat $PIDSPATH/$PIDFILE.oldbin` isRunning isAlive=$? if [ "${isAlive}" -eq $TRUE ]; then kill -QUIT `cat $PIDSPATH/$PIDFILE.oldbin` wait_for_pid 'removed' $PIDSPATH/$PIDFILE.oldbin removePIDFile $PIDSPATH/$PIDFILE.oldbin log_end_msg $SCRIPT_OK else log_end_msg $SCRIPT_ERROR log_daemon_msg "ERROR! Reverting back to original $DESCRIPTION" kill -HUP `cat $PIDSPATH/$PIDFILE` kill -TERM `cat $PIDSPATH/$PIDFILE.oldbin` kill -QUIT `cat $PIDSPATH/$PIDFILE.oldbin` wait_for_pid 'removed' $PIDSPATH/$PIDFILE.oldbin removePIDFile $PIDSPATH/$PIDFILE.oldbin log_end_msg $SCRIPT_ok fi else log_end_msg $SCRIPT_ERROR fi } terminate() { log_daemon_msg "Force terminating (via KILL) $DESCRIPTION" PIDS=`pidof $PS` || true [ -e $PIDSPATH/$PIDFILE ] && PIDS2=`cat $PIDSPATH/$PIDFILE` for i in $PIDS; do if [ "$i" = "$PIDS2" ]; then kill $i wait_for_pid 'removed' $PIDSPATH/$PIDFILE removePIDFile fi done log_end_msg $SCRIPT_OK } destroy() { log_daemon_msg "Force terminating and may include self (via KILLALL) $DESCRIPTION" killall $PS -q >> /dev/null 2>&1 log_end_msg $SCRIPT_OK } pidof_daemon() { PIDS=`pidof $PS` || true [ -e $PIDSPATH/$PIDFILE ] && PIDS2=`cat $PIDSPATH/$PIDFILE` for i in $PIDS; do if [ "$i" = "$PIDS2" ]; then return 1 fi done return 0 } case "$1" in start) start ;; stop) stop ;; restart|force-reload) stop sleep 1 start ;; reload) $1 ;; status) status ;; configtest) $1 ;; quietupgrade) $1 ;; terminate) $1 ;; destroy) $1 ;; *) FULLPATH=/etc/init.d/$PS echo "Usage: $FULLPATH {start|stop|restart|force-reload|status|configtest|quietupgrade|terminate|destroy}" echo " The 'destroy' command should only be used as a last resort." exit 1 ;; esac exit 0 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237519,237519#msg-237519 From nginx-forum at nginx.us Tue Mar 19 03:58:03 2013 From: nginx-forum at nginx.us (Sarymian) Date: Mon, 18 Mar 2013 23:58:03 -0400 Subject: nginx init script error debian 6 In-Reply-To: <75cff233204a5002cf497690a0e6dd6b.NginxMailingListRussian@forum.nginx.org> References: <75cff233204a5002cf497690a0e6dd6b.NginxMailingListRussian@forum.nginx.org> Message-ID: <6e7695310b0cb7fc455014b8c87fda94.NginxMailingListRussian@forum.nginx.org> Вопрос снят. Поменял кодировку символов на ANSI все заработало (перенос строк надо оставить в UNIX формате). Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237519,237521#msg-237521 From nick_ik at mail.ru Tue Mar 19 05:07:43 2013 From: nick_ik at mail.ru (=?UTF-8?B?TmljaG9sYXMgS29zdGlyeWE=?=) Date: Tue, 19 Mar 2013 09:07:43 +0400 Subject: =?UTF-8?B?WC1BY2NlbC1SZWRpcmVjdCDQvdCwIDQwNCDQv9C+0YHQu9C1IGZhbGxiYWNr?= Message-ID: <1363669663.443659970@f384.i.mail.ru> Привет. Есть такая конфигурация.     location / {         proxy_pass http://0:5000;     }     location = /404 {         root /tmp/nginx;         error_page 404 /404.html;         return 404;     }     location ~* \.(html)$ {         root /tmp/nginx;         error_page 404 /404.html;     } Бекенд возвращает ответ с "X-Accel-Redirect: /404". /404 каталога нет и срабатывает error_page 404 и возвращается /404.html страница с 404 HTTP статусом. Теперь добавим впереди memcached:     location / {         set $memcached_key "test:$uri";         memcached_pass unix:/tmp/memcached.sock;         default_type text/html;         error_page 404 = @fallback;     }     location @fallback {         proxy_pass http://0:5000;     }     location = /404 {         root /tmp/nginx;         error_page 404 /404.html;         return 404;     }     location ~* \.(html)$ {         root /tmp/nginx;         error_page 404 /404.html;     } И в такой конфигурации, когда бекенд возвращает ответ с "X-Accel-Redirect: /404", то nginx отдает не /404.html страницу, а свою внутреннюю. Если же делать сразу "X-Accel-Redirect: /404.html", то не будет 404 статуса. Какое есть решение для этой ситуации? Кстати, вызов memcached можно даже убрать, достаточно оставить цепочку из двух error_page. Такое ощущение, что если в процессе обработки запроса использовался именованный локайшен, то уже не обычные возврата нет. ---------------------------------------------------------------------- ---------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue Mar 19 06:23:14 2013 From: nginx-forum at nginx.us (sitsalavat) Date: Tue, 19 Mar 2013 02:23:14 -0400 Subject: =?UTF-8?B?bmdpbngg0Lgg0YHQuNC90YLQtdGC0LjRh9C10YHQutC40Lkg0YLQtdGB0YIgKGFi?= =?UTF-8?B?LCBzaWVnZSwgeWFuZGV4LXRhbmsp?= Message-ID: <48427c84dfe8dda1f86a132af4a119b2.NginxMailingListRussian@forum.nginx.org> Всем привет. Есть сервер на котором в качестве фронтенда крутится nginx. Выдержки из конфига: ======================= worker_processes 8; events { worker_connections 4096; } proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=all:512m inactive=1d max_size=6g; proxy_cache_key "$host$request_uri"; proxy_cache_valid 404 40m; proxy_cache_valid 500 501 502 503 504 1m; proxy_cache_valid any 5m; proxy_cache_use_stale http_502 http_503 http_504; proxy_cache_bypass $cookie_logined; proxy_no_cache $cookie_logined; proxy_connect_timeout 40; proxy_send_timeout 40; proxy_read_timeout 100; proxy_buffer_size 4m; proxy_buffers 24 1m; proxy_busy_buffers_size 8m; proxy_temp_file_write_size 4m; location / { if ($cookie_logined) { return 412; } proxy_cache all; proxy_pass @fallback; proxy_redirect @fallback; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; } ======================= Насколько я понимаю, если cookie logined нет - то пользователю должна отдавать закешированная версия, которая лежит в nginx и при синтетических тестах - они так же свободно отдавались бы. Фактически же при ab -kc 500 -n 500 -t 30 nginx начинает все сплавлять на бекенд и соответственно LA начинает зашкаливать. Люди добрые, помогите мне :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237524,237524#msg-237524 From 0 at 375.ru Tue Mar 19 08:17:13 2013 From: 0 at 375.ru (pv dev dep) Date: Tue, 19 Mar 2013 14:17:13 +0600 Subject: =?UTF-8?B?0J/RgNC4INC+0LHQvdC+0LLQu9C10L3QuNC4INC60LXRiNCwINC/0YDQvtGA0Ys=?= =?UTF-8?B?0LLQsNGO0YLRgdGPINC30LDQv9GA0L7RgdGLINC6INCx0Y3QutC10L3QtNGD?= Message-ID: <51481F09.6030903@375.ru> Здравствуйте. nginx.conf, что касается кеша: proxy_cache_path /var/www/nginx_cache levels=1:2 keys_zone=cache:64m max_size=10000m inactive=600m; proxy_temp_path /tmp/nginx; Конфиг виртуального сервера: location = / { proxy_cache cache; proxy_cache_key "$uri"; proxy_cache_valid 200 302 1m; proxy_cache_valid 404 1m; proxy_cache_lock on; proxy_cache_lock_timeout 1m; proxy_cache_min_uses 1; proxy_ignore_headers "Cache-Control" "Expires" "Set-Cookie" "X-Accel-Expires"; include proxy_params; proxy_pass http://127.0.0.1:8090; } Ngnx 1.1.19. Судя по конфигу обращение к бэкенду должно происходить раз в минуту. Так и происходит, но иногда, довольно часто, проходят два и более обращений. Бывает, что на бэкенд проходит такое количество запросов, что из-за медленного его ответа, ngnx направляет уже все запросы к бэкенду. Использование proxy_cache_lock видимого эффекта не дало. Подскажите, пожалуйста, направление для размышлений. Лог бэкенда: * 1 min refresh 79.172.13.58 - - [18/Mar/2013:16:57:11] "GET / HTTP/1.0" * 1 min refresh 188.18.249.66 - - [18/Mar/2013:16:58:12] "GET / HTTP/1.0" 88.205.160.141 - - [18/Mar/2013:16:58:12] "GET / HTTP/1.0" * 1 min refresh 88.205.179.120 - - [18/Mar/2013:16:59:13] "GET / HTTP/1.0" 94.50.85.82 - - [18/Mar/2013:16:59:13] "GET / HTTP/1.0" 31.162.121.239 - - [18/Mar/2013:16:59:13] "GET / HTTP/1.0" 94.50.92.119 - - [18/Mar/2013:16:59:14] "GET / HTTP/1.0" 92.248.251.218 - - [18/Mar/2013:16:59:14] "GET / HTTP/1.0" 89.204.82.71 - - [18/Mar/2013:16:59:14] "GET / HTTP/1.0" 90.151.236.92 - - [18/Mar/2013:16:59:14] "GET / HTTP/1.0" 188.19.72.34 - - [18/Mar/2013:16:59:14] "GET / HTTP/1.0" 188.16.17.40 - - [18/Mar/2013:16:59:14] "GET / HTTP/1.0" и так далее до average 120+ Лог ngnx: 178.46.27.201 - [18/Mar/2013:16:59:12] "GET / HTTP/1.1" [0.600] 217.118.83.245 - [18/Mar/2013:16:59:12] "GET / HTTP/1.1" [0.100] 188.16.187.170 - [18/Mar/2013:16:59:12] "GET / HTTP/1.1" [0.200] 37.79.114.174 - [18/Mar/2013:16:59:12] "GET / HTTP/1.1" [1.000] 94.50.23.226 - [18/Mar/2013:16:59:12] "GET / HTTP/1.1" [0.200] 178.47.169.96 - [18/Mar/2013:16:59:13] "GET / HTTP/1.1" [0.200] 94.50.85.82 - [18/Mar/2013:16:59:14] "GET / HTTP/1.1" [1.300] 92.248.251.218 - [18/Mar/2013:16:59:14] "GET / HTTP/1.1" [0.500] 88.205.179.120 - [18/Mar/2013:16:59:14] "GET / HTTP/1.1" [1.000] 90.151.148.162 - [18/Mar/2013:16:59:14] "GET / HTTP/1.1" [0.100] 31.162.121.239 - [18/Mar/2013:16:59:14] "GET / HTTP/1.1" [1.200] 94.50.92.119 - [18/Mar/2013:16:59:14] "GET / HTTP/1.1" [1.100] 92.50.194.134 - [18/Mar/2013:16:59:14] "GET / HTTP/1.0" [1.900] 94.51.32.201 - [18/Mar/2013:16:59:14] "GET / HTTP/1.1" [0.200] 88.205.171.216 - [18/Mar/2013:16:59:14] "GET / HTTP/1.1" [0.200] 89.204.82.71 - [18/Mar/2013:16:59:15] "GET / HTTP/1.1" [1.500] 178.46.166.140 - [18/Mar/2013:16:59:15] "GET / HTTP/1.1" [0.200] 90.151.28.187 - [18/Mar/2013:16:59:15] "GET / HTTP/1.1" [0.200] 188.17.99.19 - [18/Mar/2013:16:59:16] "GET / HTTP/1.1" [0.300] 89.204.57.17 - [18/Mar/2013:16:59:16] "GET / HTTP/1.1" [0.200] 5.140.11.144 - [18/Mar/2013:16:59:16] "GET / HTTP/1.1" [0.200] 178.46.45.84 - [18/Mar/2013:16:59:16] "GET / HTTP/1.1" [0.300] 90.151.236.92 - [18/Mar/2013:16:59:18] "GET / HTTP/1.1" [4.300] 94.51.234.35 - [18/Mar/2013:16:59:18] "GET / HTTP/1.1" [0.100] -- Сергей Панин From onokonem at gmail.com Tue Mar 19 08:25:13 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Tue, 19 Mar 2013 12:25:13 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQuCDQvtCx0L3QvtCy0LvQtdC90LjQuCDQutC10YjQsCDQv9GA0L4=?= =?UTF-8?B?0YDRi9Cy0LDRjtGC0YHRjyDQt9Cw0L/RgNC+0YHRiyDQuiDQsdGN0LrQtdC9?= =?UTF-8?B?0LTRgw==?= In-Reply-To: <51481F09.6030903@375.ru> References: <51481F09.6030903@375.ru> Message-ID: > Ngnx 1.1.19. Судя по конфигу обращение к бэкенду должно происходить раз в > минуту. Так и происходит, но иногда, довольно часто, проходят два и более > обращений. Бывает, что на бэкенд проходит такое количество запросов, что > из-за медленного его ответа, ngnx направляет уже все запросы к бэкенду. > Использование proxy_cache_lock видимого эффекта не дало. Подскажите, > пожалуйста, направление для размышлений. А что - в nginx появились busy locks? если нет - такое поведение вполне предсказуемо. From kulmaks at gmail.com Tue Mar 19 08:30:26 2013 From: kulmaks at gmail.com (Maksim Kulik) Date: Tue, 19 Mar 2013 11:30:26 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQuCDQvtCx0L3QvtCy0LvQtdC90LjQuCDQutC10YjQsCDQv9GA0L4=?= =?UTF-8?B?0YDRi9Cy0LDRjtGC0YHRjyDQt9Cw0L/RgNC+0YHRiyDQuiDQsdGN0LrQtdC9?= =?UTF-8?B?0LTRgw==?= In-Reply-To: <51481F09.6030903@375.ru> References: <51481F09.6030903@375.ru> Message-ID: Здравствуйте! Попробуйте добавить в конфиг proxy_cache_use_stale updating; Из документации: "Кроме того, дополнительный параметр updating разрешает использовать устаревший закэшированный ответ, если на данный момент он уже обновляется. Это позволяет минимизировать число обращений к проксированным серверам при обновлении закэшированных данных." 19 марта 2013 г., 11:17 пользователь pv dev dep <0 at 375.ru> написал: > Здравствуйте. > > Ngnx 1.1.19. Судя по конфигу обращение к бэкенду должно происходить раз в > минуту. Так и происходит, но иногда, довольно часто, проходят два и более > обращений. Бывает, что на бэкенд проходит такое количество запросов, что > из-за медленного его ответа, ngnx направляет уже все запросы к бэкенду. > Использование proxy_cache_lock видимого эффекта не дало. Подскажите, > пожалуйста, направление для размышлений. > -- > Сергей Панин > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From 0 at 375.ru Tue Mar 19 09:22:31 2013 From: 0 at 375.ru (pv dev dep) Date: Tue, 19 Mar 2013 15:22:31 +0600 Subject: =?UTF-8?B?UmU6INCf0YDQuCDQvtCx0L3QvtCy0LvQtdC90LjQuCDQutC10YjQsCDQv9GA0L4=?= =?UTF-8?B?0YDRi9Cy0LDRjtGC0YHRjyDQt9Cw0L/RgNC+0YHRiyDQuiDQsdGN0LrQtdC9?= =?UTF-8?B?0LTRgw==?= In-Reply-To: References: <51481F09.6030903@375.ru> Message-ID: <51482E57.5010302@375.ru> 19.03.2013 14:30, Maksim Kulik пишет: > Попробуйте добавить в конфиг > proxy_cache_use_stale updating; > Спасибо, это именно то, что мы упустили. -- Сергей Панин From mdounin at mdounin.ru Tue Mar 19 10:55:21 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 19 Mar 2013 14:55:21 +0400 Subject: =?UTF-8?B?UmU6INC/0L7RgNGP0LTQvtC6INC/0YDQvtGF0L7QttC00LXQvdC40Y8gaHR0cC0=?= =?UTF-8?B?0YTQsNC3INGB0LXRgNCy0LXRgNCw?= In-Reply-To: <20130318184959.GA15239@localhost> References: <20130318132425.GA30673@localhost> <20130318134042.GB15378@mdounin.ru> <20130318143453.GA23958@localhost> <20130318145322.GD15378@mdounin.ru> <20130318153807.GA16652@localhost> <20130318160054.GF15378@mdounin.ru> <20130318184959.GA15239@localhost> Message-ID: <20130319105521.GH15378@mdounin.ru> Hello! On Mon, Mar 18, 2013 at 10:49:59PM +0400, Oleg wrote: > On Mon, Mar 18, 2013 at 08:00:55PM +0400, Maxim Dounin wrote: > > Hello! > > > > > А http-redirect может только модуль фазы NGX_HTTP_CONTENT_PHASE слать или с > > > фазы NGX_HTTP_ACCESS_PHASE тоже можно слать перенаправления? > > > > Можно из любой фазы (но может требовать дополнительных > > приседаний). > > Так. Попробовал по-быстрому сделать перенаправление. Никаких приседаний не > заметил, по крайней мере для фазы NGX_HTTP_ACCESS_PHASE. Может, чего-то не > учёл, конечно, но сделал в лоб: > > h = r->headers_out.location; > if ( h == NULL ) { > h = ngx_list_push(&r->headers_out.headers); > if ( h == NULL ) > return NGX_ERROR; > > h->key.data = "Location"; > h->key.len = sizeof("Location") - 1; > > r->headers_out.location = h; > } > h->value.data = "http://ya.ru"; > h->value.len = sizeof("http://ya.ru") - 1; > h->hash = 1; > > r->headers_out.status = NGX_HTTP_TEMPORARY_REDIRECT; > ngx_http_send_header(r); > > return NGX_OK; > > Работает нормально. Так, насколько я понимаю, будет мусор на выходе - сначала ответ 302 без тела, а потом ответ на исходный запрос. Посмотрите telnet'ом на ответ. Для access-фазы проще всего добавить заголовок location, и вернуть NGX_HTTP_TEMPORARY_REDIRECT (BTW, хочется возвращать именно 307?). Собственно, так же, как и для content-фазы, ибо там есть специальная обработка NGX_HTTP_*. Как-то так (выдержка из ngx_http_static_module.c): ngx_http_clear_location(r); r->headers_out.location = ngx_palloc(r->pool, sizeof(ngx_table_elt_t)); if (r->headers_out.location == NULL) { return NGX_ERROR; } r->headers_out.location->value.len = len; r->headers_out.location->value.data = location; return NGX_HTTP_TEMPORARY_REDIRECT; -- Maxim Dounin http://nginx.org/en/donation.html From lego12239 at yandex.ru Tue Mar 19 11:25:40 2013 From: lego12239 at yandex.ru (Oleg) Date: Tue, 19 Mar 2013 15:25:40 +0400 Subject: =?UTF-8?B?UmU6INC/0L7RgNGP0LTQvtC6INC/0YDQvtGF0L7QttC00LXQvdC40Y8gaHR0cC0=?= =?UTF-8?B?0YTQsNC3INGB0LXRgNCy0LXRgNCw?= In-Reply-To: <20130319105521.GH15378@mdounin.ru> References: <20130318132425.GA30673@localhost> <20130318134042.GB15378@mdounin.ru> <20130318143453.GA23958@localhost> <20130318145322.GD15378@mdounin.ru> <20130318153807.GA16652@localhost> <20130318160054.GF15378@mdounin.ru> <20130318184959.GA15239@localhost> <20130319105521.GH15378@mdounin.ru> Message-ID: <20130319112540.GA12272@localhost> On Tue, Mar 19, 2013 at 02:55:21PM +0400, Maxim Dounin wrote: > Hello! > > Так, насколько я понимаю, будет мусор на выходе - сначала ответ > 302 без тела, а потом ответ на исходный запрос. Посмотрите > telnet'ом на ответ. Да :-). Я это предположил, но проверить забыл. Какие-то символы 'ba' в ответе странные: $ telnet zbox-srv.kvm 80 Trying 192.168.77.26... Connected to zbox-srv.kvm. Escape character is '^]'. GET /zboxweb/user/admin HTTP/1.1 Host: zbox-srv.kvm HTTP/1.1 307 Temporary Redirect Server: nginx/1.2.1 Date: Tue, 19 Mar 2013 11:24:40 GMT Transfer-Encoding: chunked Connection: keep-alive Location: http://$host/zboxweb ba 307 Temporary Redirect

307 Temporary Redirect


nginx/1.2.1
0 quit 400 Bad Request

400 Bad Request


nginx/1.2.1
Connection closed by foreign host. > Для access-фазы проще всего добавить заголовок location, и вернуть > NGX_HTTP_TEMPORARY_REDIRECT (BTW, хочется возвращать именно 307?). > Собственно, так же, как и для content-фазы, ибо там есть > специальная обработка NGX_HTTP_*. Как-то так (выдержка из > ngx_http_static_module.c): > > ngx_http_clear_location(r); > > r->headers_out.location = ngx_palloc(r->pool, sizeof(ngx_table_elt_t)); > if (r->headers_out.location == NULL) { > return NGX_ERROR; > } > > r->headers_out.location->value.len = len; > r->headers_out.location->value.data = location; > > return NGX_HTTP_TEMPORARY_REDIRECT; Т.е. устанавливать r->headers_out.status и делать ngx_http_send_header(r) необязательно? From mdounin at mdounin.ru Tue Mar 19 12:34:17 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 19 Mar 2013 16:34:17 +0400 Subject: keep-alive: lost requests In-Reply-To: References: <20130317231639.GV15378@mdounin.ru> <20130318184946.GG15378@mdounin.ru> Message-ID: <20130319123417.GI15378@mdounin.ru> Hello! On Mon, Mar 18, 2013 at 11:01:14PM +0400, Daniel Podolsky wrote: > > (Самописный upload progress на перле? Вообще-то он такого не > > умеет...) > А что тут уметь? хендлер от временного файла есть, заголовок > content-length есть, размер stat отдает. Ну, если гранулярность до client_body_buffer_size устраивает - то можно и так, да. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Tue Mar 19 12:42:19 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 19 Mar 2013 16:42:19 +0400 Subject: =?UTF-8?B?UmU6INC/0L7RgNGP0LTQvtC6INC/0YDQvtGF0L7QttC00LXQvdC40Y8gaHR0cC0=?= =?UTF-8?B?0YTQsNC3INGB0LXRgNCy0LXRgNCw?= In-Reply-To: <20130319112540.GA12272@localhost> References: <20130318132425.GA30673@localhost> <20130318134042.GB15378@mdounin.ru> <20130318143453.GA23958@localhost> <20130318145322.GD15378@mdounin.ru> <20130318153807.GA16652@localhost> <20130318160054.GF15378@mdounin.ru> <20130318184959.GA15239@localhost> <20130319105521.GH15378@mdounin.ru> <20130319112540.GA12272@localhost> Message-ID: <20130319124218.GJ15378@mdounin.ru> Hello! On Tue, Mar 19, 2013 at 03:25:40PM +0400, Oleg wrote: > On Tue, Mar 19, 2013 at 02:55:21PM +0400, Maxim Dounin wrote: > > Hello! > > > > Так, насколько я понимаю, будет мусор на выходе - сначала ответ > > 302 без тела, а потом ответ на исходный запрос. Посмотрите > > telnet'ом на ответ. > > Да :-). Я это предположил, но проверить забыл. > Какие-то символы 'ba' в ответе странные: Символы 'ba' - это chunked transfer encoding, который используется потому, что Content-Length ответа не известен на момент отправки заголовков. Странно, что это единственная вылезающая проблема. [...] > > Для access-фазы проще всего добавить заголовок location, и вернуть > > NGX_HTTP_TEMPORARY_REDIRECT (BTW, хочется возвращать именно 307?). > > Собственно, так же, как и для content-фазы, ибо там есть > > специальная обработка NGX_HTTP_*. Как-то так (выдержка из > > ngx_http_static_module.c): > > > > ngx_http_clear_location(r); > > > > r->headers_out.location = ngx_palloc(r->pool, sizeof(ngx_table_elt_t)); > > if (r->headers_out.location == NULL) { > > return NGX_ERROR; > > } > > > > r->headers_out.location->value.len = len; > > r->headers_out.location->value.data = location; > > > > return NGX_HTTP_TEMPORARY_REDIRECT; > > Т.е. устанавливать r->headers_out.status и делать ngx_http_send_header(r) > необязательно? Нет, возврата NGX_HTTP_TEMPORARY_REDIRECT - достаточно. -- Maxim Dounin http://nginx.org/en/donation.html From chipitsine at gmail.com Tue Mar 19 13:06:25 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 19 Mar 2013 19:06:25 +0600 Subject: =?UTF-8?B?UmU6IG5naW54INC4INGB0LjQvdGC0LXRgtC40YfQtdGB0LrQuNC5INGC0LXRgdGC?= =?UTF-8?B?IChhYiwgc2llZ2UsIHlhbmRleC10YW5rKQ==?= In-Reply-To: <48427c84dfe8dda1f86a132af4a119b2.NginxMailingListRussian@forum.nginx.org> References: <48427c84dfe8dda1f86a132af4a119b2.NginxMailingListRussian@forum.nginx.org> Message-ID: А заголовки позволяют кешировать ответ? 19.03.2013 12:23 пользователь "sitsalavat" написал: > Всем привет. > > Есть сервер на котором в качестве фронтенда крутится nginx. Выдержки из > конфига: > ======================= > worker_processes 8; > > events { > worker_connections 4096; > } > > proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=all:512m inactive=1d > max_size=6g; > > proxy_cache_key "$host$request_uri"; > proxy_cache_valid 404 40m; > proxy_cache_valid 500 501 502 503 504 1m; > proxy_cache_valid any 5m; > proxy_cache_use_stale http_502 http_503 http_504; > proxy_cache_bypass $cookie_logined; > proxy_no_cache $cookie_logined; > > proxy_connect_timeout 40; > proxy_send_timeout 40; > proxy_read_timeout 100; > > proxy_buffer_size 4m; > proxy_buffers 24 1m; > proxy_busy_buffers_size 8m; > proxy_temp_file_write_size 4m; > > location / { > if ($cookie_logined) { return 412; } > proxy_cache all; > > proxy_pass @fallback; > proxy_redirect @fallback; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header X-Real-IP $remote_addr; > } > ======================= > > > Насколько я понимаю, если cookie logined нет - то пользователю должна > отдавать закешированная версия, которая лежит в nginx и при синтетических > тестах - они так же свободно отдавались бы. > Фактически же при ab -kc 500 -n 500 -t 30 nginx начинает все сплавлять на > бекенд и соответственно LA начинает зашкаливать. > > Люди добрые, помогите мне :) > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,237524,237524#msg-237524 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From lego12239 at yandex.ru Tue Mar 19 13:10:35 2013 From: lego12239 at yandex.ru (Oleg) Date: Tue, 19 Mar 2013 17:10:35 +0400 Subject: =?UTF-8?B?UmU6INC/0L7RgNGP0LTQvtC6INC/0YDQvtGF0L7QttC00LXQvdC40Y8gaHR0cC0=?= =?UTF-8?B?0YTQsNC3INGB0LXRgNCy0LXRgNCw?= In-Reply-To: <20130319124218.GJ15378@mdounin.ru> References: <20130318132425.GA30673@localhost> <20130318134042.GB15378@mdounin.ru> <20130318143453.GA23958@localhost> <20130318145322.GD15378@mdounin.ru> <20130318153807.GA16652@localhost> <20130318160054.GF15378@mdounin.ru> <20130318184959.GA15239@localhost> <20130319105521.GH15378@mdounin.ru> <20130319112540.GA12272@localhost> <20130319124218.GJ15378@mdounin.ru> Message-ID: <20130319131035.GA3475@localhost> On Tue, Mar 19, 2013 at 04:42:19PM +0400, Maxim Dounin wrote: > Hello! > > On Tue, Mar 19, 2013 at 03:25:40PM +0400, Oleg wrote: > > Да :-). Я это предположил, но проверить забыл. > > Какие-то символы 'ba' в ответе странные: > > Символы 'ba' - это chunked transfer encoding, который используется > потому, что Content-Length ответа не известен на момент отправки > заголовков. Странно, что это единственная вылезающая проблема. А что ещё должно было вылезти? > > Т.е. устанавливать r->headers_out.status и делать ngx_http_send_header(r) > > необязательно? > > Нет, возврата NGX_HTTP_TEMPORARY_REDIRECT - достаточно. Убрал эти строки - редирект всё ещё работает :-). From mdounin at mdounin.ru Tue Mar 19 13:25:34 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 19 Mar 2013 17:25:34 +0400 Subject: =?UTF-8?B?UmU6IFgtQWNjZWwtUmVkaXJlY3Qg0L3QsCA0MDQg0L/QvtGB0LvQtSBmYWxsYmFj?= =?UTF-8?B?aw==?= In-Reply-To: <1363669663.443659970@f384.i.mail.ru> References: <1363669663.443659970@f384.i.mail.ru> Message-ID: <20130319132534.GM15378@mdounin.ru> Hello! On Tue, Mar 19, 2013 at 09:07:43AM +0400, Nicholas Kostirya wrote: [...] > И в такой конфигурации, когда бекенд возвращает ответ с > "X-Accel-Redirect: /404", > то nginx отдает не /404.html страницу, а свою внутреннюю. > > Если же делать сразу "X-Accel-Redirect: /404.html", то не будет > 404 статуса. > > Какое есть решение для этой ситуации? > > Кстати, вызов memcached можно даже убрать, достаточно оставить > цепочку из двух error_page. > Такое ощущение, что если в процессе обработки запроса > использовался именованный локайшен, то уже не обычные возврата > нет. http://nginx.org/r/recursive_error_pages -- Maxim Dounin http://nginx.org/en/donation.html From nick_ik at mail.ru Tue Mar 19 13:40:11 2013 From: nick_ik at mail.ru (=?UTF-8?B?TmljaG9sYXMgS29zdGlyeWE=?=) Date: Tue, 19 Mar 2013 17:40:11 +0400 Subject: =?UTF-8?B?UmVbMl06IFgtQWNjZWwtUmVkaXJlY3Qg0L3QsCA0MDQg0L/QvtGB0LvQtSBmYWxs?= =?UTF-8?B?YmFjaw==?= In-Reply-To: <20130319132534.GM15378@mdounin.ru> References: <1363669663.443659970@f384.i.mail.ru> <20130319132534.GM15378@mdounin.ru> Message-ID: <1363700411.336557264@f393.i.mail.ru> Спасибо! Как не хватает в документации ссылок "смотри также..." :-) Вторник, 19 марта 2013, 17:25 +04:00 от Maxim Dounin : >Hello! > >On Tue, Mar 19, 2013 at 09:07:43AM +0400, Nicholas Kostirya wrote: > >[...] > >> И в такой конфигурации, когда бекенд возвращает ответ с >> "X-Accel-Redirect: /404", >> то nginx отдает не /404.html страницу, а свою внутреннюю. >> >> Если же делать сразу "X-Accel-Redirect: /404.html", то не будет >> 404 статуса. >> >> Какое есть решение для этой ситуации? >> >> Кстати, вызов memcached можно даже убрать, достаточно оставить >> цепочку из двух error_page. >> Такое ощущение, что если в процессе обработки запроса >> использовался именованный локайшен, то уже не обычные возврата >> нет. > >http://nginx.org/r/recursive_error_pages > >-- >Maxim Dounin >http://nginx.org/en/donation.html > >_______________________________________________ >nginx-ru mailing list >nginx-ru at nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Wed Mar 20 09:09:38 2013 From: nginx-forum at nginx.us (john2do) Date: Wed, 20 Mar 2013 05:09:38 -0400 Subject: if ($args)/if ($arg_) + location Message-ID: Столкнулся тут с странным поведением, а именно: если использовать конструкцию в локейшине вида: if ( $arg_nossi != 1 ) { ssi on; } ssi_value_length 4k; set $transmit $uri; if ( $args ) { set $transmit $uri?$args; } то при появлении любого аргумента - включается ssi, но если if ($args) вытащить раньше if ($arg_nossi) то такой вид работает как и задумывалось: set $transmit $uri; if ( $args ) { set $transmit $uri?$args; } if ( $arg_nossi != 1 ) { ssi on; } ssi_value_length 4k; три дня колдовства. баг? фича? nginx/1.2.5 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237585,237585#msg-237585 From mdounin at mdounin.ru Wed Mar 20 09:14:35 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 20 Mar 2013 13:14:35 +0400 Subject: if ($args)/if ($arg_) + location In-Reply-To: References: Message-ID: <20130320091435.GE62550@mdounin.ru> Hello! On Wed, Mar 20, 2013 at 05:09:38AM -0400, john2do wrote: > Столкнулся тут с странным поведением, а именно: > если использовать конструкцию в локейшине вида: > > if ( $arg_nossi != 1 ) { > ssi on; > } > ssi_value_length 4k; > > set $transmit $uri; > if ( $args ) { > set $transmit $uri?$args; > } > > то при появлении любого аргумента - включается ssi, но > если if ($args) вытащить раньше if ($arg_nossi) то такой вид работает как и > задумывалось: > > set $transmit $uri; > if ( $args ) { > set $transmit $uri?$args; > } > > if ( $arg_nossi != 1 ) { > ssi on; > } > ssi_value_length 4k; > > три дня колдовства. > баг? фича? > nginx/1.2.5 http://wiki.nginx.org/IfIsEvil -- Maxim Dounin http://nginx.org/en/donation.html From postmaster at softsearch.ru Wed Mar 20 17:55:55 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 20 Mar 2013 21:55:55 +0400 Subject: erroneous characters after protocol string Message-ID: <42636068.20130320215555@softsearch.ru> Здравствуйте, Maxim. В логе ошибок Апача вижу вот такие ошибки: [Wed Mar 20 18:48:05 2013] [error] [client 127.0.1.5] request failed: erroneous characters after protocol string: GET /r?r=http%3A%2F%2Flesfacadiersdelamediterranee.com %2Flevel%2F1%2Ffilm%2F412283%2F HTTP/1.0 [Wed Mar 20 19:39:28 2013] [error] [client 127.0.1.5] request failed: erroneous characters after protocol string: GET /r?r=http%3A%2F%2Fdo-it-mobile.com%2Fstory.php%3Ftitle%3D\\xec\\xa0\\x84\\xeb\\xa1\\x80\\xeb\\xb4\\x89\\xec\\x82\\xac\\xeb\\x8b\\xa8-\\xeb\\xb6\\x80\\xed\\x99\\x9c-\\xec\\xa0\\x9c-3\\xec\\xa3\\xbc-\\xec\\xa0\\x9c\\xeb\\x8c\\x80\\xea\\xbd\\x83 HTTP/1.0 К апачу запросы проксирует nginx, у которого включён accept_filter=httpready . Я думал, что мусор до бэкенда пройти не может. Но как-то получилось, что кривые запросы пропустил сначала акцепт-фильтр, а затем и nginx/1.3.11. Хочется понять, как такой запрос прошёл и можно ли nginx-ом прикрывать Апач от мусорных запросов? -- С уважением, Михаил mailto:postmaster at softsearch.ru From mdounin at mdounin.ru Wed Mar 20 18:28:41 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 20 Mar 2013 22:28:41 +0400 Subject: erroneous characters after protocol string In-Reply-To: <42636068.20130320215555@softsearch.ru> References: <42636068.20130320215555@softsearch.ru> Message-ID: <20130320182841.GL62550@mdounin.ru> Hello! On Wed, Mar 20, 2013 at 09:55:55PM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > В логе ошибок Апача вижу вот такие ошибки: > [Wed Mar 20 18:48:05 2013] [error] [client 127.0.1.5] request failed: erroneous characters after protocol string: GET /r?r=http%3A%2F%2Flesfacadiersdelamediterranee.com %2Flevel%2F1%2Ffilm%2F412283%2F HTTP/1.0 > [Wed Mar 20 19:39:28 2013] [error] [client 127.0.1.5] request failed: erroneous characters after protocol string: GET /r?r=http%3A%2F%2Fdo-it-mobile.com%2Fstory.php%3Ftitle%3D\\xec\\xa0\\x84\\xeb\\xa1\\x80\\xeb\\xb4\\x89\\xec\\x82\\xac\\xeb\\x8b\\xa8-\\xeb\\xb6\\x80\\xed\\x99\\x9c-\\xec\\xa0\\x9c-3\\xec\\xa3\\xbc-\\xec\\xa0\\x9c\\xeb\\x8c\\x80\\xea\\xbd\\x83 HTTP/1.0 > > К апачу запросы проксирует nginx, у которого включён > accept_filter=httpready . Я думал, что мусор до бэкенда пройти не > может. Но как-то получилось, что кривые запросы пропустил сначала > акцепт-фильтр, а затем и nginx/1.3.11. Хочется понять, как такой > запрос прошёл и можно ли nginx-ом прикрывать Апач от мусорных > запросов? Accept-фильтр всё, что не понимает, пропускает, даже если это вообще не HTTP. А nginx спокойно относится к использованию в URI любых не-специальных символов, особенно учитывая, что такие запросы вполне встречаются в реальности. Если хочется проверять - это всегда можно сделать явно. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Mar 20 18:46:20 2013 From: nginx-forum at nginx.us (sergey_s) Date: Wed, 20 Mar 2013 14:46:20 -0400 Subject: =?UTF-8?Q?map_=D0=B8_limit_req?= Message-ID: <26b4e836b5ab0bb0e1e54ada214a2146.NginxMailingListRussian@forum.nginx.org> Здравствуйте Друзья, растолкуйте пожалуйста такой кусок конфига, найден тут, в рассылке map $http_user_agent $bot_ua { ~bot bot; } limit_req_zone $bot_ua zone=bot:10m rate=1r/s; limit_req zone=bot burst=120; я понимаю как работает map, но хоть убей не понимаю как она связана тут с limit_req_zone ( дока тоже мне как-то свет не проливает на это ) что в $http_user_agent на начальном этапе понятно, в $bot_ua - пустая строка далее, при нахождении в $http_user_agent подстроки bot, $bot_ua, присваивается значение bot правильно ? а далее, меня сбивает с толку limit_req_zone $bot_ua... .. предположим нужная подстрока найдена, тогда переменная $bot_ua = bot в итоге получается: limit_req_zone bot zone=bot:10m rate=1r/s; limit_req zone=bot burst=120; правильно ? тогда как это вообще работает ? расскажите если не трудно и вопрос связанный со всем этим нужно резать канал конкретным юзерагентам из определенного списка, ( либо через инклуд списка, либо просто перечисленыым в директиве map ) Заранее благодарен Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237601,237601#msg-237601 From ru at nginx.com Wed Mar 20 19:08:20 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Wed, 20 Mar 2013 23:08:20 +0400 Subject: =?UTF-8?Q?Re=3A_map_=D0=B8_limit_req?= In-Reply-To: <26b4e836b5ab0bb0e1e54ada214a2146.NginxMailingListRussian@forum.nginx.org> References: <26b4e836b5ab0bb0e1e54ada214a2146.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130320190820.GA91875@lo0.su> On Wed, Mar 20, 2013 at 02:46:20PM -0400, sergey_s wrote: > Здравствуйте > Друзья, растолкуйте пожалуйста такой кусок конфига, найден тут, в рассылке > > map $http_user_agent $bot_ua { > ~bot bot; > } > > limit_req_zone $bot_ua zone=bot:10m rate=1r/s; > limit_req zone=bot burst=120; > > я понимаю как работает map, но хоть убей не понимаю как она связана тут с > limit_req_zone ( дока тоже мне как-то свет не проливает на это ) > что в $http_user_agent на начальном этапе понятно, в $bot_ua - пустая > строка > далее, при нахождении в $http_user_agent подстроки bot, $bot_ua, > присваивается значение bot > правильно ? > а далее, меня сбивает с толку > > limit_req_zone $bot_ua... .. Переменная $bot_ua, значение которой (bot или пустая строка) зависит от запроса, и является ключом в зоне "bot". Пустые значения (см. доку) в зоне не учитываются, другими словами, ограничиваться будут только боты. > предположим нужная подстрока найдена, тогда переменная $bot_ua = bot > в итоге получается: > > limit_req_zone bot zone=bot:10m rate=1r/s; > limit_req zone=bot burst=120; > > правильно ? > тогда как это вообще работает ? > > расскажите если не трудно Смысл в том, что там по синтаксису переменная, а они в nginx зависят от запроса. > и вопрос связанный со всем этим > нужно резать канал конкретным юзерагентам из определенного списка, ( либо > через инклуд списка, либо просто перечисленыым в директиве map ) Не услышал тут вопроса. Пример с User-Agent есть в документации к модулю map: http://nginx.org/ru/docs/http/ngx_http_map_module.html В зависимости от того, что нужно конкретно, значениям User-Agent из нужного списка в map могут соответствовать либо одно и то же непустое значение (например, "1", как выше для ботов), либо разные (если их ограничивать нужно по отдельности). Переменная задаёт ключ, по которому ведётся учёт и производится ограничение. Запросы с одинаковым значением ключа учитываются вместе. Я советую ещё раз вдумчиво прочитать документацию на map и limit_{req,conn} на http://nginx.org. From vbart at nginx.com Wed Mar 20 19:42:41 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 20 Mar 2013 23:42:41 +0400 Subject: =?UTF-8?Q?Re=3A_map_=D0=B8_limit_req?= In-Reply-To: <26b4e836b5ab0bb0e1e54ada214a2146.NginxMailingListRussian@forum.nginx.org> References: <26b4e836b5ab0bb0e1e54ada214a2146.NginxMailingListRussian@forum.nginx.org> Message-ID: <201303202342.41702.vbart@nginx.com> On Wednesday 20 March 2013 22:46:20 sergey_s wrote: > Здравствуйте > Друзья, растолкуйте пожалуйста такой кусок конфига, найден тут, в рассылке > > map $http_user_agent $bot_ua { > ~bot bot; > } > > limit_req_zone $bot_ua zone=bot:10m rate=1r/s; > limit_req zone=bot burst=120; > > я понимаю как работает map, но хоть убей не понимаю как она связана тут с > limit_req_zone ( дока тоже мне как-то свет не проливает на это ) > что в $http_user_agent на начальном этапе понятно, в $bot_ua - пустая > строка > далее, при нахождении в $http_user_agent подстроки bot, $bot_ua, > присваивается значение bot > правильно ? > а далее, меня сбивает с толку > > limit_req_zone $bot_ua... .. > > предположим нужная подстрока найдена, тогда переменная $bot_ua = bot > в итоге получается: > > limit_req_zone bot zone=bot:10m rate=1r/s; > limit_req zone=bot burst=120; > > правильно ? > тогда как это вообще работает ? > > расскажите если не трудно > > и вопрос связанный со всем этим > нужно резать канал конкретным юзерагентам из определенного списка, ( либо > через инклуд списка, либо просто перечисленыым в директиве map ) > > Заранее благодарен "Резать канал" это скорее к limit_rate: http://nginx.org/r/limit_rate/ru -- Валентин Бартенев http://nginx.org/en/donation.html From postmaster at softsearch.ru Wed Mar 20 20:02:52 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 21 Mar 2013 00:02:52 +0400 Subject: erroneous characters after protocol string In-Reply-To: <20130320182841.GL62550@mdounin.ru> References: <42636068.20130320215555@softsearch.ru> <20130320182841.GL62550@mdounin.ru> Message-ID: <1029895211.20130321000252@softsearch.ru> Здравствуйте, Maxim. >> К апачу запросы проксирует nginx, у которого включён >> accept_filter=httpready . Я думал, что мусор до бэкенда пройти не >> может. Но как-то получилось, что кривые запросы пропустил сначала >> акцепт-фильтр, а затем и nginx/1.3.11. Хочется понять, как такой >> запрос прошёл и можно ли nginx-ом прикрывать Апач от мусорных >> запросов? > Accept-фильтр всё, что не понимает, пропускает, даже если это вообще > не HTTP. А nginx спокойно относится к использованию в URI любых > не-специальных символов, особенно учитывая, что такие запросы вполне > встречаются в реальности. И пробел в урле встречается? Его ж на плюсик или %20 надо вроде заменять. Парсить такой запрос надо с двух сторон, чтобы понять, где границы урла. > Если хочется проверять - это всегда можно сделать явно. Через перечисление всех возможных локейшнов и сбрасывания всего остального в location / { return 444;} ? -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Wed Mar 20 20:06:29 2013 From: nginx-forum at nginx.us (sergey_s) Date: Wed, 20 Mar 2013 16:06:29 -0400 Subject: =?UTF-8?Q?Re=3A_map_=D0=B8_limit_req?= In-Reply-To: <20130320190820.GA91875@lo0.su> References: <20130320190820.GA91875@lo0.su> Message-ID: Спасибо, более менее прояснилось документацию я читал неоднократно и почти по слогам) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237602,237605#msg-237605 From nginx-forum at nginx.us Wed Mar 20 20:08:05 2013 From: nginx-forum at nginx.us (sergey_s) Date: Wed, 20 Mar 2013 16:08:05 -0400 Subject: =?UTF-8?Q?Re=3A_map_=D0=B8_limit_req?= In-Reply-To: <201303202342.41702.vbart@nginx.com> References: <201303202342.41702.vbart@nginx.com> Message-ID: прошу прощения, не так выразился, имел в виду именно реквесты в секунду спасибо Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237603,237606#msg-237606 From nginx-forum at nginx.us Wed Mar 20 22:38:17 2013 From: nginx-forum at nginx.us (sergey_s) Date: Wed, 20 Mar 2013 18:38:17 -0400 Subject: =?UTF-8?Q?Re=3A_map_=D0=B8_limit_req?= In-Reply-To: <20130320190820.GA91875@lo0.su> References: <20130320190820.GA91875@lo0.su> Message-ID: <6500d1e9d27893cac8ba6e427da34a04.NginxMailingListRussian@forum.nginx.org> странные вилы, либо я что-то опять не понимаю, если прописано http { .............. map $http_user_agent $var { default ""; } limit_req_zone $var zone=limit:10m rate=10r/m; limit_req_zone $binary_remote_addr zone=testzone:10m rate=10r/m; limit_req zone=testzone burst=1; } server { ... limit_req zone=limit burst=1 } зона testzone не срабатывает а если убрать строку limit_req zone=limit burst=1 из блока server и прописать ее в http http { ....... map $http_user_agent $var { default ""; } limit_req_zone $var zone=limit:10m rate=10r/m; limit_req zone=limit burst=1 limit_req_zone $binary_remote_addr zone=testzone:10m rate=10r/m; limit_req zone=testzone burst=1; ...... } то начинает работать никто не сталкивался с такой странностью ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237602,237608#msg-237608 From vl at nginx.com Thu Mar 21 04:34:44 2013 From: vl at nginx.com (Homutov Vladimir) Date: Thu, 21 Mar 2013 08:34:44 +0400 Subject: =?UTF-8?Q?Re=3A_map_=D0=B8_limit_req?= In-Reply-To: <6500d1e9d27893cac8ba6e427da34a04.NginxMailingListRussian@forum.nginx.org> References: <20130320190820.GA91875@lo0.su> <6500d1e9d27893cac8ba6e427da34a04.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130321043443.GA30779@vl> On Wed, Mar 20, 2013 at 06:38:17PM -0400, sergey_s wrote: > странные вилы, либо я что-то опять не понимаю, если прописано > > http { > .............. > map $http_user_agent $var { > default ""; > } > > limit_req_zone $var zone=limit:10m rate=10r/m; > > limit_req_zone $binary_remote_addr zone=testzone:10m rate=10r/m; > limit_req zone=testzone burst=1; > } > > server { > ... > limit_req zone=limit burst=1 > } > > зона testzone не срабатывает > а если убрать строку > limit_req zone=limit burst=1 > из блока server и прописать ее в http синтаксис: limit_req_zone $переменная zone=название:размер rate=скорость; умолчание: ? ----> контекст: http > > http { > ....... > map $http_user_agent $var { > default ""; > } > > limit_req_zone $var zone=limit:10m rate=10r/m; > limit_req zone=limit burst=1 > > limit_req_zone $binary_remote_addr zone=testzone:10m rate=10r/m; > limit_req zone=testzone burst=1; > ...... > } > > то начинает работать > никто не сталкивался с такой странностью ? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237602,237608#msg-237608 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From ru at nginx.com Thu Mar 21 06:25:19 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Thu, 21 Mar 2013 10:25:19 +0400 Subject: =?UTF-8?Q?Re=3A_map_=D0=B8_limit_req?= In-Reply-To: <6500d1e9d27893cac8ba6e427da34a04.NginxMailingListRussian@forum.nginx.org> References: <20130320190820.GA91875@lo0.su> <6500d1e9d27893cac8ba6e427da34a04.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130321062519.GB84136@lo0.su> On Wed, Mar 20, 2013 at 06:38:17PM -0400, sergey_s wrote: > странные вилы, либо я что-то опять не понимаю, если прописано > > http { > .............. > map $http_user_agent $var { > default ""; > } > > limit_req_zone $var zone=limit:10m rate=10r/m; > > limit_req_zone $binary_remote_addr zone=testzone:10m rate=10r/m; > limit_req zone=testzone burst=1; > } > > server { > ... > limit_req zone=limit burst=1 > } > > зона testzone не срабатывает > а если убрать строку > limit_req zone=limit burst=1 > из блока server и прописать ее в http > > http { > ....... > map $http_user_agent $var { > default ""; > } > > limit_req_zone $var zone=limit:10m rate=10r/m; > limit_req zone=limit burst=1 > > limit_req_zone $binary_remote_addr zone=testzone:10m rate=10r/m; > limit_req zone=testzone burst=1; > ...... > } > > то начинает работать > никто не сталкивался с такой странностью ? Это не странность. Так устроено наследование директив в nginx. limit_req на уровне server{} отменяет limit_req на уровне http{}. Если вам нужно одновременно несколько limit_req (поддерживается начиная с версии nginx 1.1.14), их следует указывать на одном уровне. From nginx-forum at nginx.us Thu Mar 21 08:02:52 2013 From: nginx-forum at nginx.us (sergey_s) Date: Thu, 21 Mar 2013 04:02:52 -0400 Subject: =?UTF-8?Q?Re=3A_map_=D0=B8_limit_req?= In-Reply-To: <20130321062519.GB84136@lo0.su> References: <20130321062519.GB84136@lo0.su> Message-ID: и то что это разные зоны, значения не имеет ? zone=limit zone=testzone Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237602,237620#msg-237620 From mdounin at mdounin.ru Thu Mar 21 10:22:09 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 21 Mar 2013 14:22:09 +0400 Subject: erroneous characters after protocol string In-Reply-To: <1029895211.20130321000252@softsearch.ru> References: <42636068.20130320215555@softsearch.ru> <20130320182841.GL62550@mdounin.ru> <1029895211.20130321000252@softsearch.ru> Message-ID: <20130321102209.GN62550@mdounin.ru> Hello! On Thu, Mar 21, 2013 at 12:02:52AM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > >> К апачу запросы проксирует nginx, у которого включён > >> accept_filter=httpready . Я думал, что мусор до бэкенда пройти не > >> может. Но как-то получилось, что кривые запросы пропустил сначала > >> акцепт-фильтр, а затем и nginx/1.3.11. Хочется понять, как такой > >> запрос прошёл и можно ли nginx-ом прикрывать Апач от мусорных > >> запросов? > > > Accept-фильтр всё, что не понимает, пропускает, даже если это вообще > > не HTTP. А nginx спокойно относится к использованию в URI любых > > не-специальных символов, особенно учитывая, что такие запросы вполне > > встречаются в реальности. > > И пробел в урле встречается? Его ж на плюсик или %20 надо вроде > заменять. Парсить такой запрос надо с двух сторон, чтобы понять, где > границы урла. Встречается, потому и был специально разрешён: http://mailman.nginx.org/pipermail/nginx/2010-June/020878.html > > Если хочется проверять - это всегда можно сделать явно. > > Через перечисление всех возможных локейшнов и сбрасывания всего > остального в location / { return 444;} ? Location'ы, если ты хочешь проверять и аргументы запросов тоже, не помогут, даже при проверке точного совпадения. А вот регулярное выражение, проверяющее $request, никто не мешает написать. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Mar 21 11:50:46 2013 From: nginx-forum at nginx.us (fox_m) Date: Thu, 21 Mar 2013 07:50:46 -0400 Subject: =?UTF-8?Q?Nhinx_=D0=B8_icecast?= Message-ID: <4037f540f2c447a1ef9baf3f095c0fae.NginxMailingListRussian@forum.nginx.org> Всем привет. Хочу поставить icecast позади nginx, но что бы при этом соединение шло через https. т.е. клиент у себя открывает ссылку типа: https://radio-server/radio1.m3u и попадает на icecast сервер. Возможно в принципе такое? Пока сделал обычное проксирование: location / { #root html; #index index.html index.htm; proxy_pass http://XXX.XXX.XXX.237:8000; proxy_buffering off; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237627,237627#msg-237627 From vbart at nginx.com Thu Mar 21 13:25:30 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 21 Mar 2013 17:25:30 +0400 Subject: =?UTF-8?Q?Re=3A_map_=D0=B8_limit_req?= In-Reply-To: References: <20130321062519.GB84136@lo0.su> Message-ID: <201303211725.30624.vbart@nginx.com> On Thursday 21 March 2013 12:02:52 sergey_s wrote: > и то что это разные зоны, значения не имеет ? > zone=limit > zone=testzone > Не имеет. Более того, иначе и быть не может: нельзя написать две директивы limit_req в одной локации с одинаковой зоной. Такая конфигурация ошибочна, и nginx выдаст ошибку. -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Mar 21 13:37:38 2013 From: nginx-forum at nginx.us (sergey_s) Date: Thu, 21 Mar 2013 09:37:38 -0400 Subject: =?UTF-8?Q?Re=3A_map_=D0=B8_limit_req?= In-Reply-To: <201303211725.30624.vbart@nginx.com> References: <201303211725.30624.vbart@nginx.com> Message-ID: Спасибо большое, понял Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237602,237632#msg-237632 From alex.hha at gmail.com Thu Mar 21 14:27:57 2013 From: alex.hha at gmail.com (Alex Domoradov) Date: Thu, 21 Mar 2013 16:27:57 +0200 Subject: =?UTF-8?B?0J/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgd2ViIHNvY2tldHM=?= Message-ID: В связи с недавно анонсированной поддержкой web sockets в nginx решил попробовать данную возможность. Создал простой конфиг server { listen 192.168.210.221:80; server_name 192.168.210.221; charset utf8; location / { proxy_pass http://localhost:54321; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; tcp_nodelay on; } } На localhost:54321 запущена debug консоль хрома. Но при поытке открыть http://192.168.210.221/devtools/devtools.html?ws=192.168.210.221/devtools/page/25_1 получаю ошибку websocket_closed. Через localhost все работает отлично http://i.piccy.info/i7/7ab5f5e9681901a16e853d0ca3489340/4-56-740/3206943/chrome.png Есть какие то идеи? # cat /etc/redhat-release CentOS release 6.4 (Final) # uname -r 2.6.32-358.2.1.el6.x86_64 # nginx -v nginx version: nginx/1.3.14 From nginx-forum at nginx.us Thu Mar 21 20:51:47 2013 From: nginx-forum at nginx.us (cat) Date: Thu, 21 Mar 2013 16:51:47 -0400 Subject: =?UTF-8?B?0L/QtdGA0LXQvNC10L3QvdGL0LkgbGltaXQgcmVxIHpvbmU=?= Message-ID: Приветствую. Пусть есть простой запрос: http://127.0.0.1/api?username=testuser Хочу ограничивать кол-во cоединений в единицу времени в зависимости от имени пользователя в параметре: кому-то разрешить больше запросов, кому-то меньше. В идеале это выглядело бы как-то так: ### map $arg_username $limits { bob 100; alice 300; default 10; } limit_req_zone $limits zone=per_user_limit:10m rate=$limitsr/s; ### Если бы не ошибка: 2013/03/21 22:34:25 [emerg] 17212#0: invalid rate "rate=$limitsr/m" in /etc/nginx/nginx.conf:44 Есть ли способ выставлять rate для limit_req_zone динамически? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237658,237658#msg-237658 From onokonem at gmail.com Thu Mar 21 21:09:18 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Fri, 22 Mar 2013 01:09:18 +0400 Subject: =?UTF-8?B?UmU6INC/0LXRgNC10LzQtdC90L3Ri9C5IGxpbWl0IHJlcSB6b25l?= In-Reply-To: References: Message-ID: > Есть ли способ выставлять rate для limit_req_zone динамически? Именованные локации? From vbart at nginx.com Fri Mar 22 00:14:06 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 22 Mar 2013 04:14:06 +0400 Subject: =?UTF-8?B?UmU6INC/0LXRgNC10LzQtdC90L3Ri9C5IGxpbWl0IHJlcSB6b25l?= In-Reply-To: References: Message-ID: <201303220414.06923.vbart@nginx.com> On Friday 22 March 2013 00:51:47 cat wrote: > Приветствую. > Пусть есть простой запрос: > > http://127.0.0.1/api?username=testuser > > Хочу ограничивать кол-во cоединений в единицу времени в зависимости от > имени пользователя в параметре: кому-то разрешить больше запросов, кому-то > меньше. В идеале это выглядело бы как-то так: > > ### > map $arg_username $limits { > bob 100; > alice 300; > default 10; > } > > limit_req_zone $limits zone=per_user_limit:10m rate=$limitsr/s; > ### > > Если бы не ошибка: > > 2013/03/21 22:34:25 [emerg] 17212#0: invalid rate "rate=$limitsr/m" in > /etc/nginx/nginx.conf:44 > > Есть ли способ выставлять rate для limit_req_zone динамически? > Иными словами вы хотите описать несколько зон с разным rate. Да, конечно это возможно: map $arg_username $is_bob { bob 1; } map $arg_username $is_alice { alice 1; } map $arg_username $is_default { dafault 1; bob ""; alice ""; } limit_req_zone $is_bob zone=user_bob:32k rate=100r/s; limit_req_zone $is_alice zone=user_alice:32k rate=300r/s; limit_req_zone $is_default zone=default_limit:32k rate=10r/s; location / { limit_req zone=default_limit; limit_req zone=user_bob; limit_req zone=user_alice; } -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri Mar 22 09:28:12 2013 From: nginx-forum at nginx.us (cat) Date: Fri, 22 Mar 2013 05:28:12 -0400 Subject: =?UTF-8?B?UmU6INC/0LXRgNC10LzQtdC90L3Ri9C5IGxpbWl0IHJlcSB6b25l?= In-Reply-To: <201303220414.06923.vbart@nginx.com> References: <201303220414.06923.vbart@nginx.com> Message-ID: <6127af2f8616d9978dc9abd1594a47ab.NginxMailingListRussian@forum.nginx.org> Спасибо, способ выглядит достаточно компактным. Проверить пока не могу потому, что > location / { > limit_req zone=default_limit; > limit_req zone=user_bob; > limit_req zone=user_alice; > } > что-то не то: 2013/03/22 05:12:20 [emerg] 26445#0: "limit_req" directive is duplicate in /etc/nginx/nginx.conf:17 Предвижу, что пришло время обновиться. # nginx -v nginx: nginx version: nginx/1.0.10 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237662,237668#msg-237668 From vbart at nginx.com Fri Mar 22 09:35:10 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 22 Mar 2013 13:35:10 +0400 Subject: =?UTF-8?B?UmU6INC/0LXRgNC10LzQtdC90L3Ri9C5IGxpbWl0IHJlcSB6b25l?= In-Reply-To: <6127af2f8616d9978dc9abd1594a47ab.NginxMailingListRussian@forum.nginx.org> References: <201303220414.06923.vbart@nginx.com> <6127af2f8616d9978dc9abd1594a47ab.NginxMailingListRussian@forum.nginx.org> Message-ID: <201303221335.11123.vbart@nginx.com> On Friday 22 March 2013 13:28:12 cat wrote: > Спасибо, способ выглядит достаточно компактным. Проверить пока не могу > потому, что > > > location / { > > > > limit_req zone=default_limit; > > limit_req zone=user_bob; > > limit_req zone=user_alice; > > > > } > > что-то не то: > > 2013/03/22 05:12:20 [emerg] 26445#0: "limit_req" directive is duplicate in > /etc/nginx/nginx.conf:17 > > Предвижу, что пришло время обновиться. > > # nginx -v > nginx: nginx version: nginx/1.0.10 > Именно так. Поддержка нескольких директив limit_req в location появилась начиная с 1.1.14. -- Валентин Бартенев http://nginx.org/en/donation.html From stellito at mail.ru Sat Mar 23 11:07:58 2013 From: stellito at mail.ru (=?UTF-8?B?0J/QvtGB0YLQvtCy0LDRgNC+0LIg0J/QsNCy0LXQuw==?=) Date: Sat, 23 Mar 2013 15:07:58 +0400 Subject: =?UTF-8?B?0J7RgtC60LvRjtGH0LXQvdC40LUg0LHRg9GE0LXRgNC40LfQsNGG0LjQuCDQvtGC?= =?UTF-8?B?0LLQtdGC0L7QsiBmYXN0Y2dp?= Message-ID: <1364036878.360419349@f221.mail.ru> Добрый день! Скажите, как можно сделать, чтобы ответы от fastcgi сервера направлялись сразу клиенту, не дожидаясь разрыва соединения с бекэндом? Пробовал ставить заголовок X-Accel-Buffering: no, как сказано в документации - почему-то не помогает. Нашел инфу про патч, который может помочь - http://www.ruby-forum.com/topic/2387715#1017453  , это единственный выход, или можно как-то решить проблему штатными средствами? -- Павел Постоваров -------------- next part -------------- An HTML attachment was scrubbed... URL: From public-mail at alekciy.ru Sat Mar 23 15:03:29 2013 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Sat, 23 Mar 2013 19:03:29 +0400 Subject: =?UTF-8?B?UmU6INCe0YLQutC70Y7Rh9C10L3QuNC1INCx0YPRhNC10YDQuNC30LDRhtC40Lgg?= =?UTF-8?B?0L7RgtCy0LXRgtC+0LIgZmFzdGNnaQ==?= In-Reply-To: <1364036878.360419349@f221.mail.ru> References: <1364036878.360419349@f221.mail.ru> Message-ID: Она не отключаемая. По крайне мере раньше было именно так. Если не ошибаюсь вариантом решение было использование proxy модуля. 23 марта 2013 г., 15:07 пользователь Постоваров Павел написал: > Добрый день! > Скажите, как можно сделать, чтобы ответы от fastcgi сервера направлялись > сразу клиенту, не дожидаясь разрыва соединения с бекэндом? Пробовал ставить > заголовок X-Accel-Buffering: no, как сказано в документации - почему-то не > помогает. Нашел инфу про патч, который может помочь > -http://www.ruby-forum.com/topic/2387715#1017453 , это единственный выход, > или можно как-то решить проблему штатными средствами? > > > -- > Павел Постоваров > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From ru at nginx.com Sat Mar 23 15:21:17 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Sat, 23 Mar 2013 19:21:17 +0400 Subject: =?UTF-8?B?UmU6INCe0YLQutC70Y7Rh9C10L3QuNC1INCx0YPRhNC10YDQuNC30LDRhtC40Lgg?= =?UTF-8?B?0L7RgtCy0LXRgtC+0LIgZmFzdGNnaQ==?= In-Reply-To: <1364036878.360419349@f221.mail.ru> References: <1364036878.360419349@f221.mail.ru> Message-ID: <20130323152117.GE91875@lo0.su> On Sat, Mar 23, 2013 at 03:07:58PM +0400, Постоваров Павел wrote: > Добрый день! > > Скажите, как можно сделать, чтобы ответы от fastcgi сервера > направлялись сразу клиенту, не дожидаясь разрыва соединения с > бекэндом? Пробовал ставить заголовок X-Accel-Buffering: no, как > сказано в документации - почему-то не помогает. Нашел инфу про > патч, который может помочь - > http://www.ruby-forum.com/topic/2387715#1017453  , это > единственный выход, или можно как-то решить проблему штатными > средствами? Отключить буферизацию ответов для FastCGI полностью в настоящий момент нельзя: http://mailman.nginx.org/pipermail/nginx-ru/2011-September/042870.html https://trac.nginx.org/nginx/ticket/159 Можно отключить буферизацию ответов на диск: http://nginx.org/r/fastcgi_max_temp_file_size/ru При включении "fastcgi_keep_conn on", побочным эффектом будет то, что nginx будет отправлять данные клиенту как только он получит FastCGI record целиком. From nginx-forum at nginx.us Sun Mar 24 11:44:26 2013 From: nginx-forum at nginx.us (progs86) Date: Sun, 24 Mar 2013 07:44:26 -0400 Subject: =?UTF-8?B?0J/QvtGH0LXQvNGDIE5HSU5YINCy0L7Qt9Cy0YDQsNGJ0LDQtdGCINC90LUg0L8=?= =?UTF-8?B?0YDQuNC00LXRgNC20LjQstCw0LXRgtGB0Y8g0LHQsNC30L7QstC+0LPQviA=?= =?UTF-8?B?0L/RgNC+0YLQvtC60L7Qu9CwIEZhc3RDR0k=?= Message-ID: <26e9ae17d7ce4809a14c65d562afa50a.NginxMailingListRussian@forum.nginx.org> Здравствуйте, Разрабатываю FastCGI сервер по спецификации FastCGI 1.1 (fastcgi.com), но столкнулся с тем что NGINX при первом соединении присылает первый FastCGI пакет с не неизвестной ролей (значение 0). Хотя в спецификации сказано что должно поддерживаться Responder (1), Authorizer(1), Filter(0). По идеи NGINX должен отправлять первый пакет с типом Responder (1), но он отправляет не известный тип (0). На что мой сервер FastCGI отвечает статусом не известная роль. После этого NGINX закрывает соединение с FastCGI сервером. Подскажите пожалуйста, в чем может быть причина, и что нужно отправлять NGINX при получении первого пакета с заданным неизвестным типом (значение 0). С уважением, Владимир. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237716,237716#msg-237716 From nginx-forum at nginx.us Sun Mar 24 11:45:28 2013 From: nginx-forum at nginx.us (progs86) Date: Sun, 24 Mar 2013 07:45:28 -0400 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyBOR0lOWCDQstC+0LfQstGA0LDRidCw0LXRgiDQvdC1?= =?UTF-8?B?INC/0YDQuNC00LXRgNC20LjQstCw0LXRgtGB0Y8g0LHQsNC30L7QstC+0LM=?= =?UTF-8?B?0L4g0L/RgNC+0YLQvtC60L7Qu9CwIEZhc3RDR0k=?= In-Reply-To: <26e9ae17d7ce4809a14c65d562afa50a.NginxMailingListRussian@forum.nginx.org> References: <26e9ae17d7ce4809a14c65d562afa50a.NginxMailingListRussian@forum.nginx.org> Message-ID: <53c325b0ec710b81bc1b64e515219bfe.NginxMailingListRussian@forum.nginx.org> Поправка: поддерживаться Responder (1), Authorizer(2), Filter(3). Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237716,237717#msg-237717 From nginx-forum at nginx.us Sun Mar 24 11:55:48 2013 From: nginx-forum at nginx.us (progs86) Date: Sun, 24 Mar 2013 07:55:48 -0400 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyBOR0lOWCDQstC+0LfQstGA0LDRidCw0LXRgiDQvdC1?= =?UTF-8?B?INC/0YDQuNC00LXRgNC20LjQstCw0LXRgtGB0Y8g0LHQsNC30L7QstC+0LM=?= =?UTF-8?B?0L4g0L/RgNC+0YLQvtC60L7Qu9CwIEZhc3RDR0k=?= In-Reply-To: <53c325b0ec710b81bc1b64e515219bfe.NginxMailingListRussian@forum.nginx.org> References: <26e9ae17d7ce4809a14c65d562afa50a.NginxMailingListRussian@forum.nginx.org> <53c325b0ec710b81bc1b64e515219bfe.NginxMailingListRussian@forum.nginx.org> Message-ID: <7f517de95a9fff13dfd4af7ba80d2a6c.NginxMailingListRussian@forum.nginx.org> Данные первого пакета: Version: 1 Type: BeginRequest RequestId: 1 ContentLength: 8 PaddingLength: 0 ------------------------ Все данные заполнены в нули. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237716,237719#msg-237719 From nginx-forum at nginx.us Sun Mar 24 12:18:39 2013 From: nginx-forum at nginx.us (progs86) Date: Sun, 24 Mar 2013 08:18:39 -0400 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyBOR0lOWCDQstC+0LfQstGA0LDRidCw0LXRgiDQvdC1?= =?UTF-8?B?INC/0YDQuNC00LXRgNC20LjQstCw0LXRgtGB0Y8g0LHQsNC30L7QstC+0LM=?= =?UTF-8?B?0L4g0L/RgNC+0YLQvtC60L7Qu9CwIEZhc3RDR0k=?= In-Reply-To: <7f517de95a9fff13dfd4af7ba80d2a6c.NginxMailingListRussian@forum.nginx.org> References: <26e9ae17d7ce4809a14c65d562afa50a.NginxMailingListRussian@forum.nginx.org> <53c325b0ec710b81bc1b64e515219bfe.NginxMailingListRussian@forum.nginx.org> <7f517de95a9fff13dfd4af7ba80d2a6c.NginxMailingListRussian@forum.nginx.org> Message-ID: Вопрос не актуален. Была ошибка в коде. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237716,237720#msg-237720 From nginx-forum at nginx.us Sun Mar 24 20:44:55 2013 From: nginx-forum at nginx.us (aaaa5) Date: Sun, 24 Mar 2013 16:44:55 -0400 Subject: =?UTF-8?B?0KPRgdC70L7QstC90YvQuSBmYXN0Y2dpIHBhcmFtIFNDUklQVCBGSUxFTkFNRQ==?= Message-ID: <00df830e5b710c3b7790791b9f58e705.NginxMailingListRussian@forum.nginx.org> Здравствуйте, встала следующая задача: в location = aaa {...} извне подаются определённые параметры, кроме $fastcgi_script_name. Как сделать так, чтобы можно было выбирать различные fastcgi_param SCRIPT_FILENAME в зависимости от условия? Пытаюсь сделать через if - пишет в данном месте оператор fastcgi_param не работает (т.е. внутри if). Что можно ещё попробовать чтобы fastcgi_param стал условным? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237723,237723#msg-237723 From vbart at nginx.com Sun Mar 24 21:42:28 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 25 Mar 2013 01:42:28 +0400 Subject: =?UTF-8?B?UmU6INCj0YHQu9C+0LLQvdGL0LkgZmFzdGNnaSBwYXJhbSBTQ1JJUFQgRklMRU5B?= =?UTF-8?B?TUU=?= In-Reply-To: <00df830e5b710c3b7790791b9f58e705.NginxMailingListRussian@forum.nginx.org> References: <00df830e5b710c3b7790791b9f58e705.NginxMailingListRussian@forum.nginx.org> Message-ID: <201303250142.28993.vbart@nginx.com> On Monday 25 March 2013 00:44:55 aaaa5 wrote: > Здравствуйте, встала следующая задача: в location = aaa {...} извне > подаются определённые параметры, кроме $fastcgi_script_name. Как сделать > так, чтобы можно было выбирать различные fastcgi_param SCRIPT_FILENAME в > зависимости от условия? > > Пытаюсь сделать через if - пишет в данном месте оператор fastcgi_param не > работает (т.е. внутри if). Что можно ещё попробовать чтобы fastcgi_param > стал условным? > http://nginx.org/ru/docs/http/ngx_http_map_module.html -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Sun Mar 24 22:41:34 2013 From: nginx-forum at nginx.us (aaaa5) Date: Sun, 24 Mar 2013 18:41:34 -0400 Subject: =?UTF-8?B?UmU6INCj0YHQu9C+0LLQvdGL0LkgZmFzdGNnaSBwYXJhbSBTQ1JJUFQgRklMRU5B?= =?UTF-8?B?TUU=?= In-Reply-To: <201303250142.28993.vbart@nginx.com> References: <201303250142.28993.vbart@nginx.com> Message-ID: Спасибо, разобрался Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237726,237727#msg-237727 From nginx-forum at nginx.us Mon Mar 25 04:49:34 2013 From: nginx-forum at nginx.us (collerperm) Date: Mon, 25 Mar 2013 00:49:34 -0400 Subject: basic auth Message-ID: <898979586fb706aaf1152f5de38cd818.NginxMailingListRussian@forum.nginx.org> Всем привет! Хочу настроить к 2 своим vhosts сабжевую аутентификацию. В одном случае на корень, во-втором на директорию. Прочитал эту ветку http://forum.nginx.org/read.php?2,2304,2304 но так и не понял таки какой вариант правильный. Испробовал несколько из предложенных однако так оно полностью не заработало. Вот конфиг одного из моих хостов (форума на движке IPB): server { listen 80; server_name site location / { root /var/www/site; index index.php index.html index.htm; try_files $uri $uri/ /index.php?$uri&$args; rewrite ^ /index.php? last; } location ~* \.(css|js|swf|ico|png|gif|jpg|jpeg)$ { root /var/www/site; access_log off; expires 5d; } access_log /var/log/nginx/main_access.log main; error_log /var/log/nginx/main_error.log; client_max_body_size 10M; location ~ /\.ht { deny all; } location ~ \.php$ { root /var/www/site; fastcgi_pass unix:/tmp/php-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /var/www/site$fastcgi_script_name; include /etc/nginx/fastcgi.conf; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237728,237728#msg-237728 From andrey at kopeyko.ru Mon Mar 25 06:48:17 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Mon, 25 Mar 2013 10:48:17 +0400 Subject: basic auth In-Reply-To: <898979586fb706aaf1152f5de38cd818.NginxMailingListRussian@forum.nginx.org> References: <898979586fb706aaf1152f5de38cd818.NginxMailingListRussian@forum.nginx.org> Message-ID: <514FF331.1040100@kopeyko.ru> 25.03.2013 08:49, collerperm пишет: > Всем привет! Добрый день! > Хочу настроить к 2 своим vhosts сабжевую аутентификацию. > В одном случае на корень, во-втором на директорию. > Прочитал эту ветку http://forum.nginx.org/read.php?2,2304,2304 но так и не > понял таки какой вариант правильный. Испробовал несколько из предложенных > однако так оно полностью не заработало. > > Вот конфиг одного из моих хостов (форума на движке IPB): А где у вас здесь аутентификация? В вашем конфиге её просто нет. Уточните, что именно вы хотите спрятать под аутентификацию - php-скрипты или и статику тоже -, и допишите в нужный location auth_basic "closed site"; auth_basic_user_file conf/htpasswd; -- Best regards, Andrey Kopeyko From ufaweb at gmail.com Mon Mar 25 09:21:28 2013 From: ufaweb at gmail.com (=?UTF-8?B?0KDRg9GB0LvQsNC9INCo0LDRgNC40L/QvtCy?=) Date: Mon, 25 Mar 2013 15:21:28 +0600 Subject: =?UTF-8?B?VHJhbnNmZXItRW5jb2Rpbmc6IGNodW5rZWQg0LTQu9GPINGB0YLQsNGC0LjRh9C1?= =?UTF-8?B?0YHQutC40YUg0YTQsNC50LvQvtCy?= Message-ID: Добрый день. Подскажите, поддерживает ли nginx возможность отдавать статические файлы чанками? Если запросить ресурс, который nginx будет проксировать, то Transfer-Encoding: chunked включается. Например, запрашиваем ресурс, который формируется wsgi-бэкендом: curl http://server.example.com/api/v1/file/foobar/status, то ответ будет таким: HTTP/1.1 200 OK Server: nginx/1.2.1 Date: Mon, 25 Mar 2013 09:09:08 GMT Content-Type: application/json Transfer-Encoding: chunked Connection: close d {"status": 0} 0 Т.е. все хорошо, ответ пришел чанками. Но если запросить ресурс, который представляет из себя просто статичный файл и обрабатывается вот таким location'ом: location /files/ { root /home/uploader/receiver; chunked_transfer_encoding on; } То имеем такую картину: Запрос: curl http://server.example.com/files/foobar Ответ: HTTP/1.1 200 OK Server: nginx/1.2.1 Date: Mon, 25 Mar 2013 09:05:02 GMT Content-Type: application/octet-stream Content-Length: 819098 Last-Modified: Mon, 25 Mar 2013 08:38:21 GMT Connection: keep-alive Accept-Ranges: bytes ...data Т.е. nginx отдает файл "спрошняком", не деля его на чанки. Можно ли добиться того, чтобы nginx разбивал на чанки не только ответы от бэкендов, но и статические файлы? (здесь же возникает вопрос, как настаивать размер чанка) Спасибо. p.s. возможно задачу можно решить иначе, поэтому также поясню зачем мне это надо. Если верить некому Бену (https://groups.google.com/forum/?fromgroups=#!topic/python-tornado/kvZma1JY1hc), то штатный http-клиент из tornado позволяет использовать streaming_callback (http://www.tornadoweb.org/en/stable/httpclient.html) только в том случае, если ответ от сервера не "сплошной", а разбит на чанки. -- С уважением, Шарипов Руслан. Руководитель отдела разработки и сопровождения программного обеспечения ОАО "Уфанет". Контактная информация: google+: http://gplus.to/ruslan jid: serafim at jabber.ufanet.ru wave: ufaweb at googlewave.com skype: ufaweb phone: +7(917)4775460 vkontakte: http://vkontakte.ru/ufaweb myspace: http://www.myspace.com/ufaweb facebook: http://facebook.com/sharipov linkedin: http://www.linkedin.com/in/ufaweb twitter: http://twitter.com/ufaweb From nginx-forum at nginx.us Mon Mar 25 10:05:20 2013 From: nginx-forum at nginx.us (flexdiez) Date: Mon, 25 Mar 2013 06:05:20 -0400 Subject: Redirect from www to non-www uri Message-ID: Есть домен site.ru При переходе на него с префиксом www, браузер говорит "К сожалению, Google Chrome не может найти страницу www.site.ru" в конфиге nginx.conf у меня прописано http { ... ... server { listen *:80; server_name www.site.ru; rewrite ^(.*) http://site.ru$1 permanent; } } Но это почему-то не помогает. Подскажите пожалуйста, в чем может быть причина. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237737,237737#msg-237737 From vbart at nginx.com Mon Mar 25 10:15:15 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 25 Mar 2013 14:15:15 +0400 Subject: =?UTF-8?B?UmU6IFRyYW5zZmVyLUVuY29kaW5nOiBjaHVua2VkICDQtNC70Y8g0YHRgtCw0YI=?= =?UTF-8?B?0LjRh9C10YHQutC40YUg0YTQsNC50LvQvtCy?= In-Reply-To: References: Message-ID: <201303251415.16042.vbart@nginx.com> On Monday 25 March 2013 13:21:28 Руслан Шарипов wrote: > Добрый день. > > Подскажите, поддерживает ли nginx возможность отдавать статические > файлы чанками? > В этом нет практического смысла. Теоретически можно его заставить это делать через какой-нибудь обработчик, который сделает размер ответа неизвестным (например пропускать через SSI, sub filter, или addition filter). > Если запросить ресурс, который nginx будет проксировать, то > Transfer-Encoding: chunked включается. Например, запрашиваем ресурс, > который формируется wsgi-бэкендом: curl > http://server.example.com/api/v1/file/foobar/status, то ответ будет > таким: > > HTTP/1.1 200 OK > Server: nginx/1.2.1 > Date: Mon, 25 Mar 2013 09:09:08 GMT > Content-Type: application/json > Transfer-Encoding: chunked > Connection: close > > d > {"status": 0} > 0 > > Т.е. все хорошо, ответ пришел чанками. > Не всегда. Всё зависит от ресурса. Если размер ответа неизвестен, то будет использоваться chunked transfer encoding, при условии, что клиент его поддерживает. > Но если запросить ресурс, который представляет из себя просто > статичный файл и обрабатывается вот таким location'ом: > > location /files/ { > root /home/uploader/receiver; > chunked_transfer_encoding on; > } > > То имеем такую картину: > > Запрос: curl http://server.example.com/files/foobar > Ответ: > > HTTP/1.1 200 OK > Server: nginx/1.2.1 > Date: Mon, 25 Mar 2013 09:05:02 GMT > Content-Type: application/octet-stream > Content-Length: 819098 > Last-Modified: Mon, 25 Mar 2013 08:38:21 GMT > Connection: keep-alive > Accept-Ranges: bytes > > ...data > > Т.е. nginx отдает файл "спрошняком", не деля его на чанки. Можно ли > добиться того, чтобы nginx разбивал на чанки не только ответы от > бэкендов, но и статические файлы? (здесь же возникает вопрос, как > настаивать размер чанка) > > Спасибо. > > p.s. возможно задачу можно решить иначе, поэтому также поясню зачем > мне это надо. Если верить некому Бену > (https://groups.google.com/forum/?fromgroups=#!topic/python-tornado/kvZma1J > Y1hc), то штатный http-клиент из tornado позволяет использовать > streaming_callback > (http://www.tornadoweb.org/en/stable/httpclient.html) только в том > случае, если ответ от сервера не "сплошной", а разбит на чанки. > Некий Бен скорее всего неправ, и streaming_callback работает вне зависимости от chunked transfer encoding. Во всяком случае, никаких явных указаний на обратное я не нашел. И было очень бы странно, если бы он это требовал. -- Валентин Бартенев http://nginx.org/en/donation.html From vbart at nginx.com Mon Mar 25 10:17:37 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 25 Mar 2013 14:17:37 +0400 Subject: Redirect from www to non-www uri In-Reply-To: References: Message-ID: <201303251417.37583.vbart@nginx.com> On Monday 25 March 2013 14:05:20 flexdiez wrote: > Есть домен site.ru > При переходе на него с префиксом www, браузер говорит > "К сожалению, Google Chrome не может найти страницу www.site.ru" > > в конфиге nginx.conf у меня прописано > > http { > ... > ... > server { > listen *:80; > server_name www.site.ru; > rewrite ^(.*) http://site.ru$1 permanent; > } > } > > > Но это почему-то не помогает. > Подскажите пожалуйста, в чем может быть причина. > В DNS. -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Mon Mar 25 12:57:40 2013 From: nginx-forum at nginx.us (somebi) Date: Mon, 25 Mar 2013 08:57:40 -0400 Subject: =?UTF-8?B?0KHQutC+0YDQvtGB0YLRjCDQvdCw0YfQsNC70LAg0LLQvtGB0L/RgNC+0LjQt9Cy?= =?UTF-8?B?0LXQtNC10L3QuNGPINCy0LjQtNC10L4g0LIg0LzQvtC00YPQu9C1IG1wNA==?= Message-ID: <87ef7119656003519cf4bc86a1242207.NginxMailingListRussian@forum.nginx.org> Хотел поинтересоваться. От чего зависит, как быстро начнется воспроизведение видео файла? Я написал флеш плеер, у Actionscript Netstream класса есть параметр относящийся к объему буфферизации, но он ничего не меняет. Тогда я решил копать в сторону конвертации видео. Я конвертирую видео через avconv. Есть ли какие-то реккомендации от комманды Nginx, которая разрабатывала mp4 модуль? Я пытаюсь добиться мгновенной перемотки видео, чтобы буфферизация не скачивала с сервера по 4-6мб видео перед тем, как начать его проигрывать. Как мне такого достичь? В каком направлении копать? Буду так же признателен за список форумов, где я могу получить хоть какую-то помощь в этой сфере. Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237744,237744#msg-237744 From denis at webmaster.spb.ru Mon Mar 25 13:10:18 2013 From: denis at webmaster.spb.ru (denis) Date: Mon, 25 Mar 2013 17:10:18 +0400 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0L3QsNGH0LDQu9CwINCy0L7RgdC/0YDQvtC4?= =?UTF-8?B?0LfQstC10LTQtdC90LjRjyDQstC40LTQtdC+INCyINC80L7QtNGD0LvQtSBt?= =?UTF-8?B?cDQ=?= In-Reply-To: <87ef7119656003519cf4bc86a1242207.NginxMailingListRussian@forum.nginx.org> References: <87ef7119656003519cf4bc86a1242207.NginxMailingListRussian@forum.nginx.org> Message-ID: <51504CBA.1020007@webmaster.spb.ru> 25.03.2013 16:57, somebi пишет: > Хотел поинтересоваться. От чего зависит, как быстро начнется воспроизведение > видео файла? Я написал флеш плеер, у Actionscript Netstream класса есть > параметр относящийся к объему буфферизации, но он ничего не меняет. http://nginx.org/ru/docs/http/ngx_http_mp4_module.html не? в том числе про метаданные. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anatoly at sonru.com Mon Mar 25 14:32:18 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Mon, 25 Mar 2013 14:32:18 +0000 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0L3QsNGH0LDQu9CwINCy0L7RgdC/0YDQvtC4?= =?UTF-8?B?0LfQstC10LTQtdC90LjRjyDQstC40LTQtdC+INCyINC80L7QtNGD0LvQtSBt?= =?UTF-8?B?cDQ=?= In-Reply-To: <87ef7119656003519cf4bc86a1242207.NginxMailingListRussian@forum.nginx.org> References: <87ef7119656003519cf4bc86a1242207.NginxMailingListRussian@forum.nginx.org> Message-ID: <0FF6149F-70E8-4A2F-97AE-A3B560FB1137@sonru.com> это не имеет никакого отношения к nginx, вам необходимо пересадить мета-данные с moov atom в начало файла скачайте исходники ffmpeg, после чего соберите qt-faststart (для mp4, если нужен flv - то ищите flvtool2) $ make tools/qt-faststart $ cp tools/qt-faststart /usr/local/bin/ после этого $ qt-faststart /source/file.mp4 /destination/file.mp4 разделы source и destination должны быть разные, иначе будет ругаться Анатолий On Mar 25, 2013, at 12:57 PM, somebi wrote: > Хотел поинтересоваться. От чего зависит, как быстро начнется воспроизведение > видео файла? Я написал флеш плеер, у Actionscript Netstream класса есть > параметр относящийся к объему буфферизации, но он ничего не меняет. > > Тогда я решил копать в сторону конвертации видео. Я конвертирую видео через > avconv. Есть ли какие-то реккомендации от комманды Nginx, которая > разрабатывала mp4 модуль? > > Я пытаюсь добиться мгновенной перемотки видео, чтобы буфферизация не > скачивала с сервера по 4-6мб видео перед тем, как начать его проигрывать. > > Как мне такого достичь? В каком направлении копать? > > Буду так же признателен за список форумов, где я могу получить хоть какую-то > помощь в этой сфере. > > Спасибо. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237744,237744#msg-237744 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Mon Mar 25 16:58:11 2013 From: nginx-forum at nginx.us (somebi) Date: Mon, 25 Mar 2013 12:58:11 -0400 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0L3QsNGH0LDQu9CwINCy0L7RgdC/0YDQvtC4?= =?UTF-8?B?0LfQstC10LTQtdC90LjRjyDQstC40LTQtdC+INCyINC80L7QtNGD0LvQtSBt?= =?UTF-8?B?cDQ=?= In-Reply-To: <0FF6149F-70E8-4A2F-97AE-A3B560FB1137@sonru.com> References: <0FF6149F-70E8-4A2F-97AE-A3B560FB1137@sonru.com> Message-ID: Я все это уже сделал еще до публикации этого поста. Но размер первичного файла приблизительно 5mb. Как можно уменьшить этот размер, скажем до 1mb? mp4_buffer_size 1m; mp4_max_buffer_size 5m; Эти настройки вроде настраивают сколько nginx будет использовать памяти на сервере. Я правда не пробовал их менять. Если поменять max_buffer_size, то что поменяется? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237744,237764#msg-237764 From nginx-forum at nginx.us Mon Mar 25 17:04:06 2013 From: nginx-forum at nginx.us (somebi) Date: Mon, 25 Mar 2013 13:04:06 -0400 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0L3QsNGH0LDQu9CwINCy0L7RgdC/0YDQvtC4?= =?UTF-8?B?0LfQstC10LTQtdC90LjRjyDQstC40LTQtdC+INCyINC80L7QtNGD0LvQtSBt?= =?UTF-8?B?cDQ=?= In-Reply-To: References: <0FF6149F-70E8-4A2F-97AE-A3B560FB1137@sonru.com> Message-ID: <743677a61f6fb29c71cfb5aff26b7cd1.NginxMailingListRussian@forum.nginx.org> Выкидывает исключение, если ставлю mp4_max_buffer_size 2mb: mp4 moov atom is too large:5376175, you may want to increase mp4_max_buffer_size Хмм это уже интересно. Значит надо копать в сторону размера мета данных. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237744,237765#msg-237765 From sofiamay at mail.ru Mon Mar 25 19:20:27 2013 From: sofiamay at mail.ru (=?UTF-8?B?c2RmYXNkZiBhc2RmYXNkZg==?=) Date: Mon, 25 Mar 2013 23:20:27 +0400 Subject: =?UTF-8?B?0KjQtdC50L/QtdGAINCyIE5naW54INC90LUg0YDQsNCx0L7RgtCw0LXRgg==?= Message-ID: <1364239227.365772129@f384.i.mail.ru> Здравствуйте! Столкнулся с очень неприятной проблемой. В Nginx не работает шейпер. Суть проблемы такова: Есть канал на 10 мегабит к примеру. Когда подключается человек с мощным каналом (а сейчас он почти у всех) и начинает что-то качать, то забирает себе всю скорость. Когда подключается второй и третий человек им достаются жалкие 1-2 килобайта в секунду! Ну как же так можно, разве Nginx не должен шейпить скорость и раздавать ее всем потокам поровну? Бред какой-то. Поясните мне кто знает... неужели Nginx такой тупой? Советовать мне $limit_rate и иже с ним НЕ НАДО. Это правило сведёт на нет всю свободность и канал будет проставить. Никаких ограничений вообще быть не должно, вопрос стоит в честной раздаче скорости всем потокам поровну. -- Павел From vbart at nginx.com Mon Mar 25 19:31:55 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 25 Mar 2013 23:31:55 +0400 Subject: =?UTF-8?B?UmU6INCo0LXQudC/0LXRgCDQsiBOZ2lueCDQvdC1INGA0LDQsdC+0YLQsNC10YI=?= In-Reply-To: <1364239227.365772129@f384.i.mail.ru> References: <1364239227.365772129@f384.i.mail.ru> Message-ID: <201303252331.56015.vbart@nginx.com> On Monday 25 March 2013 23:20:27 sdfasdf asdfasdf wrote: > Здравствуйте! > > Столкнулся с очень неприятной проблемой. В Nginx не работает шейпер. > > Суть проблемы такова: > > Есть канал на 10 мегабит к примеру. Когда подключается человек с мощным > каналом (а сейчас он почти у всех) и начинает что-то качать, то забирает > себе всю скорость. Когда подключается второй и третий человек им достаются > жалкие 1-2 килобайта в секунду! Ну как же так можно, разве Nginx не должен > шейпить скорость и раздавать ее всем потокам поровну? Бред какой-то. > Поясните мне кто знает... неужели Nginx такой тупой? > > Советовать мне $limit_rate и иже с ним НЕ НАДО. Это правило сведёт на нет > всю свободность и канал будет проставить. Никаких ограничений вообще быть > не должно, вопрос стоит в честной раздаче скорости всем потокам поровну. У вас наверное linux и sendfile включен? -- Валентин Бартенев http://nginx.org/en/donation.html From sofiamay at mail.ru Mon Mar 25 20:04:04 2013 From: sofiamay at mail.ru (=?UTF-8?B?c2RmYXNkZiBhc2RmYXNkZg==?=) Date: Tue, 26 Mar 2013 00:04:04 +0400 Subject: =?UTF-8?B?UmVbMl06INCo0LXQudC/0LXRgCDQsiBOZ2lueCDQvdC1INGA0LDQsdC+0YLQsNC1?= =?UTF-8?B?0YI=?= In-Reply-To: <201303252331.56015.vbart@nginx.com> References: <1364239227.365772129@f384.i.mail.ru> <201303252331.56015.vbart@nginx.com> Message-ID: <1364241844.839818024@f89.mail.ru> Да, у меня linux и sendfile включен. Отключил sendfile, выключил-включил nginx и эффекта ноль. Так что sendfile тут видимо непричем. Понедельник, 25 марта 2013, 23:31 +04:00 от Валентин Бартенев : >On Monday 25 March 2013 23:20:27 sdfasdf asdfasdf wrote: >> Здравствуйте! >> >> Столкнулся с очень неприятной проблемой. В Nginx не работает шейпер. >> >> Суть проблемы такова: >> >> Есть канал на 10 мегабит к примеру. Когда подключается человек с мощным >> каналом (а сейчас он почти у всех) и начинает что-то качать, то забирает >> себе всю скорость. Когда подключается второй и третий человек им достаются >> жалкие 1-2 килобайта в секунду! Ну как же так можно, разве Nginx не должен >> шейпить скорость и раздавать ее всем потокам поровну? Бред какой-то. >> Поясните мне кто знает... неужели Nginx такой тупой? >> >> Советовать мне $limit_rate и иже с ним НЕ НАДО. Это правило сведёт на нет >> всю свободность и канал будет проставить. Никаких ограничений вообще быть >> не должно, вопрос стоит в честной раздаче скорости всем потокам поровну. > >У вас наверное linux и sendfile включен? > >-- >Валентин Бартенев >http://nginx.org/en/donation.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From mybrokenbeat at gmail.com Mon Mar 25 21:23:42 2013 From: mybrokenbeat at gmail.com (Oleg) Date: Mon, 25 Mar 2013 23:23:42 +0200 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0L3QsNGH0LDQu9CwINCy0L7RgdC/0YDQvtC4?= =?UTF-8?B?0LfQstC10LTQtdC90LjRjyDQstC40LTQtdC+INCyINC80L7QtNGD0LvQtSBt?= =?UTF-8?B?cDQ=?= In-Reply-To: <743677a61f6fb29c71cfb5aff26b7cd1.NginxMailingListRussian@forum.nginx.org> References: <0FF6149F-70E8-4A2F-97AE-A3B560FB1137@sonru.com> <743677a61f6fb29c71cfb5aff26b7cd1.NginxMailingListRussian@forum.nginx.org> Message-ID: <04AB5542-CFEB-457F-87D1-FB3744CBFA8A@gmail.com> Посмотрите файл какой-то програмкой, которая умеет парсить mp4 файлы на атомы и гляньте где находиться moov атом. Если в конце файла, то пока не скачается весь файл, проигрывание не начнется. В этом случае надо переупаковать файл таким образом, чтобы moov находился вначале. Судя по симптомам проблема именно в этом, хотя ошибка говорит о другом. moov атом обычно небольшой ~до 10кб, вряд ли он будет 5мб. 25.03.2013, в 19:04, somebi написал(а): > Выкидывает исключение, если ставлю mp4_max_buffer_size 2mb: > > mp4 moov atom is too large:5376175, you may want to increase > mp4_max_buffer_size > > Хмм это уже интересно. Значит надо копать в сторону размера мета данных. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237744,237765#msg-237765 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Tue Mar 26 01:25:21 2013 From: nginx-forum at nginx.us (somebi) Date: Mon, 25 Mar 2013 21:25:21 -0400 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0L3QsNGH0LDQu9CwINCy0L7RgdC/0YDQvtC4?= =?UTF-8?B?0LfQstC10LTQtdC90LjRjyDQstC40LTQtdC+INCyINC80L7QtNGD0LvQtSBt?= =?UTF-8?B?cDQ=?= In-Reply-To: <04AB5542-CFEB-457F-87D1-FB3744CBFA8A@gmail.com> References: <04AB5542-CFEB-457F-87D1-FB3744CBFA8A@gmail.com> Message-ID: <1dc9fc62bd0de862b33ddca097dbe2c2.NginxMailingListRussian@forum.nginx.org> В том то и дело, что он огромный. Я уже переместил метаданные в начало фильма с помощью qt-faststart. Из-за чего может быть такой большой файл мета данных? Что вообще входит в эти мета данные? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237744,237776#msg-237776 From nginx-forum at nginx.us Tue Mar 26 01:26:30 2013 From: nginx-forum at nginx.us (somebi) Date: Mon, 25 Mar 2013 21:26:30 -0400 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0L3QsNGH0LDQu9CwINCy0L7RgdC/0YDQvtC4?= =?UTF-8?B?0LfQstC10LTQtdC90LjRjyDQstC40LTQtdC+INCyINC80L7QtNGD0LvQtSBt?= =?UTF-8?B?cDQ=?= In-Reply-To: <04AB5542-CFEB-457F-87D1-FB3744CBFA8A@gmail.com> References: <04AB5542-CFEB-457F-87D1-FB3744CBFA8A@gmail.com> Message-ID: <145792caba7a2c22841524e04d6f9769.NginxMailingListRussian@forum.nginx.org> Стрим работает, все проигрывается, только скачивается порядка 6 мегабайт до начала проигрывания и столько же при перемотке фильма. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237744,237777#msg-237777 From ru at nginx.com Tue Mar 26 05:11:34 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Tue, 26 Mar 2013 09:11:34 +0400 Subject: =?UTF-8?B?UmU6INCo0LXQudC/0LXRgCDQsiBOZ2lueCDQvdC1INGA0LDQsdC+0YLQsNC10YI=?= In-Reply-To: <1364241844.839818024@f89.mail.ru> References: <1364239227.365772129@f384.i.mail.ru> <201303252331.56015.vbart@nginx.com> <1364241844.839818024@f89.mail.ru> Message-ID: <20130326051134.GD91875@lo0.su> On Tue, Mar 26, 2013 at 12:04:04AM +0400, sdfasdf asdfasdf wrote: > Да, у меня linux и sendfile включен. Отключил sendfile, выключил-включил > nginx и эффекта ноль. Так что sendfile тут видимо непричем. http://nginx.org/r/sendfile_max_chunk/ru From chipitsine at gmail.com Tue Mar 26 11:03:30 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 26 Mar 2013 17:03:30 +0600 Subject: =?UTF-8?B?0L/QsNGC0Ycg0LTQu9GPIG5naW54L3dpbjMy?= Message-ID: Добрый день! мы достаточно плотно используем nginx для Windows, запускаем его через назначенное задание (scheduled tasks). Для этого в конфиге надо сделать "daemon off" и дальше менеджер заданий следит за мастер-процессом, запущенным на терминале. это, кстати, удобнее, чем служба Windows (вообще, назначенные задания более удобны и мы чаще используем их, чем службы). в этом сценарии есть один недостаток, при завершении мастер-процесса, остается запущенный worker-процесс. насколько я понял, в случае Windows это штатная ситуация (при такой работе с процессами, которая используется в nginx), для исправления предлагаю такой патч (сделан для 1.3.14): --- src/os/win32/ngx_process_cycle.c 2013-03-26 16:57:20.000000000 +0600 +++ src/os/win32/ngx_process_cycle.c.new 2013-03-26 16:57:00.987341331 +0600 @@ -303,6 +303,8 @@ ngx_console_handler(u_long type) { char *msg; + ngx_cycle_t *cycle; + cycle = (ngx_cycle_t *) ngx_cycle; switch (type) { @@ -316,6 +318,7 @@ case CTRL_CLOSE_EVENT: msg = "console closing, exiting"; + ngx_terminate_worker_processes(cycle); break; case CTRL_LOGOFF_EVENT: Илья Шипицин -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Tue Mar 26 11:27:20 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 26 Mar 2013 15:27:20 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBuZ2lueC93aW4zMg==?= In-Reply-To: References: Message-ID: <20130326112719.GM62550@mdounin.ru> Hello! On Tue, Mar 26, 2013 at 05:03:30PM +0600, Илья Шипицин wrote: > Добрый день! > > мы достаточно плотно используем nginx для Windows, запускаем его через > назначенное задание (scheduled tasks). Для этого в конфиге надо сделать > "daemon off" и дальше менеджер заданий следит за мастер-процессом, > запущенным на терминале. > > это, кстати, удобнее, чем служба Windows (вообще, назначенные задания более > удобны и мы чаще используем их, чем службы). > > в этом сценарии есть один недостаток, при завершении мастер-процесса, > остается запущенный worker-процесс. > > насколько я понял, в случае Windows это штатная ситуация (при такой работе > с процессами, которая используется в nginx), для исправления предлагаю > такой патч (сделан для 1.3.14): > > --- src/os/win32/ngx_process_cycle.c 2013-03-26 16:57:20.000000000 +0600 > +++ src/os/win32/ngx_process_cycle.c.new 2013-03-26 > 16:57:00.987341331 +0600 > @@ -303,6 +303,8 @@ > ngx_console_handler(u_long type) > { > char *msg; > + ngx_cycle_t *cycle; > + cycle = (ngx_cycle_t *) ngx_cycle; > > switch (type) { > > @@ -316,6 +318,7 @@ > > case CTRL_CLOSE_EVENT: > msg = "console closing, exiting"; > + ngx_terminate_worker_processes(cycle); > break; > > case CTRL_LOGOFF_EVENT: Звать ngx_terminate_worker_processes() - это не очень хорошая идея, это всё-таки аварийный механизм, и может приводить к нехорошему. Тут имеет смысл как минимум попытаться штатно завершить рабочие процессы. -- Maxim Dounin http://nginx.org/en/donation.html From chipitsine at gmail.com Tue Mar 26 11:43:21 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 26 Mar 2013 17:43:21 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBuZ2lueC93aW4zMg==?= In-Reply-To: <20130326112719.GM62550@mdounin.ru> References: <20130326112719.GM62550@mdounin.ru> Message-ID: давайте разбираться. если запускать nginx в консоли (это штатный режим, так работают назначенные задания), то завершение задания с точки зрения мастер-процесса выглядит, как CTRL_CLOSE_EVENT в функции-обработчике ngx_console_handler worker-процесс в это время залипает в функции ngx_worker_process_cycle в цикле "ev=WaitForMultipleObjects()" соответственно, закрытие мастера путем закрывания не приводит к тому, что в данном месте возникает какое-то событие. варианты - либо существенно переделывать логику и протаскивать сюда еще одно событие, либо жестко закрыть worker через ngx_terminate_worker_processes. чем чреват второй вариант ? ну ок, закроются текущие сессии. завершая задание, мы, вероятно, этого и добиваемся. 26 марта 2013 г., 17:27 пользователь Maxim Dounin написал: > Hello! > > On Tue, Mar 26, 2013 at 05:03:30PM +0600, Илья Шипицин wrote: > > > Добрый день! > > > > мы достаточно плотно используем nginx для Windows, запускаем его через > > назначенное задание (scheduled tasks). Для этого в конфиге надо сделать > > "daemon off" и дальше менеджер заданий следит за мастер-процессом, > > запущенным на терминале. > > > > это, кстати, удобнее, чем служба Windows (вообще, назначенные задания > более > > удобны и мы чаще используем их, чем службы). > > > > в этом сценарии есть один недостаток, при завершении мастер-процесса, > > остается запущенный worker-процесс. > > > > насколько я понял, в случае Windows это штатная ситуация (при такой > работе > > с процессами, которая используется в nginx), для исправления предлагаю > > такой патч (сделан для 1.3.14): > > > > --- src/os/win32/ngx_process_cycle.c 2013-03-26 16:57:20.000000000 > +0600 > > +++ src/os/win32/ngx_process_cycle.c.new 2013-03-26 > > 16:57:00.987341331 +0600 > > @@ -303,6 +303,8 @@ > > ngx_console_handler(u_long type) > > { > > char *msg; > > + ngx_cycle_t *cycle; > > + cycle = (ngx_cycle_t *) ngx_cycle; > > > > switch (type) { > > > > @@ -316,6 +318,7 @@ > > > > case CTRL_CLOSE_EVENT: > > msg = "console closing, exiting"; > > + ngx_terminate_worker_processes(cycle); > > break; > > > > case CTRL_LOGOFF_EVENT: > > Звать ngx_terminate_worker_processes() - это не очень хорошая > идея, это всё-таки аварийный механизм, и может приводить к > нехорошему. Тут имеет смысл как минимум попытаться штатно > завершить рабочие процессы. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Tue Mar 26 12:08:18 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 26 Mar 2013 16:08:18 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBuZ2lueC93aW4zMg==?= In-Reply-To: References: <20130326112719.GM62550@mdounin.ru> Message-ID: <20130326120818.GN62550@mdounin.ru> Hello! On Tue, Mar 26, 2013 at 05:43:21PM +0600, Илья Шипицин wrote: > давайте разбираться. если запускать nginx в консоли (это штатный режим, так > работают назначенные задания), то завершение задания с точки зрения > мастер-процесса выглядит, как CTRL_CLOSE_EVENT в функции-обработчике > ngx_console_handler > > worker-процесс в это время залипает в функции ngx_worker_process_cycle в > цикле "ev=WaitForMultipleObjects()" > > соответственно, закрытие мастера путем закрывания не приводит к тому, что в > данном месте возникает какое-то событие. То, что это плохо - вопросов не вызывает. По Ctrl-C всё должно штатно закрываться, а не висеть вечно. > варианты - либо существенно переделывать логику и протаскивать сюда еще > одно событие, либо жестко закрыть worker через > ngx_terminate_worker_processes. > > чем чреват второй вариант ? ну ок, закроются текущие сессии. завершая > задание, мы, вероятно, этого и добиваемся. Например, могут остаться полусохранённые файлы в кеше/proxy_store - если рабочий процесс прервали в процессе копирования временного файла в целевой каталог. (Документация по TerminateProcess() и различные code checker'ы любят пугать про "the state of global data maintained by dynamic-link libraries (DLLs) may be compromised". Но это, насколько я понимаю, в данном случае к nginx'у неприменимо - по крайней мере, в отсутствии сторонних модулей.) > > > 26 марта 2013 г., 17:27 пользователь Maxim Dounin написал: > > > Hello! > > > > On Tue, Mar 26, 2013 at 05:03:30PM +0600, Илья Шипицин wrote: > > > > > Добрый день! > > > > > > мы достаточно плотно используем nginx для Windows, запускаем его через > > > назначенное задание (scheduled tasks). Для этого в конфиге надо сделать > > > "daemon off" и дальше менеджер заданий следит за мастер-процессом, > > > запущенным на терминале. > > > > > > это, кстати, удобнее, чем служба Windows (вообще, назначенные задания > > более > > > удобны и мы чаще используем их, чем службы). > > > > > > в этом сценарии есть один недостаток, при завершении мастер-процесса, > > > остается запущенный worker-процесс. > > > > > > насколько я понял, в случае Windows это штатная ситуация (при такой > > работе > > > с процессами, которая используется в nginx), для исправления предлагаю > > > такой патч (сделан для 1.3.14): > > > > > > --- src/os/win32/ngx_process_cycle.c 2013-03-26 16:57:20.000000000 > > +0600 > > > +++ src/os/win32/ngx_process_cycle.c.new 2013-03-26 > > > 16:57:00.987341331 +0600 > > > @@ -303,6 +303,8 @@ > > > ngx_console_handler(u_long type) > > > { > > > char *msg; > > > + ngx_cycle_t *cycle; > > > + cycle = (ngx_cycle_t *) ngx_cycle; > > > > > > switch (type) { > > > > > > @@ -316,6 +318,7 @@ > > > > > > case CTRL_CLOSE_EVENT: > > > msg = "console closing, exiting"; > > > + ngx_terminate_worker_processes(cycle); > > > break; > > > > > > case CTRL_LOGOFF_EVENT: > > > > Звать ngx_terminate_worker_processes() - это не очень хорошая > > идея, это всё-таки аварийный механизм, и может приводить к > > нехорошему. Тут имеет смысл как минимум попытаться штатно > > завершить рабочие процессы. > > > > -- > > Maxim Dounin > > http://nginx.org/en/donation.html > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://nginx.org/en/donation.html From chipitsine at gmail.com Tue Mar 26 12:23:23 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 26 Mar 2013 18:23:23 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBuZ2lueC93aW4zMg==?= In-Reply-To: <20130326120818.GN62550@mdounin.ru> References: <20130326112719.GM62550@mdounin.ru> <20130326120818.GN62550@mdounin.ru> Message-ID: по Ctrl-C воркеры закрываются. в назначенных заданиях, насколько я понял, не отправляется Ctrl-C, а закрывается stdin. ок, замечания понятны. поправлю. 26 марта 2013 г., 18:08 пользователь Maxim Dounin написал: > Hello! > > On Tue, Mar 26, 2013 at 05:43:21PM +0600, Илья Шипицин wrote: > > > давайте разбираться. если запускать nginx в консоли (это штатный режим, > так > > работают назначенные задания), то завершение задания с точки зрения > > мастер-процесса выглядит, как CTRL_CLOSE_EVENT в функции-обработчике > > ngx_console_handler > > > > worker-процесс в это время залипает в функции ngx_worker_process_cycle в > > цикле "ev=WaitForMultipleObjects()" > > > > соответственно, закрытие мастера путем закрывания не приводит к тому, > что в > > данном месте возникает какое-то событие. > > То, что это плохо - вопросов не вызывает. По Ctrl-C всё должно > штатно закрываться, а не висеть вечно. > > > варианты - либо существенно переделывать логику и протаскивать сюда еще > > одно событие, либо жестко закрыть worker через > > ngx_terminate_worker_processes. > > > > чем чреват второй вариант ? ну ок, закроются текущие сессии. завершая > > задание, мы, вероятно, этого и добиваемся. > > Например, могут остаться полусохранённые файлы в кеше/proxy_store - > если рабочий процесс прервали в процессе копирования временного > файла в целевой каталог. > > (Документация по TerminateProcess() и различные code > checker'ы любят пугать про "the state of global data maintained > by dynamic-link libraries (DLLs) may be compromised". Но это, > насколько я понимаю, в данном случае к nginx'у неприменимо - по > крайней мере, в отсутствии сторонних модулей.) > > > > > > > 26 марта 2013 г., 17:27 пользователь Maxim Dounin >написал: > > > > > Hello! > > > > > > On Tue, Mar 26, 2013 at 05:03:30PM +0600, Илья Шипицин wrote: > > > > > > > Добрый день! > > > > > > > > мы достаточно плотно используем nginx для Windows, запускаем его > через > > > > назначенное задание (scheduled tasks). Для этого в конфиге надо > сделать > > > > "daemon off" и дальше менеджер заданий следит за мастер-процессом, > > > > запущенным на терминале. > > > > > > > > это, кстати, удобнее, чем служба Windows (вообще, назначенные задания > > > более > > > > удобны и мы чаще используем их, чем службы). > > > > > > > > в этом сценарии есть один недостаток, при завершении мастер-процесса, > > > > остается запущенный worker-процесс. > > > > > > > > насколько я понял, в случае Windows это штатная ситуация (при такой > > > работе > > > > с процессами, которая используется в nginx), для исправления > предлагаю > > > > такой патч (сделан для 1.3.14): > > > > > > > > --- src/os/win32/ngx_process_cycle.c 2013-03-26 16:57:20.000000000 > > > +0600 > > > > +++ src/os/win32/ngx_process_cycle.c.new 2013-03-26 > > > > 16:57:00.987341331 +0600 > > > > @@ -303,6 +303,8 @@ > > > > ngx_console_handler(u_long type) > > > > { > > > > char *msg; > > > > + ngx_cycle_t *cycle; > > > > + cycle = (ngx_cycle_t *) ngx_cycle; > > > > > > > > switch (type) { > > > > > > > > @@ -316,6 +318,7 @@ > > > > > > > > case CTRL_CLOSE_EVENT: > > > > msg = "console closing, exiting"; > > > > + ngx_terminate_worker_processes(cycle); > > > > break; > > > > > > > > case CTRL_LOGOFF_EVENT: > > > > > > Звать ngx_terminate_worker_processes() - это не очень хорошая > > > идея, это всё-таки аварийный механизм, и может приводить к > > > нехорошему. Тут имеет смысл как минимум попытаться штатно > > > завершить рабочие процессы. > > > > > > -- > > > Maxim Dounin > > > http://nginx.org/en/donation.html > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue Mar 26 12:23:52 2013 From: nginx-forum at nginx.us (somebi) Date: Tue, 26 Mar 2013 08:23:52 -0400 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0L3QsNGH0LDQu9CwINCy0L7RgdC/0YDQvtC4?= =?UTF-8?B?0LfQstC10LTQtdC90LjRjyDQstC40LTQtdC+INCyINC80L7QtNGD0LvQtSBt?= =?UTF-8?B?cDQ=?= In-Reply-To: <145792caba7a2c22841524e04d6f9769.NginxMailingListRussian@forum.nginx.org> References: <04AB5542-CFEB-457F-87D1-FB3744CBFA8A@gmail.com> <145792caba7a2c22841524e04d6f9769.NginxMailingListRussian@forum.nginx.org> Message-ID: Вчера скачал программу Atom Box Studio и выдрал метаданные из фильма размером 718mb, мета данные оказались размером в 92 мегабайта!!! Залили этот файл на дропбокс, вот ссылка: Основную часть файла описываются некие Chunk Offset такого вида: ( 41279) Chunk Offset : 0x0519DF46 ( 41280) Chunk Offset : 0x0519E738 ( 41281) Chunk Offset : 0x0519E9F0 ( 41282) Chunk Offset : 0x0519EB5E ( 41283) Chunk Offset : 0x0519EE4C и Sample Size такого: ( 315536) Sample Size : 344 ( 315537) Sample Size : 344 ( 315538) Sample Size : 345 ( 315539) Sample Size : 338 Из-за чего их там так много? Файл конвертировал с помощью avconv от libav v9.4 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237744,237796#msg-237796 From nginx-forum at nginx.us Tue Mar 26 12:26:41 2013 From: nginx-forum at nginx.us (somebi) Date: Tue, 26 Mar 2013 08:26:41 -0400 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0L3QsNGH0LDQu9CwINCy0L7RgdC/0YDQvtC4?= =?UTF-8?B?0LfQstC10LTQtdC90LjRjyDQstC40LTQtdC+INCyINC80L7QtNGD0LvQtSBt?= =?UTF-8?B?cDQ=?= In-Reply-To: References: <04AB5542-CFEB-457F-87D1-FB3744CBFA8A@gmail.com> <145792caba7a2c22841524e04d6f9769.NginxMailingListRussian@forum.nginx.org> Message-ID: <79bb711720ea91737c074a4a69dfdf60.NginxMailingListRussian@forum.nginx.org> Упс, пардон. Вот ссылка на ведь файл https://www.dropbox.com/s/tok76wospngf854/moov Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237744,237798#msg-237798 From vas at mpeks.tomsk.su Tue Mar 26 13:23:51 2013 From: vas at mpeks.tomsk.su (Victor Sudakov) Date: Tue, 26 Mar 2013 20:23:51 +0700 Subject: nginx as TCP proxy Message-ID: <20130326132351.GA64530@admin.sibptus.tomsk.ru> Коллеги, Пытаюсь использовать nginx-devel-1.3.14 (из портов FreeBSD) как tcp load balancer. Почему-то тест конфига не проходит с сообщением: Performing sanity check on nginx configuration: nginx: [warn] upstream "test" may not have port 80 in /usr/local/etc/nginx/nginx.conf:34 nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed Что я делаю не так? Заранее спасибо. Полный конфиг приведён ниже. worker_processes 1; events { worker_connections 1024; } tcp { upstream test { # simple round-robin server localhost:783; server murka:783; check interval=3000 rise=2 fall=5 timeout=1000; } server { listen 7783; proxy_pass test ; } } -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov at sibptus.tomsk.ru From mdounin at mdounin.ru Tue Mar 26 13:30:07 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 26 Mar 2013 17:30:07 +0400 Subject: nginx-1.3.15 Message-ID: <20130326133007.GQ62550@mdounin.ru> Изменения в nginx 1.3.15 26.03.2013 *) Изменение: открытие и закрытие соединения без отправки в нём каких-либо данных больше не записывается в access_log с кодом ошибки 400. *) Добавление: модуль ngx_http_spdy_module. Спасибо Automattic за спонсирование разработки. *) Добавление: директивы limit_req_status и limit_conn_status. Спасибо Nick Marden. *) Добавление: директива image_filter_interlace. Спасибо Ивану Боброву. *) Добавление: переменная $connections_waiting в модуле ngx_http_stub_status_module. *) Добавление: теперь почтовый прокси-сервер поддерживает IPv6-бэкенды. *) Исправление: при повторной отправке запроса на бэкенд тело запроса могло передаваться неправильно; ошибка появилась в 1.3.9. Спасибо Piotr Sikora. *) Исправление: в директиве client_body_in_file_only; ошибка появилась в 1.3.9. *) Исправление: ответы могли зависать, если использовались подзапросы и при обработке подзапроса происходила DNS-ошибка. Спасибо Lanshun Zhou. *) Исправление: в процедуре учёта использования бэкендов. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Tue Mar 26 15:28:22 2013 From: nginx-forum at nginx.us (baltazor) Date: Tue, 26 Mar 2013 11:28:22 -0400 Subject: =?UTF-8?Q?nginx_=D0=B7=D0=B0_nginx?= Message-ID: <49beae5f51fcd91f2dc57511ee87f68f.NginxMailingListRussian@forum.nginx.org> Добрый день. Нужно сделать связку: Nginx + nginx + apache В первом nginx сделал proxy_pass http://ip:80 , сайт работает. Проблема заключается в том что второй nginx видит не мой IP , а IP первого сервера , но апач видит уже мой IP в X-Forwarded-For и X-Real-IP Конфиг на первом nginx: location / { proxy_pass http://ip:80/; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; } Конфиг на втором сервере такой же , кроме ip Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237807,237807#msg-237807 From alex.barut at gmail.com Tue Mar 26 15:33:58 2013 From: alex.barut at gmail.com (Alex Belyansky) Date: Tue, 26 Mar 2013 19:33:58 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LAgbmdpbng=?= In-Reply-To: <49beae5f51fcd91f2dc57511ee87f68f.NginxMailingListRussian@forum.nginx.org> References: <49beae5f51fcd91f2dc57511ee87f68f.NginxMailingListRussian@forum.nginx.org> Message-ID: <5151BFE6.8030309@gmail.com> On 26.03.2013 19:28, baltazor wrote: > Добрый день. Нужно сделать связку: > Nginx + nginx + apache > В первом nginx сделал proxy_pass http://ip:80 , сайт работает. > Проблема заключается в том что второй nginx видит не мой IP , а IP первого > сервера , но апач видит уже мой IP в X-Forwarded-For и X-Real-IP > > Конфиг на первом nginx: > > location / > { > proxy_pass http://ip:80/; > proxy_redirect off; > > proxy_set_header Host $host; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header X-Real-IP $remote_addr; > } > > Конфиг на втором сервере такой же , кроме ip > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237807,237807#msg-237807 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Ну в первом же случае вы установили уже хейдеры, зачем на втором сервере так же их устанавливать? Я думаю, что если уберете на втором сервере строчки: proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; то должно заработать как надо. From nginx-forum at nginx.us Tue Mar 26 15:45:57 2013 From: nginx-forum at nginx.us (baltazor) Date: Tue, 26 Mar 2013 11:45:57 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LAgbmdpbng=?= In-Reply-To: <5151BFE6.8030309@gmail.com> References: <5151BFE6.8030309@gmail.com> Message-ID: <283c97f8591b6ae7b195f8d1e05f34ae.NginxMailingListRussian@forum.nginx.org> Не заработало, т.е. на apache IP показывается тот что нужно , а вот на втором nginx IP в логах показывается сервера Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237807,237809#msg-237809 From sofiamay at mail.ru Tue Mar 26 15:59:20 2013 From: sofiamay at mail.ru (=?UTF-8?B?c2RmYXNkZiBhc2RmYXNkZg==?=) Date: Tue, 26 Mar 2013 19:59:20 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LAgbmdpbng=?= In-Reply-To: <49beae5f51fcd91f2dc57511ee87f68f.NginxMailingListRussian@forum.nginx.org> References: <49beae5f51fcd91f2dc57511ee87f68f.NginxMailingListRussian@forum.nginx.org> Message-ID: <1364313560.460105979@f265.mail.ru> на первом nginx proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $http_x_forwarded_for; на втором nginx proxy_set_header X-Real-IP $http_x_real_ip; proxy_set_header X-Forwarded-For $http_x_forwarded_for; в апаче (если 2,2) LoadModule rpaf_module modules/mod_rpaf.so RPAFenable On RPAFproxy_ips 127.0.0.1 ваши другие ip через пробел RPAFsethostname Off RPAFheader X-Real-IP в апаче (если 2,4) LoadModule remoteip_module modules/mod_remoteip.so RemoteIPHeader X-Real-IP Работает, проверено. Соблюдать строго по тексту, никаких других строк, как везде в интернете понаписано, не вставлять. Вторник, 26 марта 2013, 11:28 -04:00 от "baltazor" : >Добрый день. Нужно сделать связку: >Nginx + nginx + apache >В первом nginx сделал proxy_pass http://ip:80 , сайт работает. >Проблема заключается в том что второй nginx видит не мой IP , а IP первого >сервера , но апач видит уже мой IP в X-Forwarded-For и X-Real-IP > >Конфиг на первом nginx: > >        location / >{ >proxy_pass http://ip:80/; >proxy_redirect off; > >proxy_set_header Host $host; >            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >            proxy_set_header X-Real-IP $remote_addr; >} > >Конфиг на втором сервере такой же , кроме ip > >Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237807,237807#msg-237807 > >_______________________________________________ >nginx-ru mailing list >nginx-ru at nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Tue Mar 26 16:07:00 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 26 Mar 2013 20:07:00 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LAgbmdpbng=?= In-Reply-To: <283c97f8591b6ae7b195f8d1e05f34ae.NginxMailingListRussian@forum.nginx.org> References: <5151BFE6.8030309@gmail.com> <283c97f8591b6ae7b195f8d1e05f34ae.NginxMailingListRussian@forum.nginx.org> Message-ID: <201303262007.00562.vbart@nginx.com> On Tuesday 26 March 2013 19:45:57 baltazor wrote: > Не заработало, т.е. на apache IP показывается тот что нужно , а вот на > втором nginx IP в логах показывается сервера > А вы соответствующий модуль включили? http://nginx.org/ru/docs/http/ngx_http_realip_module.html -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Tue Mar 26 18:50:22 2013 From: nginx-forum at nginx.us (baltazor) Date: Tue, 26 Mar 2013 14:50:22 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LAgbmdpbng=?= In-Reply-To: <1364313560.460105979@f265.mail.ru> References: <1364313560.460105979@f265.mail.ru> Message-ID: Пробовал так, проблема в том что apache видит нужный IP адрес, а вот nginx второй видит IP не мой а IP первого nginx sofiamay Wrote: ------------------------------------------------------- > на первом nginx > > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $http_x_forwarded_for; > > на втором nginx > > proxy_set_header X-Real-IP $http_x_real_ip; > proxy_set_header X-Forwarded-For $http_x_forwarded_for; > > в апаче (если 2,2) > > LoadModule rpaf_module modules/mod_rpaf.so > RPAFenable On > RPAFproxy_ips 127.0.0.1 ваши другие ip через пробел > RPAFsethostname Off > RPAFheader X-Real-IP > > в апаче (если 2,4) > > LoadModule remoteip_module modules/mod_remoteip.so > RemoteIPHeader X-Real-IP > > Работает, проверено. Соблюдать строго по тексту, никаких других строк, > как везде в интернете понаписано, не вставлять. > > Вторник, 26 марта 2013, 11:28 -04:00 от "baltazor" > : > >Добрый день. Нужно сделать связку: > >Nginx + nginx + apache > >В первом nginx сделал proxy_pass http://ip:80 , сайт работает. > >Проблема заключается в том что второй nginx видит не мой IP , а IP > первого > >сервера , но апач видит уже мой IP в X-Forwarded-For и X-Real-IP > > > >Конфиг на первом nginx: > > > >        location / > >{ > >proxy_pass http://ip:80/; > >proxy_redirect off; > > > >proxy_set_header Host $host; > >            proxy_set_header X-Forwarded-For > $proxy_add_x_forwarded_for; > >            proxy_set_header X-Real-IP $remote_addr; > >} > > > >Конфиг на втором сервере такой же , кроме ip > > > >Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,237807,237807#msg-237807 > > > >_______________________________________________ > >nginx-ru mailing list > >nginx-ru at nginx.org > >http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237807,237817#msg-237817 From sofiamay at mail.ru Tue Mar 26 21:37:15 2013 From: sofiamay at mail.ru (=?UTF-8?B?c2RmYXNkZiBhc2RmYXNkZg==?=) Date: Wed, 27 Mar 2013 01:37:15 +0400 Subject: =?UTF-8?B?UmVbMl06IG5naW54INC30LAgbmdpbng=?= In-Reply-To: References: <1364313560.460105979@f265.mail.ru> Message-ID: <1364333835.28879451@f223.mail.ru> Прошу прощения, действительно, думал у вас c Apache проблема. Тогда вам уже дали совет выше: http://nginx.org/ru/docs/http/ngx_http_realip_module.html Вторник, 26 марта 2013, 14:50 -04:00 от "baltazor" : >Пробовал так, проблема в том что apache видит нужный IP адрес, а вот nginx >второй видит IP не мой а IP первого nginx > >sofiamay Wrote: >------------------------------------------------------- >> на первом nginx >> >> proxy_set_header X-Real-IP $remote_addr; >> proxy_set_header X-Forwarded-For $http_x_forwarded_for; >> >> на втором nginx >> >> proxy_set_header X-Real-IP $http_x_real_ip; >> proxy_set_header X-Forwarded-For $http_x_forwarded_for; >> >> в апаче (если 2,2) >> >> LoadModule rpaf_module modules/mod_rpaf.so >> RPAFenable On >> RPAFproxy_ips 127.0.0.1 ваши другие ip через пробел >> RPAFsethostname Off >> RPAFheader X-Real-IP >> >> в апаче (если 2,4) >> >> LoadModule remoteip_module modules/mod_remoteip.so >> RemoteIPHeader X-Real-IP >> >> Работает, проверено. Соблюдать строго по тексту, никаких других строк, >> как везде в интернете понаписано, не вставлять. >> >> Вторник, 26 марта 2013, 11:28 -04:00 от "baltazor" >> < nginx-forum at nginx.us >: >> >Добрый день. Нужно сделать связку: >> >Nginx + nginx + apache >> >В первом nginx сделал proxy_pass http://ip:80 , сайт работает. >> >Проблема заключается в том что второй nginx видит не мой IP , а IP >> первого >> >сервера , но апач видит уже мой IP в X-Forwarded-For и X-Real-IP >> > >> >Конфиг на первом nginx: >> > >> >        location / >> >{ >> >proxy_pass http://ip:80/; >> >proxy_redirect off; >> > >> >proxy_set_header Host $host; >> >            proxy_set_header X-Forwarded-For >> $proxy_add_x_forwarded_for; >> >            proxy_set_header X-Real-IP $remote_addr; >> >} >> > >> >Конфиг на втором сервере такой же , кроме ip >> > >> >Posted at Nginx Forum: >> http://forum.nginx.org/read.php?21,237807,237807#msg-237807 >> > >> >_______________________________________________ >> >nginx-ru mailing list >> >nginx-ru at nginx.org >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > >Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237807,237817#msg-237817 > >_______________________________________________ >nginx-ru mailing list >nginx-ru at nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine at gmail.com Wed Mar 27 03:58:07 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 27 Mar 2013 09:58:07 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBuZ2lueC93aW4zMg==?= In-Reply-To: <20130326120818.GN62550@mdounin.ru> References: <20130326112719.GM62550@mdounin.ru> <20130326120818.GN62550@mdounin.ru> Message-ID: вот такой вариант ? --- src/os/win32/ngx_process_cycle.c.orig 2013-03-27 09:53:48.000000000 +0600 +++ src/os/win32/ngx_process_cycle.c 2013-03-27 09:48:56.000000000 +0600 @@ -303,6 +303,8 @@ ngx_console_handler(u_long type) { char *msg; + ngx_cycle_t *cycle; + cycle = (ngx_cycle_t *) ngx_cycle; switch (type) { @@ -316,6 +318,8 @@ case CTRL_CLOSE_EVENT: msg = "console closing, exiting"; + ngx_quit = 1; + ngx_quit_worker_processes(cycle, 0); break; case CTRL_LOGOFF_EVENT: 26 марта 2013 г., 18:08 пользователь Maxim Dounin написал: > Hello! > > On Tue, Mar 26, 2013 at 05:43:21PM +0600, Илья Шипицин wrote: > > > давайте разбираться. если запускать nginx в консоли (это штатный режим, > так > > работают назначенные задания), то завершение задания с точки зрения > > мастер-процесса выглядит, как CTRL_CLOSE_EVENT в функции-обработчике > > ngx_console_handler > > > > worker-процесс в это время залипает в функции ngx_worker_process_cycle в > > цикле "ev=WaitForMultipleObjects()" > > > > соответственно, закрытие мастера путем закрывания не приводит к тому, > что в > > данном месте возникает какое-то событие. > > То, что это плохо - вопросов не вызывает. По Ctrl-C всё должно > штатно закрываться, а не висеть вечно. > > > варианты - либо существенно переделывать логику и протаскивать сюда еще > > одно событие, либо жестко закрыть worker через > > ngx_terminate_worker_processes. > > > > чем чреват второй вариант ? ну ок, закроются текущие сессии. завершая > > задание, мы, вероятно, этого и добиваемся. > > Например, могут остаться полусохранённые файлы в кеше/proxy_store - > если рабочий процесс прервали в процессе копирования временного > файла в целевой каталог. > > (Документация по TerminateProcess() и различные code > checker'ы любят пугать про "the state of global data maintained > by dynamic-link libraries (DLLs) may be compromised". Но это, > насколько я понимаю, в данном случае к nginx'у неприменимо - по > крайней мере, в отсутствии сторонних модулей.) > > > > > > > 26 марта 2013 г., 17:27 пользователь Maxim Dounin >написал: > > > > > Hello! > > > > > > On Tue, Mar 26, 2013 at 05:03:30PM +0600, Илья Шипицин wrote: > > > > > > > Добрый день! > > > > > > > > мы достаточно плотно используем nginx для Windows, запускаем его > через > > > > назначенное задание (scheduled tasks). Для этого в конфиге надо > сделать > > > > "daemon off" и дальше менеджер заданий следит за мастер-процессом, > > > > запущенным на терминале. > > > > > > > > это, кстати, удобнее, чем служба Windows (вообще, назначенные задания > > > более > > > > удобны и мы чаще используем их, чем службы). > > > > > > > > в этом сценарии есть один недостаток, при завершении мастер-процесса, > > > > остается запущенный worker-процесс. > > > > > > > > насколько я понял, в случае Windows это штатная ситуация (при такой > > > работе > > > > с процессами, которая используется в nginx), для исправления > предлагаю > > > > такой патч (сделан для 1.3.14): > > > > > > > > --- src/os/win32/ngx_process_cycle.c 2013-03-26 16:57:20.000000000 > > > +0600 > > > > +++ src/os/win32/ngx_process_cycle.c.new 2013-03-26 > > > > 16:57:00.987341331 +0600 > > > > @@ -303,6 +303,8 @@ > > > > ngx_console_handler(u_long type) > > > > { > > > > char *msg; > > > > + ngx_cycle_t *cycle; > > > > + cycle = (ngx_cycle_t *) ngx_cycle; > > > > > > > > switch (type) { > > > > > > > > @@ -316,6 +318,7 @@ > > > > > > > > case CTRL_CLOSE_EVENT: > > > > msg = "console closing, exiting"; > > > > + ngx_terminate_worker_processes(cycle); > > > > break; > > > > > > > > case CTRL_LOGOFF_EVENT: > > > > > > Звать ngx_terminate_worker_processes() - это не очень хорошая > > > идея, это всё-таки аварийный механизм, и может приводить к > > > нехорошему. Тут имеет смысл как минимум попытаться штатно > > > завершить рабочие процессы. > > > > > > -- > > > Maxim Dounin > > > http://nginx.org/en/donation.html > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ru at nginx.com Wed Mar 27 09:07:16 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Wed, 27 Mar 2013 13:07:16 +0400 Subject: nginx as TCP proxy In-Reply-To: <20130326132351.GA64530@admin.sibptus.tomsk.ru> References: <20130326132351.GA64530@admin.sibptus.tomsk.ru> Message-ID: <20130327090716.GE89105@lo0.su> On Tue, Mar 26, 2013 at 08:23:51PM +0700, Victor Sudakov wrote: > Коллеги, > > Пытаюсь использовать nginx-devel-1.3.14 (из портов FreeBSD) как tcp load > balancer. Почему-то тест конфига не проходит с сообщением: > > Performing sanity check on nginx configuration: > nginx: [warn] upstream "test" may not have port 80 in /usr/local/etc/nginx/nginx.conf:34 > nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed > > Что я делаю не так? Заранее спасибо. Полный конфиг приведён ниже. > > > worker_processes 1; > > events { > worker_connections 1024; > } > > tcp { > upstream test { > # simple round-robin > server localhost:783; > server murka:783; > check interval=3000 rise=2 fall=5 timeout=1000; > } > > server { > listen 7783; > proxy_pass test ; > } > } tcp_proxy - это сторонний модуль. В -devel иногда случаются API-несовместимые изменения, это было одно из них: http://trac.nginx.org/nginx/changeset/5006/nginx. Автор модуля отреагировал спустя всего лишь три дня после выхода nginx 1.3.11 с этим изменением: https://github.com/yaoweibin/nginx_tcp_proxy_module/commit/f1d5c627fc3a25c3fd36c0850ffb40470bee9d90 Однако, порт FreeBSD использует версию 0.26 этого модуля, которой уже 10 месяцев: https://github.com/yaoweibin/nginx_tcp_proxy_module/tags Правильная последовательность действий видимо такая: - попросить автора модуля (Weibin Yao ) выпустить новую версию модуля; - попросить ответственного за порт www/nginx-devel обновить порт. From nginx-forum at nginx.us Wed Mar 27 10:09:54 2013 From: nginx-forum at nginx.us (ciklop) Date: Wed, 27 Mar 2013 06:09:54 -0400 Subject: =?UTF-8?B?UmU6IFRyYW5zZmVyLUVuY29kaW5nOiBjaHVua2VkINC00LvRjyDRgdGC0LDRgtC4?= =?UTF-8?B?0YfQtdGB0LrQuNGFINGE0LDQudC70L7Qsg==?= In-Reply-To: <201303251415.16042.vbart@nginx.com> References: <201303251415.16042.vbart@nginx.com> Message-ID: >Некий Бен скорее всего неправ, и streaming_callback работает вне зависимости >от chunked transfer encoding. Во всяком случае, никаких явных указаний на >обратное я не нашел. И было очень бы странно, если бы он это требовал. Тут есть такой нюанс - tornado может использовать simple_httpclient и curl_httpclient Вот как раз simple_httpclient явно ожидает Transfer-Encoding: chunked. Без него streaming_callback работать не будет. А вот curl_httpclient этот заголовок для этого случае не волнует, и с ним всё прекрасно работает. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237736,237824#msg-237824 From mdounin at mdounin.ru Wed Mar 27 12:20:34 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 27 Mar 2013 16:20:34 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBuZ2lueC93aW4zMg==?= In-Reply-To: References: <20130326112719.GM62550@mdounin.ru> <20130326120818.GN62550@mdounin.ru> Message-ID: <20130327122034.GY62550@mdounin.ru> Hello! On Wed, Mar 27, 2013 at 09:58:07AM +0600, Илья Шипицин wrote: > вот такой вариант ? > > --- src/os/win32/ngx_process_cycle.c.orig 2013-03-27 > 09:53:48.000000000 +0600 > +++ src/os/win32/ngx_process_cycle.c 2013-03-27 09:48:56.000000000 +0600 > @@ -303,6 +303,8 @@ > ngx_console_handler(u_long type) > { > char *msg; > + ngx_cycle_t *cycle; > + cycle = (ngx_cycle_t *) ngx_cycle; > > switch (type) { > > @@ -316,6 +318,8 @@ > > case CTRL_CLOSE_EVENT: > msg = "console closing, exiting"; > + ngx_quit = 1; > + ngx_quit_worker_processes(cycle, 0); > break; > > case CTRL_LOGOFF_EVENT: Я пересморел этот код ещё раз, перечитал соответствующую виндовую документацию, и склонен думать, что: 1) Патч, меняющий обработку только в случае CTRL_CLOSE_EVENT - заведомое неправильный, т.к. все случаи с точки зрения системы и nginx'а - равнозначны. (Прозвучавшее тут утверждение, что по Ctrl-C воркеры закрываются - видимо основано на наблюдениях за отдельными случаями, когда везло. Текущее поведение - содержит в себе race, см. ниже, и может иногда работать правильно.) 2) Текущая обработка - правильная, за одним небольшим упущением: нужно дожидаться завершения процесса до собственно возврата из ngx_console_handler(), потому что после возврата - процесс завершат, и сделанная нами попытка запустить процедуру штатной остановки - скорее всего пропадёт впустую. Что, собственно, и происходит. IMHO, правильным решением будет добавить ожидание перед возвратом из ngx_console_handler(). В качетсве грубого хака - можно попробовать воткнуть туда банальный ngx_msleep(1000), должно помочь. > > > > > > > 26 марта 2013 г., 18:08 пользователь Maxim Dounin написал: > > > Hello! > > > > On Tue, Mar 26, 2013 at 05:43:21PM +0600, Илья Шипицин wrote: > > > > > давайте разбираться. если запускать nginx в консоли (это штатный режим, > > так > > > работают назначенные задания), то завершение задания с точки зрения > > > мастер-процесса выглядит, как CTRL_CLOSE_EVENT в функции-обработчике > > > ngx_console_handler > > > > > > worker-процесс в это время залипает в функции ngx_worker_process_cycle в > > > цикле "ev=WaitForMultipleObjects()" > > > > > > соответственно, закрытие мастера путем закрывания не приводит к тому, > > что в > > > данном месте возникает какое-то событие. > > > > То, что это плохо - вопросов не вызывает. По Ctrl-C всё должно > > штатно закрываться, а не висеть вечно. > > > > > варианты - либо существенно переделывать логику и протаскивать сюда еще > > > одно событие, либо жестко закрыть worker через > > > ngx_terminate_worker_processes. > > > > > > чем чреват второй вариант ? ну ок, закроются текущие сессии. завершая > > > задание, мы, вероятно, этого и добиваемся. > > > > Например, могут остаться полусохранённые файлы в кеше/proxy_store - > > если рабочий процесс прервали в процессе копирования временного > > файла в целевой каталог. > > > > (Документация по TerminateProcess() и различные code > > checker'ы любят пугать про "the state of global data maintained > > by dynamic-link libraries (DLLs) may be compromised". Но это, > > насколько я понимаю, в данном случае к nginx'у неприменимо - по > > крайней мере, в отсутствии сторонних модулей.) > > > > > > > > > > > 26 марта 2013 г., 17:27 пользователь Maxim Dounin > >написал: > > > > > > > Hello! > > > > > > > > On Tue, Mar 26, 2013 at 05:03:30PM +0600, Илья Шипицин wrote: > > > > > > > > > Добрый день! > > > > > > > > > > мы достаточно плотно используем nginx для Windows, запускаем его > > через > > > > > назначенное задание (scheduled tasks). Для этого в конфиге надо > > сделать > > > > > "daemon off" и дальше менеджер заданий следит за мастер-процессом, > > > > > запущенным на терминале. > > > > > > > > > > это, кстати, удобнее, чем служба Windows (вообще, назначенные задания > > > > более > > > > > удобны и мы чаще используем их, чем службы). > > > > > > > > > > в этом сценарии есть один недостаток, при завершении мастер-процесса, > > > > > остается запущенный worker-процесс. > > > > > > > > > > насколько я понял, в случае Windows это штатная ситуация (при такой > > > > работе > > > > > с процессами, которая используется в nginx), для исправления > > предлагаю > > > > > такой патч (сделан для 1.3.14): > > > > > > > > > > --- src/os/win32/ngx_process_cycle.c 2013-03-26 16:57:20.000000000 > > > > +0600 > > > > > +++ src/os/win32/ngx_process_cycle.c.new 2013-03-26 > > > > > 16:57:00.987341331 +0600 > > > > > @@ -303,6 +303,8 @@ > > > > > ngx_console_handler(u_long type) > > > > > { > > > > > char *msg; > > > > > + ngx_cycle_t *cycle; > > > > > + cycle = (ngx_cycle_t *) ngx_cycle; > > > > > > > > > > switch (type) { > > > > > > > > > > @@ -316,6 +318,7 @@ > > > > > > > > > > case CTRL_CLOSE_EVENT: > > > > > msg = "console closing, exiting"; > > > > > + ngx_terminate_worker_processes(cycle); > > > > > break; > > > > > > > > > > case CTRL_LOGOFF_EVENT: > > > > > > > > Звать ngx_terminate_worker_processes() - это не очень хорошая > > > > идея, это всё-таки аварийный механизм, и может приводить к > > > > нехорошему. Тут имеет смысл как минимум попытаться штатно > > > > завершить рабочие процессы. > > > > > > > > -- > > > > Maxim Dounin > > > > http://nginx.org/en/donation.html > > > > > > > > _______________________________________________ > > > > nginx-ru mailing list > > > > nginx-ru at nginx.org > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > -- > > Maxim Dounin > > http://nginx.org/en/donation.html > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://nginx.org/en/donation.html From chipitsine at gmail.com Wed Mar 27 12:25:17 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 27 Mar 2013 18:25:17 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBuZ2lueC93aW4zMg==?= In-Reply-To: <20130327122034.GY62550@mdounin.ru> References: <20130326112719.GM62550@mdounin.ru> <20130326120818.GN62550@mdounin.ru> <20130327122034.GY62550@mdounin.ru> Message-ID: если банальный ngx_msleep(1000) действительно решит проблемы - мне непринципиально, пусть будет так. поправите код ? 27 марта 2013 г., 18:20 пользователь Maxim Dounin написал: > Hello! > > On Wed, Mar 27, 2013 at 09:58:07AM +0600, Илья Шипицин wrote: > > > вот такой вариант ? > > > > --- src/os/win32/ngx_process_cycle.c.orig 2013-03-27 > > 09:53:48.000000000 +0600 > > +++ src/os/win32/ngx_process_cycle.c 2013-03-27 09:48:56.000000000 > +0600 > > @@ -303,6 +303,8 @@ > > ngx_console_handler(u_long type) > > { > > char *msg; > > + ngx_cycle_t *cycle; > > + cycle = (ngx_cycle_t *) ngx_cycle; > > > > switch (type) { > > > > @@ -316,6 +318,8 @@ > > > > case CTRL_CLOSE_EVENT: > > msg = "console closing, exiting"; > > + ngx_quit = 1; > > + ngx_quit_worker_processes(cycle, 0); > > break; > > > > case CTRL_LOGOFF_EVENT: > > Я пересморел этот код ещё раз, перечитал соответствующую виндовую > документацию, и склонен думать, что: > > 1) Патч, меняющий обработку только в случае CTRL_CLOSE_EVENT - > заведомое неправильный, т.к. все случаи с точки зрения системы и > nginx'а - равнозначны. (Прозвучавшее тут утверждение, что по > Ctrl-C воркеры закрываются - видимо основано на наблюдениях за > отдельными случаями, когда везло. Текущее поведение - содержит в > себе race, см. ниже, и может иногда работать правильно.) > > 2) Текущая обработка - правильная, за одним небольшим упущением: > нужно дожидаться завершения процесса до собственно возврата из > ngx_console_handler(), потому что после возврата - процесс > завершат, и сделанная нами попытка запустить процедуру штатной > остановки - скорее всего пропадёт впустую. Что, собственно, и > происходит. > > IMHO, правильным решением будет добавить ожидание перед возвратом > из ngx_console_handler(). В качетсве грубого хака - можно > попробовать воткнуть туда банальный ngx_msleep(1000), должно > помочь. > > > > > > > > > > > > > > > 26 марта 2013 г., 18:08 пользователь Maxim Dounin >написал: > > > > > Hello! > > > > > > On Tue, Mar 26, 2013 at 05:43:21PM +0600, Илья Шипицин wrote: > > > > > > > давайте разбираться. если запускать nginx в консоли (это штатный > режим, > > > так > > > > работают назначенные задания), то завершение задания с точки зрения > > > > мастер-процесса выглядит, как CTRL_CLOSE_EVENT в функции-обработчике > > > > ngx_console_handler > > > > > > > > worker-процесс в это время залипает в функции > ngx_worker_process_cycle в > > > > цикле "ev=WaitForMultipleObjects()" > > > > > > > > соответственно, закрытие мастера путем закрывания не приводит к тому, > > > что в > > > > данном месте возникает какое-то событие. > > > > > > То, что это плохо - вопросов не вызывает. По Ctrl-C всё должно > > > штатно закрываться, а не висеть вечно. > > > > > > > варианты - либо существенно переделывать логику и протаскивать сюда > еще > > > > одно событие, либо жестко закрыть worker через > > > > ngx_terminate_worker_processes. > > > > > > > > чем чреват второй вариант ? ну ок, закроются текущие сессии. завершая > > > > задание, мы, вероятно, этого и добиваемся. > > > > > > Например, могут остаться полусохранённые файлы в кеше/proxy_store - > > > если рабочий процесс прервали в процессе копирования временного > > > файла в целевой каталог. > > > > > > (Документация по TerminateProcess() и различные code > > > checker'ы любят пугать про "the state of global data maintained > > > by dynamic-link libraries (DLLs) may be compromised". Но это, > > > насколько я понимаю, в данном случае к nginx'у неприменимо - по > > > крайней мере, в отсутствии сторонних модулей.) > > > > > > > > > > > > > > > 26 марта 2013 г., 17:27 пользователь Maxim Dounin < > mdounin at mdounin.ru > > > >написал: > > > > > > > > > Hello! > > > > > > > > > > On Tue, Mar 26, 2013 at 05:03:30PM +0600, Илья Шипицин wrote: > > > > > > > > > > > Добрый день! > > > > > > > > > > > > мы достаточно плотно используем nginx для Windows, запускаем его > > > через > > > > > > назначенное задание (scheduled tasks). Для этого в конфиге надо > > > сделать > > > > > > "daemon off" и дальше менеджер заданий следит за > мастер-процессом, > > > > > > запущенным на терминале. > > > > > > > > > > > > это, кстати, удобнее, чем служба Windows (вообще, назначенные > задания > > > > > более > > > > > > удобны и мы чаще используем их, чем службы). > > > > > > > > > > > > в этом сценарии есть один недостаток, при завершении > мастер-процесса, > > > > > > остается запущенный worker-процесс. > > > > > > > > > > > > насколько я понял, в случае Windows это штатная ситуация (при > такой > > > > > работе > > > > > > с процессами, которая используется в nginx), для исправления > > > предлагаю > > > > > > такой патч (сделан для 1.3.14): > > > > > > > > > > > > --- src/os/win32/ngx_process_cycle.c 2013-03-26 > 16:57:20.000000000 > > > > > +0600 > > > > > > +++ src/os/win32/ngx_process_cycle.c.new 2013-03-26 > > > > > > 16:57:00.987341331 +0600 > > > > > > @@ -303,6 +303,8 @@ > > > > > > ngx_console_handler(u_long type) > > > > > > { > > > > > > char *msg; > > > > > > + ngx_cycle_t *cycle; > > > > > > + cycle = (ngx_cycle_t *) ngx_cycle; > > > > > > > > > > > > switch (type) { > > > > > > > > > > > > @@ -316,6 +318,7 @@ > > > > > > > > > > > > case CTRL_CLOSE_EVENT: > > > > > > msg = "console closing, exiting"; > > > > > > + ngx_terminate_worker_processes(cycle); > > > > > > break; > > > > > > > > > > > > case CTRL_LOGOFF_EVENT: > > > > > > > > > > Звать ngx_terminate_worker_processes() - это не очень хорошая > > > > > идея, это всё-таки аварийный механизм, и может приводить к > > > > > нехорошему. Тут имеет смысл как минимум попытаться штатно > > > > > завершить рабочие процессы. > > > > > > > > > > -- > > > > > Maxim Dounin > > > > > http://nginx.org/en/donation.html > > > > > > > > > > _______________________________________________ > > > > > nginx-ru mailing list > > > > > nginx-ru at nginx.org > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > _______________________________________________ > > > > nginx-ru mailing list > > > > nginx-ru at nginx.org > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > -- > > > Maxim Dounin > > > http://nginx.org/en/donation.html > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine at gmail.com Wed Mar 27 12:26:33 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 27 Mar 2013 18:26:33 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBuZ2lueC93aW4zMg==?= In-Reply-To: <20130327122034.GY62550@mdounin.ru> References: <20130326112719.GM62550@mdounin.ru> <20130326120818.GN62550@mdounin.ru> <20130327122034.GY62550@mdounin.ru> Message-ID: "потому что после возврата - процесс завершат" - что вы имеете в виду ? 27 марта 2013 г., 18:20 пользователь Maxim Dounin написал: > Hello! > > On Wed, Mar 27, 2013 at 09:58:07AM +0600, Илья Шипицин wrote: > > > вот такой вариант ? > > > > --- src/os/win32/ngx_process_cycle.c.orig 2013-03-27 > > 09:53:48.000000000 +0600 > > +++ src/os/win32/ngx_process_cycle.c 2013-03-27 09:48:56.000000000 > +0600 > > @@ -303,6 +303,8 @@ > > ngx_console_handler(u_long type) > > { > > char *msg; > > + ngx_cycle_t *cycle; > > + cycle = (ngx_cycle_t *) ngx_cycle; > > > > switch (type) { > > > > @@ -316,6 +318,8 @@ > > > > case CTRL_CLOSE_EVENT: > > msg = "console closing, exiting"; > > + ngx_quit = 1; > > + ngx_quit_worker_processes(cycle, 0); > > break; > > > > case CTRL_LOGOFF_EVENT: > > Я пересморел этот код ещё раз, перечитал соответствующую виндовую > документацию, и склонен думать, что: > > 1) Патч, меняющий обработку только в случае CTRL_CLOSE_EVENT - > заведомое неправильный, т.к. все случаи с точки зрения системы и > nginx'а - равнозначны. (Прозвучавшее тут утверждение, что по > Ctrl-C воркеры закрываются - видимо основано на наблюдениях за > отдельными случаями, когда везло. Текущее поведение - содержит в > себе race, см. ниже, и может иногда работать правильно.) > > 2) Текущая обработка - правильная, за одним небольшим упущением: > нужно дожидаться завершения процесса до собственно возврата из > ngx_console_handler(), потому что после возврата - процесс > завершат, и сделанная нами попытка запустить процедуру штатной > остановки - скорее всего пропадёт впустую. Что, собственно, и > происходит. > > IMHO, правильным решением будет добавить ожидание перед возвратом > из ngx_console_handler(). В качетсве грубого хака - можно > попробовать воткнуть туда банальный ngx_msleep(1000), должно > помочь. > > > > > > > > > > > > > > > 26 марта 2013 г., 18:08 пользователь Maxim Dounin >написал: > > > > > Hello! > > > > > > On Tue, Mar 26, 2013 at 05:43:21PM +0600, Илья Шипицин wrote: > > > > > > > давайте разбираться. если запускать nginx в консоли (это штатный > режим, > > > так > > > > работают назначенные задания), то завершение задания с точки зрения > > > > мастер-процесса выглядит, как CTRL_CLOSE_EVENT в функции-обработчике > > > > ngx_console_handler > > > > > > > > worker-процесс в это время залипает в функции > ngx_worker_process_cycle в > > > > цикле "ev=WaitForMultipleObjects()" > > > > > > > > соответственно, закрытие мастера путем закрывания не приводит к тому, > > > что в > > > > данном месте возникает какое-то событие. > > > > > > То, что это плохо - вопросов не вызывает. По Ctrl-C всё должно > > > штатно закрываться, а не висеть вечно. > > > > > > > варианты - либо существенно переделывать логику и протаскивать сюда > еще > > > > одно событие, либо жестко закрыть worker через > > > > ngx_terminate_worker_processes. > > > > > > > > чем чреват второй вариант ? ну ок, закроются текущие сессии. завершая > > > > задание, мы, вероятно, этого и добиваемся. > > > > > > Например, могут остаться полусохранённые файлы в кеше/proxy_store - > > > если рабочий процесс прервали в процессе копирования временного > > > файла в целевой каталог. > > > > > > (Документация по TerminateProcess() и различные code > > > checker'ы любят пугать про "the state of global data maintained > > > by dynamic-link libraries (DLLs) may be compromised". Но это, > > > насколько я понимаю, в данном случае к nginx'у неприменимо - по > > > крайней мере, в отсутствии сторонних модулей.) > > > > > > > > > > > > > > > 26 марта 2013 г., 17:27 пользователь Maxim Dounin < > mdounin at mdounin.ru > > > >написал: > > > > > > > > > Hello! > > > > > > > > > > On Tue, Mar 26, 2013 at 05:03:30PM +0600, Илья Шипицин wrote: > > > > > > > > > > > Добрый день! > > > > > > > > > > > > мы достаточно плотно используем nginx для Windows, запускаем его > > > через > > > > > > назначенное задание (scheduled tasks). Для этого в конфиге надо > > > сделать > > > > > > "daemon off" и дальше менеджер заданий следит за > мастер-процессом, > > > > > > запущенным на терминале. > > > > > > > > > > > > это, кстати, удобнее, чем служба Windows (вообще, назначенные > задания > > > > > более > > > > > > удобны и мы чаще используем их, чем службы). > > > > > > > > > > > > в этом сценарии есть один недостаток, при завершении > мастер-процесса, > > > > > > остается запущенный worker-процесс. > > > > > > > > > > > > насколько я понял, в случае Windows это штатная ситуация (при > такой > > > > > работе > > > > > > с процессами, которая используется в nginx), для исправления > > > предлагаю > > > > > > такой патч (сделан для 1.3.14): > > > > > > > > > > > > --- src/os/win32/ngx_process_cycle.c 2013-03-26 > 16:57:20.000000000 > > > > > +0600 > > > > > > +++ src/os/win32/ngx_process_cycle.c.new 2013-03-26 > > > > > > 16:57:00.987341331 +0600 > > > > > > @@ -303,6 +303,8 @@ > > > > > > ngx_console_handler(u_long type) > > > > > > { > > > > > > char *msg; > > > > > > + ngx_cycle_t *cycle; > > > > > > + cycle = (ngx_cycle_t *) ngx_cycle; > > > > > > > > > > > > switch (type) { > > > > > > > > > > > > @@ -316,6 +318,7 @@ > > > > > > > > > > > > case CTRL_CLOSE_EVENT: > > > > > > msg = "console closing, exiting"; > > > > > > + ngx_terminate_worker_processes(cycle); > > > > > > break; > > > > > > > > > > > > case CTRL_LOGOFF_EVENT: > > > > > > > > > > Звать ngx_terminate_worker_processes() - это не очень хорошая > > > > > идея, это всё-таки аварийный механизм, и может приводить к > > > > > нехорошему. Тут имеет смысл как минимум попытаться штатно > > > > > завершить рабочие процессы. > > > > > > > > > > -- > > > > > Maxim Dounin > > > > > http://nginx.org/en/donation.html > > > > > > > > > > _______________________________________________ > > > > > nginx-ru mailing list > > > > > nginx-ru at nginx.org > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > _______________________________________________ > > > > nginx-ru mailing list > > > > nginx-ru at nginx.org > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > -- > > > Maxim Dounin > > > http://nginx.org/en/donation.html > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine at gmail.com Wed Mar 27 12:57:05 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 27 Mar 2013 18:57:05 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBuZ2lueC93aW4zMg==?= In-Reply-To: <20130327122034.GY62550@mdounin.ru> References: <20130326112719.GM62550@mdounin.ru> <20130326120818.GN62550@mdounin.ru> <20130327122034.GY62550@mdounin.ru> Message-ID: я проверил банальный ngx_msleep(1000) - он не помогает. вот тут http://msdn.microsoft.com/ru-RU/library/windows/desktop/ms686722%28v=vs.85%29.aspx написано " When the system is terminating a process, it does not terminate any child processes that the process has created." 27 марта 2013 г., 18:20 пользователь Maxim Dounin написал: > Hello! > > On Wed, Mar 27, 2013 at 09:58:07AM +0600, Илья Шипицин wrote: > > > вот такой вариант ? > > > > --- src/os/win32/ngx_process_cycle.c.orig 2013-03-27 > > 09:53:48.000000000 +0600 > > +++ src/os/win32/ngx_process_cycle.c 2013-03-27 09:48:56.000000000 > +0600 > > @@ -303,6 +303,8 @@ > > ngx_console_handler(u_long type) > > { > > char *msg; > > + ngx_cycle_t *cycle; > > + cycle = (ngx_cycle_t *) ngx_cycle; > > > > switch (type) { > > > > @@ -316,6 +318,8 @@ > > > > case CTRL_CLOSE_EVENT: > > msg = "console closing, exiting"; > > + ngx_quit = 1; > > + ngx_quit_worker_processes(cycle, 0); > > break; > > > > case CTRL_LOGOFF_EVENT: > > Я пересморел этот код ещё раз, перечитал соответствующую виндовую > документацию, и склонен думать, что: > > 1) Патч, меняющий обработку только в случае CTRL_CLOSE_EVENT - > заведомое неправильный, т.к. все случаи с точки зрения системы и > nginx'а - равнозначны. (Прозвучавшее тут утверждение, что по > Ctrl-C воркеры закрываются - видимо основано на наблюдениях за > отдельными случаями, когда везло. Текущее поведение - содержит в > себе race, см. ниже, и может иногда работать правильно.) > > 2) Текущая обработка - правильная, за одним небольшим упущением: > нужно дожидаться завершения процесса до собственно возврата из > ngx_console_handler(), потому что после возврата - процесс > завершат, и сделанная нами попытка запустить процедуру штатной > остановки - скорее всего пропадёт впустую. Что, собственно, и > происходит. > > IMHO, правильным решением будет добавить ожидание перед возвратом > из ngx_console_handler(). В качетсве грубого хака - можно > попробовать воткнуть туда банальный ngx_msleep(1000), должно > помочь. > > > > > > > > > > > > > > > 26 марта 2013 г., 18:08 пользователь Maxim Dounin >написал: > > > > > Hello! > > > > > > On Tue, Mar 26, 2013 at 05:43:21PM +0600, Илья Шипицин wrote: > > > > > > > давайте разбираться. если запускать nginx в консоли (это штатный > режим, > > > так > > > > работают назначенные задания), то завершение задания с точки зрения > > > > мастер-процесса выглядит, как CTRL_CLOSE_EVENT в функции-обработчике > > > > ngx_console_handler > > > > > > > > worker-процесс в это время залипает в функции > ngx_worker_process_cycle в > > > > цикле "ev=WaitForMultipleObjects()" > > > > > > > > соответственно, закрытие мастера путем закрывания не приводит к тому, > > > что в > > > > данном месте возникает какое-то событие. > > > > > > То, что это плохо - вопросов не вызывает. По Ctrl-C всё должно > > > штатно закрываться, а не висеть вечно. > > > > > > > варианты - либо существенно переделывать логику и протаскивать сюда > еще > > > > одно событие, либо жестко закрыть worker через > > > > ngx_terminate_worker_processes. > > > > > > > > чем чреват второй вариант ? ну ок, закроются текущие сессии. завершая > > > > задание, мы, вероятно, этого и добиваемся. > > > > > > Например, могут остаться полусохранённые файлы в кеше/proxy_store - > > > если рабочий процесс прервали в процессе копирования временного > > > файла в целевой каталог. > > > > > > (Документация по TerminateProcess() и различные code > > > checker'ы любят пугать про "the state of global data maintained > > > by dynamic-link libraries (DLLs) may be compromised". Но это, > > > насколько я понимаю, в данном случае к nginx'у неприменимо - по > > > крайней мере, в отсутствии сторонних модулей.) > > > > > > > > > > > > > > > 26 марта 2013 г., 17:27 пользователь Maxim Dounin < > mdounin at mdounin.ru > > > >написал: > > > > > > > > > Hello! > > > > > > > > > > On Tue, Mar 26, 2013 at 05:03:30PM +0600, Илья Шипицин wrote: > > > > > > > > > > > Добрый день! > > > > > > > > > > > > мы достаточно плотно используем nginx для Windows, запускаем его > > > через > > > > > > назначенное задание (scheduled tasks). Для этого в конфиге надо > > > сделать > > > > > > "daemon off" и дальше менеджер заданий следит за > мастер-процессом, > > > > > > запущенным на терминале. > > > > > > > > > > > > это, кстати, удобнее, чем служба Windows (вообще, назначенные > задания > > > > > более > > > > > > удобны и мы чаще используем их, чем службы). > > > > > > > > > > > > в этом сценарии есть один недостаток, при завершении > мастер-процесса, > > > > > > остается запущенный worker-процесс. > > > > > > > > > > > > насколько я понял, в случае Windows это штатная ситуация (при > такой > > > > > работе > > > > > > с процессами, которая используется в nginx), для исправления > > > предлагаю > > > > > > такой патч (сделан для 1.3.14): > > > > > > > > > > > > --- src/os/win32/ngx_process_cycle.c 2013-03-26 > 16:57:20.000000000 > > > > > +0600 > > > > > > +++ src/os/win32/ngx_process_cycle.c.new 2013-03-26 > > > > > > 16:57:00.987341331 +0600 > > > > > > @@ -303,6 +303,8 @@ > > > > > > ngx_console_handler(u_long type) > > > > > > { > > > > > > char *msg; > > > > > > + ngx_cycle_t *cycle; > > > > > > + cycle = (ngx_cycle_t *) ngx_cycle; > > > > > > > > > > > > switch (type) { > > > > > > > > > > > > @@ -316,6 +318,7 @@ > > > > > > > > > > > > case CTRL_CLOSE_EVENT: > > > > > > msg = "console closing, exiting"; > > > > > > + ngx_terminate_worker_processes(cycle); > > > > > > break; > > > > > > > > > > > > case CTRL_LOGOFF_EVENT: > > > > > > > > > > Звать ngx_terminate_worker_processes() - это не очень хорошая > > > > > идея, это всё-таки аварийный механизм, и может приводить к > > > > > нехорошему. Тут имеет смысл как минимум попытаться штатно > > > > > завершить рабочие процессы. > > > > > > > > > > -- > > > > > Maxim Dounin > > > > > http://nginx.org/en/donation.html > > > > > > > > > > _______________________________________________ > > > > > nginx-ru mailing list > > > > > nginx-ru at nginx.org > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > _______________________________________________ > > > > nginx-ru mailing list > > > > nginx-ru at nginx.org > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > -- > > > Maxim Dounin > > > http://nginx.org/en/donation.html > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Mar 27 13:38:53 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 27 Mar 2013 17:38:53 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBuZ2lueC93aW4zMg==?= In-Reply-To: References: <20130326112719.GM62550@mdounin.ru> <20130326120818.GN62550@mdounin.ru> <20130327122034.GY62550@mdounin.ru> Message-ID: <20130327133853.GA62550@mdounin.ru> Hello! On Wed, Mar 27, 2013 at 06:57:05PM +0600, Илья Шипицин wrote: > я проверил банальный ngx_msleep(1000) - он не помогает. > > вот тут > > http://msdn.microsoft.com/ru-RU/library/windows/desktop/ms686722%28v=vs.85%29.aspx > > написано " When the system is terminating a process, it does not terminate > any child processes that the process has created." Судя по цитируемому - понимания, почему ngx_msleep() должет помочь, не наступило, и подозреваю, что проверка была неправильной. На пальцах: Ниже в этой же функции nginx зовёт SetEvent(ngx_stop_event). Это, в свою очередь, должно вызвать возврат из WaitForMultipleObjects() в ngx_master_process_cycle(), и завершение рабочих процессов. Наша задача в ngx_console_handler() - дождаться, пока это случится, и только после этого вернуть 1. Подробнее о том, как система вызывает обработчики, установленные с помощью SetConsoleCtrlHandler(), можно почитать тут: http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx (И таки да, html, top-posting и несколько ответов на одно и то же письмо - это всё хорошие способы убедить меня не отвечать.) > 27 марта 2013 г., 18:20 пользователь Maxim Dounin написал: > > > Hello! > > > > On Wed, Mar 27, 2013 at 09:58:07AM +0600, Илья Шипицин wrote: > > > > > вот такой вариант ? > > > > > > --- src/os/win32/ngx_process_cycle.c.orig 2013-03-27 > > > 09:53:48.000000000 +0600 > > > +++ src/os/win32/ngx_process_cycle.c 2013-03-27 09:48:56.000000000 > > +0600 > > > @@ -303,6 +303,8 @@ > > > ngx_console_handler(u_long type) > > > { > > > char *msg; > > > + ngx_cycle_t *cycle; > > > + cycle = (ngx_cycle_t *) ngx_cycle; > > > > > > switch (type) { > > > > > > @@ -316,6 +318,8 @@ > > > > > > case CTRL_CLOSE_EVENT: > > > msg = "console closing, exiting"; > > > + ngx_quit = 1; > > > + ngx_quit_worker_processes(cycle, 0); > > > break; > > > > > > case CTRL_LOGOFF_EVENT: > > > > Я пересморел этот код ещё раз, перечитал соответствующую виндовую > > документацию, и склонен думать, что: > > > > 1) Патч, меняющий обработку только в случае CTRL_CLOSE_EVENT - > > заведомое неправильный, т.к. все случаи с точки зрения системы и > > nginx'а - равнозначны. (Прозвучавшее тут утверждение, что по > > Ctrl-C воркеры закрываются - видимо основано на наблюдениях за > > отдельными случаями, когда везло. Текущее поведение - содержит в > > себе race, см. ниже, и может иногда работать правильно.) > > > > 2) Текущая обработка - правильная, за одним небольшим упущением: > > нужно дожидаться завершения процесса до собственно возврата из > > ngx_console_handler(), потому что после возврата - процесс > > завершат, и сделанная нами попытка запустить процедуру штатной > > остановки - скорее всего пропадёт впустую. Что, собственно, и > > происходит. > > > > IMHO, правильным решением будет добавить ожидание перед возвратом > > из ngx_console_handler(). В качетсве грубого хака - можно > > попробовать воткнуть туда банальный ngx_msleep(1000), должно > > помочь. > > > > > > > > > > > > > > > > > > > > > > > 26 марта 2013 г., 18:08 пользователь Maxim Dounin > >написал: > > > > > > > Hello! > > > > > > > > On Tue, Mar 26, 2013 at 05:43:21PM +0600, Илья Шипицин wrote: > > > > > > > > > давайте разбираться. если запускать nginx в консоли (это штатный > > режим, > > > > так > > > > > работают назначенные задания), то завершение задания с точки зрения > > > > > мастер-процесса выглядит, как CTRL_CLOSE_EVENT в функции-обработчике > > > > > ngx_console_handler > > > > > > > > > > worker-процесс в это время залипает в функции > > ngx_worker_process_cycle в > > > > > цикле "ev=WaitForMultipleObjects()" > > > > > > > > > > соответственно, закрытие мастера путем закрывания не приводит к тому, > > > > что в > > > > > данном месте возникает какое-то событие. > > > > > > > > То, что это плохо - вопросов не вызывает. По Ctrl-C всё должно > > > > штатно закрываться, а не висеть вечно. > > > > > > > > > варианты - либо существенно переделывать логику и протаскивать сюда > > еще > > > > > одно событие, либо жестко закрыть worker через > > > > > ngx_terminate_worker_processes. > > > > > > > > > > чем чреват второй вариант ? ну ок, закроются текущие сессии. завершая > > > > > задание, мы, вероятно, этого и добиваемся. > > > > > > > > Например, могут остаться полусохранённые файлы в кеше/proxy_store - > > > > если рабочий процесс прервали в процессе копирования временного > > > > файла в целевой каталог. > > > > > > > > (Документация по TerminateProcess() и различные code > > > > checker'ы любят пугать про "the state of global data maintained > > > > by dynamic-link libraries (DLLs) may be compromised". Но это, > > > > насколько я понимаю, в данном случае к nginx'у неприменимо - по > > > > крайней мере, в отсутствии сторонних модулей.) > > > > > > > > > > > > > > > > > > > 26 марта 2013 г., 17:27 пользователь Maxim Dounin < > > mdounin at mdounin.ru > > > > >написал: > > > > > > > > > > > Hello! > > > > > > > > > > > > On Tue, Mar 26, 2013 at 05:03:30PM +0600, Илья Шипицин wrote: > > > > > > > > > > > > > Добрый день! > > > > > > > > > > > > > > мы достаточно плотно используем nginx для Windows, запускаем его > > > > через > > > > > > > назначенное задание (scheduled tasks). Для этого в конфиге надо > > > > сделать > > > > > > > "daemon off" и дальше менеджер заданий следит за > > мастер-процессом, > > > > > > > запущенным на терминале. > > > > > > > > > > > > > > это, кстати, удобнее, чем служба Windows (вообще, назначенные > > задания > > > > > > более > > > > > > > удобны и мы чаще используем их, чем службы). > > > > > > > > > > > > > > в этом сценарии есть один недостаток, при завершении > > мастер-процесса, > > > > > > > остается запущенный worker-процесс. > > > > > > > > > > > > > > насколько я понял, в случае Windows это штатная ситуация (при > > такой > > > > > > работе > > > > > > > с процессами, которая используется в nginx), для исправления > > > > предлагаю > > > > > > > такой патч (сделан для 1.3.14): > > > > > > > > > > > > > > --- src/os/win32/ngx_process_cycle.c 2013-03-26 > > 16:57:20.000000000 > > > > > > +0600 > > > > > > > +++ src/os/win32/ngx_process_cycle.c.new 2013-03-26 > > > > > > > 16:57:00.987341331 +0600 > > > > > > > @@ -303,6 +303,8 @@ > > > > > > > ngx_console_handler(u_long type) > > > > > > > { > > > > > > > char *msg; > > > > > > > + ngx_cycle_t *cycle; > > > > > > > + cycle = (ngx_cycle_t *) ngx_cycle; > > > > > > > > > > > > > > switch (type) { > > > > > > > > > > > > > > @@ -316,6 +318,7 @@ > > > > > > > > > > > > > > case CTRL_CLOSE_EVENT: > > > > > > > msg = "console closing, exiting"; > > > > > > > + ngx_terminate_worker_processes(cycle); > > > > > > > break; > > > > > > > > > > > > > > case CTRL_LOGOFF_EVENT: > > > > > > > > > > > > Звать ngx_terminate_worker_processes() - это не очень хорошая > > > > > > идея, это всё-таки аварийный механизм, и может приводить к > > > > > > нехорошему. Тут имеет смысл как минимум попытаться штатно > > > > > > завершить рабочие процессы. > > > > > > > > > > > > -- > > > > > > Maxim Dounin > > > > > > http://nginx.org/en/donation.html > > > > > > > > > > > > _______________________________________________ > > > > > > nginx-ru mailing list > > > > > > nginx-ru at nginx.org > > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > _______________________________________________ > > > > > nginx-ru mailing list > > > > > nginx-ru at nginx.org > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > > > > -- > > > > Maxim Dounin > > > > http://nginx.org/en/donation.html > > > > > > > > _______________________________________________ > > > > nginx-ru mailing list > > > > nginx-ru at nginx.org > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > -- > > Maxim Dounin > > http://nginx.org/en/donation.html > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://nginx.org/en/donation.html From vbart at nginx.com Wed Mar 27 14:00:52 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 27 Mar 2013 18:00:52 +0400 Subject: =?UTF-8?B?UmU6IFRyYW5zZmVyLUVuY29kaW5nOiBjaHVua2VkICDQtNC70Y8g0YHRgtCw0YI=?= =?UTF-8?B?0LjRh9C10YHQutC40YUg0YTQsNC50LvQvtCy?= In-Reply-To: References: <201303251415.16042.vbart@nginx.com> Message-ID: <201303271800.52380.vbart@nginx.com> On Wednesday 27 March 2013 14:09:54 ciklop wrote: > >Некий Бен скорее всего неправ, и streaming_callback работает вне > > зависимости > > >от chunked transfer encoding. Во всяком случае, никаких явных указаний на > >обратное я не нашел. И было очень бы странно, если бы он это требовал. > > Тут есть такой нюанс - tornado может использовать simple_httpclient и > curl_httpclient > Вот как раз simple_httpclient явно ожидает Transfer-Encoding: chunked. Без > него streaming_callback работать не будет. > А вот curl_httpclient этот заголовок для этого случае не волнует, и с ним > всё прекрасно работает. > Я посмотрел код simple_httpclient и проблема заключается в том, что он в принципе не поддерживает streaming_callback в том виде, в котором его полагает использовать автор топика. Для получения данных он зовет IOStream.read_bytes(), которая поддерживает установку streaming_callback, но он не пользуется этой возможностью вообще, не важно, используется ли chunked transfer encoding, или нет. Однако у simple_httpclient также определен streaming_callback, но он несет совершенно другой смысл и работает иначе. Совпадение в названиях - тут скорее нелепая ошибка. Насколько я понимаю, задача автора - экономить ресурсы и память, не буферизировать большой файл целиком в память, а обрабатывать его по мере получения. Для этой задачи simple_httpclient в принципе не подходит. Не даром simple в названии. -- Валентин Бартенев http://nginx.org/en/donation.html From mail at knutov.com Wed Mar 27 18:12:06 2013 From: mail at knutov.com (Nick Knutov) Date: Thu, 28 Mar 2013 00:12:06 +0600 Subject: nginx-1.3.15 In-Reply-To: <20130326133007.GQ62550@mdounin.ru> References: <20130326133007.GQ62550@mdounin.ru> Message-ID: <51533676.30903@knutov.com> О, кажется это то, что я давно хотел и без дополнительных патчей. А где документация по этому модулю со списком доступных переменных? На сайте не нашел его ни в русской, ни в английской документации. 26.03.2013 19:30, Maxim Dounin пишет: > Изменения в nginx 1.3.15 26.03.2013 > > *) Добавление: переменная $connections_waiting в модуле > ngx_http_stub_status_module. -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From nginx-forum at nginx.us Wed Mar 27 18:41:40 2013 From: nginx-forum at nginx.us (Graid) Date: Wed, 27 Mar 2013 14:41:40 -0400 Subject: not www Message-ID: <7f119ed8cfe4f096667c2c71b96faff3.NginxMailingListRussian@forum.nginx.org> Никогда не использую сабдомен www в проетах, и обычно на всякий пожарный добавляю редиректы такого вида. if ($host = "www.site_name") { rewrite ^/(.*)$ http://site_name/$1 permanent; } Возможно автоматизировать данный конфиг для "мультидоменности". Что то вроде server_name www.* #тут редирект на домен без www В голову приходит только пропустить $host через регулярку. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237842,237842#msg-237842 From kulmaks at gmail.com Wed Mar 27 19:00:42 2013 From: kulmaks at gmail.com (Maksim Kulik) Date: Wed, 27 Mar 2013 22:00:42 +0300 Subject: nginx-1.3.15 In-Reply-To: <51533676.30903@knutov.com> References: <20130326133007.GQ62550@mdounin.ru> <51533676.30903@knutov.com> Message-ID: Есть немного тут: http://nginx.org/ru/docs/http/ngx_http_core_module.html#listen и тут: http://nginx.org/ru/docs/http/ngx_http_spdy_module.html 27 марта 2013 г., 21:12 пользователь Nick Knutov написал: > > О, кажется это то, что я давно хотел и без дополнительных патчей. > > А где документация по этому модулю со списком доступных переменных? На > сайте не нашел его ни в русской, ни в английской документации. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vovansystems at gmail.com Wed Mar 27 19:02:15 2013 From: vovansystems at gmail.com (VovansystemS) Date: Wed, 27 Mar 2013 22:02:15 +0300 Subject: not www In-Reply-To: <7f119ed8cfe4f096667c2c71b96faff3.NginxMailingListRussian@forum.nginx.org> References: <7f119ed8cfe4f096667c2c71b96faff3.NginxMailingListRussian@forum.nginx.org> Message-ID: > Что то вроде > server_name www.* > #тут редирект на домен без www > В голову приходит только пропустить $host через регулярку. у меня для этих целей есть отдельный блок server: server { # редирект на основной домен (он без www) для всех сайтов. # возможно оверрайдить данную настройку указав в кофиге самого сайта в директиве server_name домен с www. server_name ~^www\.(?.+)$; # обязательно указываем ip:port, ибо сайты привязаны к айпишникам и иначе данный server не будет обрабатывать запросы listen 91.11.11.11:80; listen 91.11.11.12:80; return 301 $scheme://$servername$request_uri$is_args$args; } From dmitriy at lyalyuev.info Wed Mar 27 19:48:19 2013 From: dmitriy at lyalyuev.info (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JvRj9C70Y7QtdCy?=) Date: Wed, 27 Mar 2013 21:48:19 +0200 Subject: nginx-1.3.15 In-Reply-To: References: <20130326133007.GQ62550@mdounin.ru> <51533676.30903@knutov.com> Message-ID: Добрый вечер. В development ppa для убунты когда можно ждать? Там пока 1.3.12 лежит. 27 марта 2013 г., 21:00 пользователь Maksim Kulik написал: > Есть немного тут: > http://nginx.org/ru/docs/http/ngx_http_core_module.html#listen > и тут: http://nginx.org/ru/docs/http/ngx_http_spdy_module.html > > 27 марта 2013 г., 21:12 пользователь Nick Knutov написал: > > >> О, кажется это то, что я давно хотел и без дополнительных патчей. >> >> А где документация по этому модулю со списком доступных переменных? На >> сайте не нашел его ни в русской, ни в английской документации. >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- С уважением, Дмитрий Лялюев тел. +380 (66) 532-29-62 Все контакты для связи на http://lyalyuev.info -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Mar 27 20:02:35 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 28 Mar 2013 00:02:35 +0400 Subject: nginx-1.3.15 In-Reply-To: <51533676.30903@knutov.com> References: <20130326133007.GQ62550@mdounin.ru> <51533676.30903@knutov.com> Message-ID: <20130327200235.GH62550@mdounin.ru> Hello! On Thu, Mar 28, 2013 at 12:12:06AM +0600, Nick Knutov wrote: > > О, кажется это то, что я давно хотел и без дополнительных патчей. > > А где документация по этому модулю со списком доступных переменных? На > сайте не нашел его ни в русской, ни в английской документации. На сайте есть, но только на языке C. :) Список доступных переменных тут: http://trac.nginx.org/nginx/browser/nginx/trunk/src/http/modules/ngx_http_stub_status_module.c#L65 -- Maxim Dounin http://nginx.org/en/donation.html From vbart at nginx.com Wed Mar 27 20:16:17 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 28 Mar 2013 00:16:17 +0400 Subject: nginx-1.3.15 In-Reply-To: References: <20130326133007.GQ62550@mdounin.ru> Message-ID: <201303280016.17883.vbart@nginx.com> On Wednesday 27 March 2013 23:48:19 Дмитрий Лялюев wrote: > Добрый вечер. > > В development ppa для убунты когда можно ждать? > Там пока 1.3.12 лежит. > JFYI, nginx.org и NGINX, Inc. не имеет никакого отношения к https://launchpad.net/~nginx/+archive/development Будьте внимательны и осторожны. -- Валентин Бартенев http://nginx.org/en/donation.html > 27 марта 2013 г., 21:00 пользователь Maksim Kulik написал: > > Есть немного тут: > > http://nginx.org/ru/docs/http/ngx_http_core_module.html#listen > > и тут: http://nginx.org/ru/docs/http/ngx_http_spdy_module.html > > > > 27 марта 2013 г., 21:12 пользователь Nick Knutov написал: > >> О, кажется это то, что я давно хотел и без дополнительных патчей. > >> > >> А где документация по этому модулю со списком доступных переменных? На > >> сайте не нашел его ни в русской, ни в английской документации. > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru From a.vasilishin at kpi.ua Wed Mar 27 20:25:49 2013 From: a.vasilishin at kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Wed, 27 Mar 2013 22:25:49 +0200 Subject: Request Entity Too Large Message-ID: <515355CD.3050900@kpi.ua> Здравствуйте! После обновления системы появилась странная ошибка,хотя нгинкс не обновлялся. В конфиге всю жизнь было прописано (и сейчас тоже): client_max_body_size 2048m; client_body_temp_path /tmp; client_body_in_file_only clean; В папке /tmp приаплоадесоздает куча файлов размером 71 байт: -rw------- 1 www-data www-data 71 Мар 27 20:46 0000016025 Содержимое файла # cat /tmp/0000016025 File=File&security_key=c2734b0030cb695809aa2a38c98d2e1b&properties=null Почему-то самого тела передаваемого файла нигде нет, ну и в конце алоада выдает такую ошибку,хотя размер файла гораздо меньше 2048Мб. # nginx -V nginx version: nginx/1.2.4 configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-file-aio --with-http_flv_module --with-http_geoip_module --with-http_mp4_module --with-http_realip_module --with-http_secure_link_module --with-http_stub_status_module --without-http_scgi_module --without-http_split_clients_module --without-http_ssi_module --without-http_userid_module --without-http_uwsgi_module From a.vasilishin at kpi.ua Wed Mar 27 21:36:26 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Wed, 27 Mar 2013 23:36:26 +0200 Subject: Request Entity Too Large In-Reply-To: <515355CD.3050900@kpi.ua> References: <515355CD.3050900@kpi.ua> Message-ID: <5153665A.5010104@kpi.ua> Сам же себе и отвечу. Не работающий конфиг: include /etc/nginx/sites-enabled/*.conf; client_max_body_size 2048m; client_body_temp_path /tmp; client_body_in_file_only clean; Работающий конфиг: client_max_body_size 2048m; client_body_temp_path /tmp; client_body_in_file_only clean; include /etc/nginx/sites-enabled/*.conf; Не думал, что порядок вставки инклюда с виртуалхостами влияет на к ним применение директив описанных в http { } From mdounin at mdounin.ru Wed Mar 27 22:38:04 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 28 Mar 2013 02:38:04 +0400 Subject: Request Entity Too Large In-Reply-To: <5153665A.5010104@kpi.ua> References: <515355CD.3050900@kpi.ua> <5153665A.5010104@kpi.ua> Message-ID: <20130327223803.GM62550@mdounin.ru> Hello! On Wed, Mar 27, 2013 at 11:36:26PM +0200, Андрей Василишин wrote: > > > Сам же себе и отвечу. Не работающий конфиг: > include /etc/nginx/sites-enabled/*.conf; > client_max_body_size 2048m; > client_body_temp_path /tmp; > client_body_in_file_only clean; > > > Работающий конфиг: > client_max_body_size 2048m; > client_body_temp_path /tmp; > client_body_in_file_only clean; > include /etc/nginx/sites-enabled/*.conf; > > Не думал, что порядок вставки инклюда с виртуалхостами влияет на к > ним применение директив описанных в http { } Я стесняюсь спросить - а что показывает nginx -V? В nginx'е из коробки - влиять не должно, но сторонние модули такие модули. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Mar 27 22:46:40 2013 From: nginx-forum at nginx.us (somebi) Date: Wed, 27 Mar 2013 18:46:40 -0400 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0L3QsNGH0LDQu9CwINCy0L7RgdC/0YDQvtC4?= =?UTF-8?B?0LfQstC10LTQtdC90LjRjyDQstC40LTQtdC+INCyINC80L7QtNGD0LvQtSBt?= =?UTF-8?B?cDQ=?= In-Reply-To: <79bb711720ea91737c074a4a69dfdf60.NginxMailingListRussian@forum.nginx.org> References: <04AB5542-CFEB-457F-87D1-FB3744CBFA8A@gmail.com> <145792caba7a2c22841524e04d6f9769.NginxMailingListRussian@forum.nginx.org> <79bb711720ea91737c074a4a69dfdf60.NginxMailingListRussian@forum.nginx.org> Message-ID: <95fa91bbe8f32cd41326177d07639201.NginxMailingListRussian@forum.nginx.org> Ктонибудь, подскажите хоть что-то. Неужели те, кто делал mp4 модуль не знают ответа? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237744,237853#msg-237853 From vbart at nginx.com Wed Mar 27 22:59:18 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 28 Mar 2013 02:59:18 +0400 Subject: Request Entity Too Large In-Reply-To: <5153665A.5010104@kpi.ua> References: <515355CD.3050900@kpi.ua> <5153665A.5010104@kpi.ua> Message-ID: <201303280259.18894.vbart@nginx.com> On Thursday 28 March 2013 01:36:26 Андрей Василишин wrote: > Сам же себе и отвечу. Не работающий конфиг: > include /etc/nginx/sites-enabled/*.conf; > client_max_body_size 2048m; > client_body_temp_path /tmp; > client_body_in_file_only clean; > > > Работающий конфиг: > client_max_body_size 2048m; > client_body_temp_path /tmp; > client_body_in_file_only clean; > include /etc/nginx/sites-enabled/*.conf; > > Не думал, что порядок вставки инклюда с виртуалхостами влияет на к ним > применение директив описанных в http { } > И не влияет. У вас что-то другое. -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Mar 27 23:51:49 2013 From: nginx-forum at nginx.us (zeromind) Date: Wed, 27 Mar 2013 19:51:49 -0400 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0L3QsNGH0LDQu9CwINCy0L7RgdC/0YDQvtC4?= =?UTF-8?B?0LfQstC10LTQtdC90LjRjyDQstC40LTQtdC+INCyINC80L7QtNGD0LvQtSBt?= =?UTF-8?B?cDQ=?= In-Reply-To: <87ef7119656003519cf4bc86a1242207.NginxMailingListRussian@forum.nginx.org> References: <87ef7119656003519cf4bc86a1242207.NginxMailingListRussian@forum.nginx.org> Message-ID: это подгружаются мета данные, юзай flv формат и не будет таких проблем.. за доп консультацией обращайся в icq - 444886246 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237744,237855#msg-237855 From nginx-forum at nginx.us Thu Mar 28 00:05:06 2013 From: nginx-forum at nginx.us (zeromind) Date: Wed, 27 Mar 2013 20:05:06 -0400 Subject: =?UTF-8?B?QmFzaWMgYXV0aCDQv9GA0Lgg0YDQtdCy0YDQsNC50YLQtQ==?= Message-ID: <863dea7a8cf2d83848b163e5f526e8f7.NginxMailingListRussian@forum.nginx.org> Здраствуйте форумчане :), хочу задать вопрос, у меня есть следующие локейшены в конфиге: location /admin { if (!-e $request_filename) { rewrite ^/admin/(.*)$ /admin/index.php?route=$1 last; } index index.php; auth_basic "Unauthorized"; auth_basic_user_file /home/***/www/s1/admin/.htpasswd; } location ~ \.php$ { try_files $uri = 404; fastcgi_index index.php; include fastcgi_params; fastcgi_pass unix:/var/run/php-fpm.sock; } На php, я реализовал мод реврайт, и для этого в nginxe вбил - rewrite ^/admin/(.*)$ /admin/index.php?route=$1 last; так вот.. если мы заходим по url /admin/main/ то запросится пару раз авторизация.. и если НАЖАТЬ ОТМЕНА, покажится сайт (локейшен php отработает динамику), но без css, js, img и тд.. Я так понимаю это из-за реврайта? как решить данную проблему ? отказываться от реврайта не хочу Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237856,237856#msg-237856 From onokonem at gmail.com Thu Mar 28 08:06:02 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 28 Mar 2013 12:06:02 +0400 Subject: mp4 continuously updated file streaming Message-ID: Добрый день! Не смог придумать адекватный запрос к гуглу, хоть и попробовал несколько раз. У меня есть ip-камера и vlc, который пишет поток с нее в файл. Хочется раздавать этот файл nginx-ом, причем - в псевдо-live режиме, с отставанием на, к примеру, секунду от текущего времени. В этой связи - два вопроса: 1) Умеет ли ngx_http_mp4_module стримить файл, в конец которого происходит запись? 2) Можно ли поуправлять из встроенного перла параметром start для ngx_http_mp4_module? Спасибо. С уважением, Даниил Подольский. PS Что vlc умеет не только писать на диск, но и стримить - я в курсе. Но хочется и live, и архив отдавать единообразно. From mdounin at mdounin.ru Thu Mar 28 08:43:20 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 28 Mar 2013 12:43:20 +0400 Subject: =?UTF-8?B?UmU6IEJhc2ljIGF1dGgg0L/RgNC4INGA0LXQstGA0LDQudGC0LU=?= In-Reply-To: <863dea7a8cf2d83848b163e5f526e8f7.NginxMailingListRussian@forum.nginx.org> References: <863dea7a8cf2d83848b163e5f526e8f7.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130328084320.GN62550@mdounin.ru> Hello! On Wed, Mar 27, 2013 at 08:05:06PM -0400, zeromind wrote: > Здраствуйте форумчане :), хочу задать вопрос, у меня есть следующие > локейшены в конфиге: > > location /admin { > if (!-e $request_filename) { > rewrite ^/admin/(.*)$ > /admin/index.php?route=$1 last; > } > index index.php; > auth_basic "Unauthorized"; > auth_basic_user_file > /home/***/www/s1/admin/.htpasswd; > } > > location ~ \.php$ { > try_files $uri = 404; > fastcgi_index index.php; > include fastcgi_params; > fastcgi_pass unix:/var/run/php-fpm.sock; > } > > На php, я реализовал мод реврайт, и для этого в nginxe вбил - rewrite > ^/admin/(.*)$ /admin/index.php?route=$1 last; > так вот.. если мы заходим по url /admin/main/ то запросится пару раз > авторизация.. и если НАЖАТЬ ОТМЕНА, покажится сайт (локейшен php отработает > динамику), но без css, js, img и тд.. Я так понимаю это из-за реврайта? как > решить данную проблему ? У вас доступ к /admin/index.php - не закрыт авторизацией. Решение проблемы - таки закрыть. Правильный конфиг будет выглядеть как-то так: location /admin { auth_basic ... location ~ \.php$ { fastcgi_pass ... ... } } location / { ... location ~ \.php$ { fastcgi_pass ... ... } } -- Maxim Dounin http://nginx.org/en/donation.html From a.vasilishin at kpi.ua Thu Mar 28 08:56:25 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Thu, 28 Mar 2013 10:56:25 +0200 Subject: Request Entity Too Large In-Reply-To: <20130327223803.GM62550@mdounin.ru> References: <515355CD.3050900@kpi.ua> <5153665A.5010104@kpi.ua> <20130327223803.GM62550@mdounin.ru> Message-ID: <515405B9.4050603@kpi.ua> 28.03.2013 0:38, Maxim Dounin пишет: > Я стесняюсь спросить - а что показывает nginx -V? В nginx'е из > коробки - влиять не должно, но сторонние модули такие модули. > Сторонних модулей нет, nginx -V приводил в первом сообщении. По поводу того, что нгинкс не обновлялся - я соврал, обновлся до стандартного дебиановского nginx-extras 1.2.1,потом я его обновил до собственной сборки из дебиановских сорцов nginx-extras 1.2.4 (из сборки исключены все third party модули), но и с учетом множества рестартов новый 1.2.4 продолжал выдавать все туже ошибку, в дебаг-логе ничего подозрительного при этом нет. Потом поменял местами инклюд и еще один рестарт исправил ошибку. From nginx-forum at nginx.us Thu Mar 28 08:57:29 2013 From: nginx-forum at nginx.us (tolikkk) Date: Thu, 28 Mar 2013 04:57:29 -0400 Subject: load balancer backend failed condition Message-ID: <77b23e6dcce102b05896a96661236927.NginxMailingListRussian@forum.nginx.org> Добрый день. Имеется nginx версии 1.2.7. Использую его в качестве HTTP-балансировщика с модулем upstream (HttpUpstreamModule). Кусок конфига: upstream lb_units { server app01:51001 max_fails=3 fail_timeout=30s; server app01:51002 max_fails=3 fail_timeout=30s; server app02:51001 max_fails=3 fail_timeout=30s; server app02:51002 max_fails=3 fail_timeout=30s; } server { listen 51000; server_name localhost; location / { proxy_pass http://lb_units; } } На основе чего server помечается, как недоступный и на него перестают направляться запросы? В документации сказано "If an error occurs when communicating with the server, a request will be passed to the next server". Достаточным условием работоспособности является факт установки TCP-соединения на server:port? Собственно мой вопрос - можно ли прикрутить какую-то прикладную логику к проверке доступности backend-серверов? Я хотел бы отправлять вполне конкретный POST-запрос и уже на основе разбора полученного ответа принимать решение надо ли помечать backend-сервер, как failed - подскажите пожалуйста, такое возможно? Если да - где можно почитать описание и примеры? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237866,237866#msg-237866 From a.vasilishin at kpi.ua Thu Mar 28 08:58:40 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Thu, 28 Mar 2013 10:58:40 +0200 Subject: mp4 continuously updated file streaming In-Reply-To: References: Message-ID: <51540640.4000603@kpi.ua> 28.03.2013 10:06, Daniel Podolsky пишет: > Добрый день! > > Не смог придумать адекватный запрос к гуглу, хоть и попробовал несколько раз. > > У меня есть ip-камера и vlc, который пишет поток с нее в файл. > > Хочется раздавать этот файл nginx-ом, причем - в псевдо-live режиме, с > отставанием на, к примеру, секунду от текущего времени. > > В этой связи - два вопроса: > > 1) Умеет ли ngx_http_mp4_module стримить файл, в конец которого > происходит запись? > > 2) Можно ли поуправлять из встроенного перла параметром start для > ngx_http_mp4_module? > > Спасибо. > > С уважением, > Даниил Подольский. > > PS > Что vlc умеет не только писать на диск, но и стримить - я в курсе. Но > хочется и live, и архив отдавать единообразно. Посмотрите Nginx-rtmp-module, тотточно умеет стриммить, еще стриммить и сохранять поток умеет wowza. From onokonem at gmail.com Thu Mar 28 09:13:43 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 28 Mar 2013 13:13:43 +0400 Subject: mp4 continuously updated file streaming In-Reply-To: <51540640.4000603@kpi.ua> References: <51540640.4000603@kpi.ua> Message-ID: > Посмотрите Nginx-rtmp-module, тотточно умеет стриммить, Посмотрю, спасибо! Первое, что я хотел бы посмотреть - это под какую задачу создавался модуль :) По набору директив похоже, что задача близка к моей. Но хочется подробностей. Быстрый гугл ничего не дал. Вернее - ссылок я получил много, но ни одной с текстом "модуль предназначен для...". :( Может быть, у Вас есть ссылка на соответствующие материалы? > еще стриммить и сохранять поток умеет wowza. Но стоит денег. From a.vasilishin at kpi.ua Thu Mar 28 09:18:46 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Thu, 28 Mar 2013 11:18:46 +0200 Subject: mp4 continuously updated file streaming In-Reply-To: References: <51540640.4000603@kpi.ua> Message-ID: <51540AF6.7070100@kpi.ua> 28.03.2013 11:13, Daniel Podolsky пишет: >> Посмотрите Nginx-rtmp-module, тотточно умеет стриммить, > Посмотрю, спасибо! Первое, что я хотел бы посмотреть - это под какую > задачу создавался модуль :) По набору директив похоже, что задача > близка к моей. Но хочется подробностей. Стриммить умеет, при чем как потоки с пережатием или без, так файлы на диске https://github.com/arut/nginx-rtmp-module/wiki/Examples > Быстрый гугл ничего не дал. Вернее - ссылок я получил много, но ни > одной с текстом "модуль предназначен для...". :( Может быть, у Вас > есть ссылка на соответствующие материалы? > https://github.com/arut/nginx-rtmp-module/wiki/Tutorial And you can add record support for live streams: application live { live on; allow publish 127.0.0.1; deny publish all; allow play all; record all; record_path /path/to/record/dir; record_max_size 100M; record_unique off; } From ru at nginx.com Thu Mar 28 09:22:24 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Thu, 28 Mar 2013 13:22:24 +0400 Subject: load balancer backend failed condition In-Reply-To: <77b23e6dcce102b05896a96661236927.NginxMailingListRussian@forum.nginx.org> References: <77b23e6dcce102b05896a96661236927.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130328092224.GB65443@lo0.su> On Thu, Mar 28, 2013 at 04:57:29AM -0400, tolikkk wrote: > Добрый день. > > Имеется nginx версии 1.2.7. Использую его в качестве HTTP-балансировщика с > модулем upstream (HttpUpstreamModule). > > Кусок конфига: > > upstream lb_units { > server app01:51001 max_fails=3 fail_timeout=30s; > server app01:51002 max_fails=3 fail_timeout=30s; > server app02:51001 max_fails=3 fail_timeout=30s; > server app02:51002 max_fails=3 fail_timeout=30s; > } > > server { > listen 51000; > server_name localhost; > > location / { > proxy_pass http://lb_units; > } > } > > На основе чего server помечается, как недоступный и на него перестают > направляться запросы? > В документации сказано "If an error occurs when communicating with the > server, a request will be passed to the next server". Достаточным условием > работоспособности является факт установки TCP-соединения на server:port? http://nginx.org/r/proxy_next_upstream/ru > Собственно мой вопрос - можно ли прикрутить какую-то прикладную логику к > проверке доступности backend-серверов? Я хотел бы отправлять вполне > конкретный POST-запрос и уже на основе разбора полученного ответа принимать > решение надо ли помечать backend-сервер, как failed - подскажите пожалуйста, > такое возможно? Если да - где можно почитать описание и примеры? Штатными средствами нельзя. From meganuke at meganuke.ru Thu Mar 28 09:31:35 2013 From: meganuke at meganuke.ru (Nikita Stupin) Date: Thu, 28 Mar 2013 13:31:35 +0400 Subject: nginx-1.3.15 In-Reply-To: <201303280016.17883.vbart@nginx.com> References: <20130326133007.GQ62550@mdounin.ru> <201303280016.17883.vbart@nginx.com> Message-ID: <51540DF7.4070304@meganuke.ru> Добрый день. Валентин, а планируется на http://nginx.org/packages/ubuntu/ выкладывать сборки и development ветки? On 3/28/13 12:16 AM, Валентин Бартенев wrote: > On Wednesday 27 March 2013 23:48:19 Дмитрий Лялюев wrote: >> Добрый вечер. >> >> В development ppa для убунты когда можно ждать? >> Там пока 1.3.12 лежит. >> > > JFYI, nginx.org и NGINX, Inc. не имеет никакого отношения к > https://launchpad.net/~nginx/+archive/development > > Будьте внимательны и осторожны. > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > > >> 27 марта 2013 г., 21:00 пользователь Maksim Kulik написал: >>> Есть немного тут: >>> http://nginx.org/ru/docs/http/ngx_http_core_module.html#listen >>> и тут: http://nginx.org/ru/docs/http/ngx_http_spdy_module.html >>> >>> 27 марта 2013 г., 21:12 пользователь Nick Knutov написал: >>>> О, кажется это то, что я давно хотел и без дополнительных патчей. >>>> >>>> А где документация по этому модулю со списком доступных переменных? На >>>> сайте не нашел его ни в русской, ни в английской документации. >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From nginx-forum at nginx.us Thu Mar 28 09:53:02 2013 From: nginx-forum at nginx.us (tolikkk) Date: Thu, 28 Mar 2013 05:53:02 -0400 Subject: load balancer backend failed condition In-Reply-To: <20130328092224.GB65443@lo0.su> References: <20130328092224.GB65443@lo0.su> Message-ID: За proxy_next_upstream спасибо. По изменению метода проверки доступности backend'ов нештатными средствами - подходящих сторонних модулей не знаете случайных? Единственное, что я пока смог придумать - это поставить в cron скрипт, который будет через curl или wget отправлять нужные запросы на backend'ы и если получен ответ, отличный от ожидаемого, то менять конф. файл nginx (добавлять атрибут down проблемному серверу) и перезапускать процесс nginx. Но это, честно говоря, кривизна какая-то. Неужели, у меня первого возникла такая задача? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237866,237875#msg-237875 From denis at webmaster.spb.ru Thu Mar 28 10:24:53 2013 From: denis at webmaster.spb.ru (denis) Date: Thu, 28 Mar 2013 14:24:53 +0400 Subject: Request Entity Too Large In-Reply-To: <20130327223803.GM62550@mdounin.ru> References: <515355CD.3050900@kpi.ua> <5153665A.5010104@kpi.ua> <20130327223803.GM62550@mdounin.ru> Message-ID: <51541A75.8000902@webmaster.spb.ru> 28.03.2013 2:38, Maxim Dounin пишет: >> Не думал, что порядок вставки инклюда с виртуалхостами влияет на к >> ним применение директив описанных в http { } > Я стесняюсь спросить - а что показывает nginx -V? В nginx'е из > коробки - влиять не должно, но сторонние модули такие модули. > Опыт показывает, что влияет очень сильно, вплоть до того, что поддомены приходилось описывать с именами вида 000_sub.domain, иначе первым видело основной блок и привет. (инклуд вида sites/*) Хотя явно столкнулись только с 1 версией, не помню уже какой, но теперь поддомены всегда называем так, чем ниже уровень, тем больше нулей. Более того, на 1 сервере даже игнорировались эти нули и файлы читались в порядке их создания. Явный баг был. И кстати порядок имеет значение, и когда описываем limit_zone, и кэши, и proxy_pass... Очень грустно, что нет вывода итоговой конфигурации, сильно облегчило бы жизнь. Думаю, задача максимум в 10 строк решается, nginx-у делаем ключик типа апачевского -S и на него вывод. From denis at webmaster.spb.ru Thu Mar 28 10:43:24 2013 From: denis at webmaster.spb.ru (denis) Date: Thu, 28 Mar 2013 14:43:24 +0400 Subject: =?UTF-8?B?0L/QvtC70L3QsNGPINCx0LvQvtC60LjRgNC+0LLQutCwIG5naW54Pw==?= Message-ID: <51541ECC.4050406@webmaster.spb.ru> У нас несколько серверов глубокой ночью бэкапятся, и при запуске s3cmd sync сервер становится полностью недоступен, несмотря на секцию upstream. При этом при росте нагрузки от клиентов или ошибке на резерв переключает как надо. Что можно сделать, кроме как запустить 2 nginx чисто как балансер? И кстати, как это правильнее делать во freebsd (8.2) Часть конфига user www www; worker_processes 4; worker_priority -5; error_log /var/log/nginx/error.log; pid /var/run/nginx.pid; events { use kqueue; worker_connections 4096; } http { include mime.types; default_type application/octet-stream; include "conf/log.conf"; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; include "conf/gzip.conf"; #remove "2: No such file or directory" from error.log log_not_found off; include sites-enabled/*.conf; } пример сайта из sites-enabled/*.conf upstream BE-site.ru { server 127.0.0.1:81 max_fails=5 fail_timeout=10; server backup.site.ru backup; } server { server_name .site.ru; root /var/www/site.ru; include "conf/proxy-head.conf"; include "conf/proxy.conf"; include "conf/type-img.conf"; include "conf/static.conf"; include "conf/f.conf"; location / { proxy_pass http://BE-site.ru; proxy_redirect off; proxy_next_upstream error timeout invalid_header http_500 http_502 http_503; } } Инклуды - всякие статик файлы там подключаются, например static.conf location ~* \.(css|js|ico|txt|swf|flv|doc|xls|pdf|zip|rar|avi|mp3)$ { expires 30d; access_log off; } From maxim at nginx.com Thu Mar 28 10:46:30 2013 From: maxim at nginx.com (Maxim Konovalov) Date: Thu, 28 Mar 2013 14:46:30 +0400 Subject: nginx-1.3.15 In-Reply-To: <51540DF7.4070304@meganuke.ru> References: <20130326133007.GQ62550@mdounin.ru> <201303280016.17883.vbart@nginx.com> <51540DF7.4070304@meganuke.ru> Message-ID: <51541F86.7000709@nginx.com> On 3/28/13 1:31 PM, Nikita Stupin wrote: > Добрый день. > > Валентин, а планируется на http://nginx.org/packages/ubuntu/ > выкладывать сборки и development ветки? > Планируется, работаем над этим. -- Maxim Konovalov +7 (910) 4293178 http://nginx.com/services.html From nginx-forum at nginx.us Thu Mar 28 10:50:47 2013 From: nginx-forum at nginx.us (Namaste) Date: Thu, 28 Mar 2013 06:50:47 -0400 Subject: http headers Message-ID: Привет! При первом обращении к картинке на сайте, она выдается скриптом и кешируется fastcgi_cache'ом При повторном обращении берется из кеша, при этом nginx не передает заголовки last-modified & content-length браузеру. По идее nginx ведь мог бы вычислять content-length по размеру файла в кеше за вычетом хидеров и last-modified у файла мог бы брать.. Можно это как-то настроить? или только в самом скрипте вместе с картинкой передавать эти хидеры? Accept-Ranges: bytes - тоже не передает. Докачка поддерживается из кеша? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237881,237881#msg-237881 From mdounin at mdounin.ru Thu Mar 28 10:58:10 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 28 Mar 2013 14:58:10 +0400 Subject: http headers In-Reply-To: References: Message-ID: <20130328105810.GP62550@mdounin.ru> Hello! On Thu, Mar 28, 2013 at 06:50:47AM -0400, Namaste wrote: > Привет! > > При первом обращении к картинке на сайте, она выдается скриптом и кешируется > fastcgi_cache'ом > При повторном обращении берется из кеша, при этом nginx не передает > заголовки last-modified & content-length браузеру. > > По идее nginx ведь мог бы вычислять content-length по размеру файла в кеше > за вычетом хидеров и last-modified у файла мог бы брать.. > Можно это как-то настроить? или только в самом скрипте вместе с картинкой > передавать эти хидеры? Клиенту возвращается то, что вернул backend. Так что если хочется Content-Length и Last-Modified, то надо эти заголовки возвращать. > Accept-Ranges: bytes - тоже не передает. > > Докачка поддерживается из кеша? Range-запросы, они же "докачка", будут работать, если в закешированном ответе указан Content-Length и присутствует заголовок Accept-Ranges. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Mar 28 11:05:51 2013 From: nginx-forum at nginx.us (Namaste) Date: Thu, 28 Mar 2013 07:05:51 -0400 Subject: http headers In-Reply-To: <20130328105810.GP62550@mdounin.ru> References: <20130328105810.GP62550@mdounin.ru> Message-ID: <7f7ae328d73325d9e72c5d57e193c474.NginxMailingListRussian@forum.nginx.org> Понятно. Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237881,237883#msg-237883 From chipitsine at gmail.com Thu Mar 28 11:22:18 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Thu, 28 Mar 2013 17:22:18 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBuZ2lueC93aW4zMg==?= In-Reply-To: <20130327133853.GA62550@mdounin.ru> References: <20130326112719.GM62550@mdounin.ru> <20130326120818.GN62550@mdounin.ru> <20130327122034.GY62550@mdounin.ru> <20130327133853.GA62550@mdounin.ru> Message-ID: Добрый день! ngx_sleep я вставлял перед SetEvent, вставил после - да, сработало. проверьте очередной патч (задумка такая - ждем завершения потомков, если они есть, после чего выходим из ngx_console_close) насчет HTML - гмейл так по-умолчанию делает. всё против вас настроено )) --- src/os/win32/ngx_process_cycle.c.orig 2013-03-27 09:53:48.000000000 +0600 +++ src/os/win32/ngx_process_cycle.c 2013-03-28 17:14:17.000000000 +0600 @@ -303,7 +303,10 @@ ngx_console_handler(u_long type) { char *msg; - + ngx_int_t n; + u_long nev, timeout, ev; + HANDLE events[MAXIMUM_WAIT_OBJECTS]; + switch (type) { case CTRL_C_EVENT: @@ -337,6 +340,18 @@ "SetEvent(\"%s\") failed", ngx_stop_event_name); } + nev = 0; + for (n = 0; n < ngx_last_process; n++) { + if (ngx_processes[n].handle) { + events[nev++] = ngx_processes[n].handle; + } + } + + if(nev != 0){ + timeout = INFINITE; + ev = WaitForMultipleObjects(nev, events, 0, timeout); + } + return 1; } 27 марта 2013 г., 19:38 пользователь Maxim Dounin написал: > Hello! > > On Wed, Mar 27, 2013 at 06:57:05PM +0600, Илья Шипицин wrote: > >> я проверил банальный ngx_msleep(1000) - он не помогает. >> >> вот тут >> >> http://msdn.microsoft.com/ru-RU/library/windows/desktop/ms686722%28v=vs.85%29.aspx >> >> написано " When the system is terminating a process, it does not terminate >> any child processes that the process has created." > > Судя по цитируемому - понимания, почему ngx_msleep() должет > помочь, не наступило, и подозреваю, что проверка была > неправильной. > > На пальцах: > > Ниже в этой же функции nginx зовёт SetEvent(ngx_stop_event). > Это, в свою очередь, должно вызвать возврат из > WaitForMultipleObjects() в ngx_master_process_cycle(), и завершение > рабочих процессов. > > Наша задача в ngx_console_handler() - дождаться, пока это > случится, и только после этого вернуть 1. > > Подробнее о том, как система вызывает обработчики, установленные с > помощью SetConsoleCtrlHandler(), можно почитать тут: > > http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx > > (И таки да, html, top-posting и несколько ответов на одно и то же > письмо - это всё хорошие способы убедить меня не отвечать.) > >> 27 марта 2013 г., 18:20 пользователь Maxim Dounin написал: >> >> > Hello! >> > >> > On Wed, Mar 27, 2013 at 09:58:07AM +0600, Илья Шипицин wrote: >> > >> > > вот такой вариант ? >> > > >> > > --- src/os/win32/ngx_process_cycle.c.orig 2013-03-27 >> > > 09:53:48.000000000 +0600 >> > > +++ src/os/win32/ngx_process_cycle.c 2013-03-27 09:48:56.000000000 >> > +0600 >> > > @@ -303,6 +303,8 @@ >> > > ngx_console_handler(u_long type) >> > > { >> > > char *msg; >> > > + ngx_cycle_t *cycle; >> > > + cycle = (ngx_cycle_t *) ngx_cycle; >> > > >> > > switch (type) { >> > > >> > > @@ -316,6 +318,8 @@ >> > > >> > > case CTRL_CLOSE_EVENT: >> > > msg = "console closing, exiting"; >> > > + ngx_quit = 1; >> > > + ngx_quit_worker_processes(cycle, 0); >> > > break; >> > > >> > > case CTRL_LOGOFF_EVENT: >> > >> > Я пересморел этот код ещё раз, перечитал соответствующую виндовую >> > документацию, и склонен думать, что: >> > >> > 1) Патч, меняющий обработку только в случае CTRL_CLOSE_EVENT - >> > заведомое неправильный, т.к. все случаи с точки зрения системы и >> > nginx'а - равнозначны. (Прозвучавшее тут утверждение, что по >> > Ctrl-C воркеры закрываются - видимо основано на наблюдениях за >> > отдельными случаями, когда везло. Текущее поведение - содержит в >> > себе race, см. ниже, и может иногда работать правильно.) >> > >> > 2) Текущая обработка - правильная, за одним небольшим упущением: >> > нужно дожидаться завершения процесса до собственно возврата из >> > ngx_console_handler(), потому что после возврата - процесс >> > завершат, и сделанная нами попытка запустить процедуру штатной >> > остановки - скорее всего пропадёт впустую. Что, собственно, и >> > происходит. >> > >> > IMHO, правильным решением будет добавить ожидание перед возвратом >> > из ngx_console_handler(). В качетсве грубого хака - можно >> > попробовать воткнуть туда банальный ngx_msleep(1000), должно >> > помочь. >> > >> > > >> > > >> > > >> > > >> > > >> > > >> > > 26 марта 2013 г., 18:08 пользователь Maxim Dounin > > >написал: >> > > >> > > > Hello! >> > > > >> > > > On Tue, Mar 26, 2013 at 05:43:21PM +0600, Илья Шипицин wrote: >> > > > >> > > > > давайте разбираться. если запускать nginx в консоли (это штатный >> > режим, >> > > > так >> > > > > работают назначенные задания), то завершение задания с точки зрения >> > > > > мастер-процесса выглядит, как CTRL_CLOSE_EVENT в функции-обработчике >> > > > > ngx_console_handler >> > > > > >> > > > > worker-процесс в это время залипает в функции >> > ngx_worker_process_cycle в >> > > > > цикле "ev=WaitForMultipleObjects()" >> > > > > >> > > > > соответственно, закрытие мастера путем закрывания не приводит к тому, >> > > > что в >> > > > > данном месте возникает какое-то событие. >> > > > >> > > > То, что это плохо - вопросов не вызывает. По Ctrl-C всё должно >> > > > штатно закрываться, а не висеть вечно. >> > > > >> > > > > варианты - либо существенно переделывать логику и протаскивать сюда >> > еще >> > > > > одно событие, либо жестко закрыть worker через >> > > > > ngx_terminate_worker_processes. >> > > > > >> > > > > чем чреват второй вариант ? ну ок, закроются текущие сессии. завершая >> > > > > задание, мы, вероятно, этого и добиваемся. >> > > > >> > > > Например, могут остаться полусохранённые файлы в кеше/proxy_store - >> > > > если рабочий процесс прервали в процессе копирования временного >> > > > файла в целевой каталог. >> > > > >> > > > (Документация по TerminateProcess() и различные code >> > > > checker'ы любят пугать про "the state of global data maintained >> > > > by dynamic-link libraries (DLLs) may be compromised". Но это, >> > > > насколько я понимаю, в данном случае к nginx'у неприменимо - по >> > > > крайней мере, в отсутствии сторонних модулей.) >> > > > >> > > > > >> > > > > >> > > > > 26 марта 2013 г., 17:27 пользователь Maxim Dounin < >> > mdounin at mdounin.ru >> > > > >написал: >> > > > > >> > > > > > Hello! >> > > > > > >> > > > > > On Tue, Mar 26, 2013 at 05:03:30PM +0600, Илья Шипицин wrote: >> > > > > > >> > > > > > > Добрый день! >> > > > > > > >> > > > > > > мы достаточно плотно используем nginx для Windows, запускаем его >> > > > через >> > > > > > > назначенное задание (scheduled tasks). Для этого в конфиге надо >> > > > сделать >> > > > > > > "daemon off" и дальше менеджер заданий следит за >> > мастер-процессом, >> > > > > > > запущенным на терминале. >> > > > > > > >> > > > > > > это, кстати, удобнее, чем служба Windows (вообще, назначенные >> > задания >> > > > > > более >> > > > > > > удобны и мы чаще используем их, чем службы). >> > > > > > > >> > > > > > > в этом сценарии есть один недостаток, при завершении >> > мастер-процесса, >> > > > > > > остается запущенный worker-процесс. >> > > > > > > >> > > > > > > насколько я понял, в случае Windows это штатная ситуация (при >> > такой >> > > > > > работе >> > > > > > > с процессами, которая используется в nginx), для исправления >> > > > предлагаю >> > > > > > > такой патч (сделан для 1.3.14): >> > > > > > > >> > > > > > > --- src/os/win32/ngx_process_cycle.c 2013-03-26 >> > 16:57:20.000000000 >> > > > > > +0600 >> > > > > > > +++ src/os/win32/ngx_process_cycle.c.new 2013-03-26 >> > > > > > > 16:57:00.987341331 +0600 >> > > > > > > @@ -303,6 +303,8 @@ >> > > > > > > ngx_console_handler(u_long type) >> > > > > > > { >> > > > > > > char *msg; >> > > > > > > + ngx_cycle_t *cycle; >> > > > > > > + cycle = (ngx_cycle_t *) ngx_cycle; >> > > > > > > >> > > > > > > switch (type) { >> > > > > > > >> > > > > > > @@ -316,6 +318,7 @@ >> > > > > > > >> > > > > > > case CTRL_CLOSE_EVENT: >> > > > > > > msg = "console closing, exiting"; >> > > > > > > + ngx_terminate_worker_processes(cycle); >> > > > > > > break; >> > > > > > > >> > > > > > > case CTRL_LOGOFF_EVENT: >> > > > > > >> > > > > > Звать ngx_terminate_worker_processes() - это не очень хорошая >> > > > > > идея, это всё-таки аварийный механизм, и может приводить к >> > > > > > нехорошему. Тут имеет смысл как минимум попытаться штатно >> > > > > > завершить рабочие процессы. >> > > > > > >> > > > > > -- >> > > > > > Maxim Dounin >> > > > > > http://nginx.org/en/donation.html >> > > > > > >> > > > > > _______________________________________________ >> > > > > > nginx-ru mailing list >> > > > > > nginx-ru at nginx.org >> > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > >> > > > > _______________________________________________ >> > > > > nginx-ru mailing list >> > > > > nginx-ru at nginx.org >> > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > >> > > > >> > > > -- >> > > > Maxim Dounin >> > > > http://nginx.org/en/donation.html >> > > > >> > > > _______________________________________________ >> > > > nginx-ru mailing list >> > > > nginx-ru at nginx.org >> > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > >> > >> > > _______________________________________________ >> > > nginx-ru mailing list >> > > nginx-ru at nginx.org >> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > >> > >> > -- >> > Maxim Dounin >> > http://nginx.org/en/donation.html >> > >> > _______________________________________________ >> > nginx-ru mailing list >> > nginx-ru at nginx.org >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Thu Mar 28 11:34:33 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 28 Mar 2013 15:34:33 +0400 Subject: Request Entity Too Large In-Reply-To: <515405B9.4050603@kpi.ua> References: <515355CD.3050900@kpi.ua> <5153665A.5010104@kpi.ua> <20130327223803.GM62550@mdounin.ru> <515405B9.4050603@kpi.ua> Message-ID: <20130328113433.GQ62550@mdounin.ru> Hello! On Thu, Mar 28, 2013 at 10:56:25AM +0200, Андрей Василишин wrote: > 28.03.2013 0:38, Maxim Dounin пишет: > > >Я стесняюсь спросить - а что показывает nginx -V? В nginx'е из > >коробки - влиять не должно, но сторонние модули такие модули. > > > > Сторонних модулей нет, nginx -V приводил в первом сообщении. > По поводу того, что нгинкс не обновлялся - я соврал, обновлся до > стандартного дебиановского nginx-extras 1.2.1,потом я его обновил до > собственной сборки из дебиановских сорцов nginx-extras 1.2.4 (из > сборки исключены все third party модули), но и с учетом множества > рестартов новый 1.2.4 продолжал выдавать все туже ошибку, в То, что таки работала версия без сторонних модулей, а не ранее запущенная сборка с зоопарком - чем нибудь подтверждается, кроме собственной увернности в том, что restart'ы - были? E.g. номером версии, записанным в логах? > дебаг-логе ничего подозрительного при этом нет. Дополнительно интересно - что при этом было в логах nginx'а? Если nginx возвращает 413, то он на уровне error пишет в логи "client intended to send too large body", с указанием размеров. Если соответствующих строк не было - возможно, ошибку возвращал вообще не nginx... > Потом поменял > местами инклюд и еще один рестарт исправил ошибку. Если упомянутые строчки поменять местами обратно - проблема возвращается? -- Maxim Dounin http://nginx.org/en/donation.html From chipitsine at gmail.com Thu Mar 28 12:03:05 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Thu, 28 Mar 2013 18:03:05 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBuZ2lueC93aW4zMg==?= In-Reply-To: References: <20130326112719.GM62550@mdounin.ru> <20130326120818.GN62550@mdounin.ru> <20130327122034.GY62550@mdounin.ru> <20130327133853.GA62550@mdounin.ru> Message-ID: Добрый день! поправил 0 --> TRUE в WaitForMultipleObjects, чтобы дождаться завершения всех потомков, патч: --- src/os/win32/ngx_process_cycle.c.orig 2013-03-27 09:53:48.000000000 +0600 +++ src/os/win32/ngx_process_cycle.c 2013-03-28 17:58:49.000000000 +0600 @@ -303,7 +303,10 @@ ngx_console_handler(u_long type) { char *msg; - + ngx_int_t n; + u_long nev, timeout, ev; + HANDLE events[MAXIMUM_WAIT_OBJECTS]; + switch (type) { case CTRL_C_EVENT: @@ -337,6 +340,18 @@ "SetEvent(\"%s\") failed", ngx_stop_event_name); } + nev = 0; + for (n = 0; n < ngx_last_process; n++) { + if (ngx_processes[n].handle) { + events[nev++] = ngx_processes[n].handle; + } + } + + if(nev != 0){ + timeout = INFINITE; + ev = WaitForMultipleObjects(nev, events, TRUE, timeout); + } + return 1; } 28 марта 2013 г., 17:22 пользователь Илья Шипицин написал: > Добрый день! > > ngx_sleep я вставлял перед SetEvent, вставил после - да, сработало. > проверьте очередной патч (задумка такая - ждем завершения потомков, > если они есть, после чего выходим из ngx_console_close) > > насчет HTML - гмейл так по-умолчанию делает. всё против вас настроено )) > > > --- src/os/win32/ngx_process_cycle.c.orig 2013-03-27 > 09:53:48.000000000 +0600 > +++ src/os/win32/ngx_process_cycle.c 2013-03-28 17:14:17.000000000 +0600 > @@ -303,7 +303,10 @@ > ngx_console_handler(u_long type) > { > char *msg; > - > + ngx_int_t n; > + u_long nev, timeout, ev; > + HANDLE events[MAXIMUM_WAIT_OBJECTS]; > + > switch (type) { > > case CTRL_C_EVENT: > @@ -337,6 +340,18 @@ > "SetEvent(\"%s\") failed", ngx_stop_event_name); > } > > + nev = 0; > + for (n = 0; n < ngx_last_process; n++) { > + if (ngx_processes[n].handle) { > + events[nev++] = ngx_processes[n].handle; > + } > + } > + > + if(nev != 0){ > + timeout = INFINITE; > + ev = WaitForMultipleObjects(nev, events, 0, timeout); > + } > + > return 1; > } > > 27 марта 2013 г., 19:38 пользователь Maxim Dounin написал: >> Hello! >> >> On Wed, Mar 27, 2013 at 06:57:05PM +0600, Илья Шипицин wrote: >> >>> я проверил банальный ngx_msleep(1000) - он не помогает. >>> >>> вот тут >>> >>> http://msdn.microsoft.com/ru-RU/library/windows/desktop/ms686722%28v=vs.85%29.aspx >>> >>> написано " When the system is terminating a process, it does not terminate >>> any child processes that the process has created." >> >> Судя по цитируемому - понимания, почему ngx_msleep() должет >> помочь, не наступило, и подозреваю, что проверка была >> неправильной. >> >> На пальцах: >> >> Ниже в этой же функции nginx зовёт SetEvent(ngx_stop_event). >> Это, в свою очередь, должно вызвать возврат из >> WaitForMultipleObjects() в ngx_master_process_cycle(), и завершение >> рабочих процессов. >> >> Наша задача в ngx_console_handler() - дождаться, пока это >> случится, и только после этого вернуть 1. >> >> Подробнее о том, как система вызывает обработчики, установленные с >> помощью SetConsoleCtrlHandler(), можно почитать тут: >> >> http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx >> >> (И таки да, html, top-posting и несколько ответов на одно и то же >> письмо - это всё хорошие способы убедить меня не отвечать.) >> >>> 27 марта 2013 г., 18:20 пользователь Maxim Dounin написал: >>> >>> > Hello! >>> > >>> > On Wed, Mar 27, 2013 at 09:58:07AM +0600, Илья Шипицин wrote: >>> > >>> > > вот такой вариант ? >>> > > >>> > > --- src/os/win32/ngx_process_cycle.c.orig 2013-03-27 >>> > > 09:53:48.000000000 +0600 >>> > > +++ src/os/win32/ngx_process_cycle.c 2013-03-27 09:48:56.000000000 >>> > +0600 >>> > > @@ -303,6 +303,8 @@ >>> > > ngx_console_handler(u_long type) >>> > > { >>> > > char *msg; >>> > > + ngx_cycle_t *cycle; >>> > > + cycle = (ngx_cycle_t *) ngx_cycle; >>> > > >>> > > switch (type) { >>> > > >>> > > @@ -316,6 +318,8 @@ >>> > > >>> > > case CTRL_CLOSE_EVENT: >>> > > msg = "console closing, exiting"; >>> > > + ngx_quit = 1; >>> > > + ngx_quit_worker_processes(cycle, 0); >>> > > break; >>> > > >>> > > case CTRL_LOGOFF_EVENT: >>> > >>> > Я пересморел этот код ещё раз, перечитал соответствующую виндовую >>> > документацию, и склонен думать, что: >>> > >>> > 1) Патч, меняющий обработку только в случае CTRL_CLOSE_EVENT - >>> > заведомое неправильный, т.к. все случаи с точки зрения системы и >>> > nginx'а - равнозначны. (Прозвучавшее тут утверждение, что по >>> > Ctrl-C воркеры закрываются - видимо основано на наблюдениях за >>> > отдельными случаями, когда везло. Текущее поведение - содержит в >>> > себе race, см. ниже, и может иногда работать правильно.) >>> > >>> > 2) Текущая обработка - правильная, за одним небольшим упущением: >>> > нужно дожидаться завершения процесса до собственно возврата из >>> > ngx_console_handler(), потому что после возврата - процесс >>> > завершат, и сделанная нами попытка запустить процедуру штатной >>> > остановки - скорее всего пропадёт впустую. Что, собственно, и >>> > происходит. >>> > >>> > IMHO, правильным решением будет добавить ожидание перед возвратом >>> > из ngx_console_handler(). В качетсве грубого хака - можно >>> > попробовать воткнуть туда банальный ngx_msleep(1000), должно >>> > помочь. >>> > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > 26 марта 2013 г., 18:08 пользователь Maxim Dounin >> > >написал: >>> > > >>> > > > Hello! >>> > > > >>> > > > On Tue, Mar 26, 2013 at 05:43:21PM +0600, Илья Шипицин wrote: >>> > > > >>> > > > > давайте разбираться. если запускать nginx в консоли (это штатный >>> > режим, >>> > > > так >>> > > > > работают назначенные задания), то завершение задания с точки зрения >>> > > > > мастер-процесса выглядит, как CTRL_CLOSE_EVENT в функции-обработчике >>> > > > > ngx_console_handler >>> > > > > >>> > > > > worker-процесс в это время залипает в функции >>> > ngx_worker_process_cycle в >>> > > > > цикле "ev=WaitForMultipleObjects()" >>> > > > > >>> > > > > соответственно, закрытие мастера путем закрывания не приводит к тому, >>> > > > что в >>> > > > > данном месте возникает какое-то событие. >>> > > > >>> > > > То, что это плохо - вопросов не вызывает. По Ctrl-C всё должно >>> > > > штатно закрываться, а не висеть вечно. >>> > > > >>> > > > > варианты - либо существенно переделывать логику и протаскивать сюда >>> > еще >>> > > > > одно событие, либо жестко закрыть worker через >>> > > > > ngx_terminate_worker_processes. >>> > > > > >>> > > > > чем чреват второй вариант ? ну ок, закроются текущие сессии. завершая >>> > > > > задание, мы, вероятно, этого и добиваемся. >>> > > > >>> > > > Например, могут остаться полусохранённые файлы в кеше/proxy_store - >>> > > > если рабочий процесс прервали в процессе копирования временного >>> > > > файла в целевой каталог. >>> > > > >>> > > > (Документация по TerminateProcess() и различные code >>> > > > checker'ы любят пугать про "the state of global data maintained >>> > > > by dynamic-link libraries (DLLs) may be compromised". Но это, >>> > > > насколько я понимаю, в данном случае к nginx'у неприменимо - по >>> > > > крайней мере, в отсутствии сторонних модулей.) >>> > > > >>> > > > > >>> > > > > >>> > > > > 26 марта 2013 г., 17:27 пользователь Maxim Dounin < >>> > mdounin at mdounin.ru >>> > > > >написал: >>> > > > > >>> > > > > > Hello! >>> > > > > > >>> > > > > > On Tue, Mar 26, 2013 at 05:03:30PM +0600, Илья Шипицин wrote: >>> > > > > > >>> > > > > > > Добрый день! >>> > > > > > > >>> > > > > > > мы достаточно плотно используем nginx для Windows, запускаем его >>> > > > через >>> > > > > > > назначенное задание (scheduled tasks). Для этого в конфиге надо >>> > > > сделать >>> > > > > > > "daemon off" и дальше менеджер заданий следит за >>> > мастер-процессом, >>> > > > > > > запущенным на терминале. >>> > > > > > > >>> > > > > > > это, кстати, удобнее, чем служба Windows (вообще, назначенные >>> > задания >>> > > > > > более >>> > > > > > > удобны и мы чаще используем их, чем службы). >>> > > > > > > >>> > > > > > > в этом сценарии есть один недостаток, при завершении >>> > мастер-процесса, >>> > > > > > > остается запущенный worker-процесс. >>> > > > > > > >>> > > > > > > насколько я понял, в случае Windows это штатная ситуация (при >>> > такой >>> > > > > > работе >>> > > > > > > с процессами, которая используется в nginx), для исправления >>> > > > предлагаю >>> > > > > > > такой патч (сделан для 1.3.14): >>> > > > > > > >>> > > > > > > --- src/os/win32/ngx_process_cycle.c 2013-03-26 >>> > 16:57:20.000000000 >>> > > > > > +0600 >>> > > > > > > +++ src/os/win32/ngx_process_cycle.c.new 2013-03-26 >>> > > > > > > 16:57:00.987341331 +0600 >>> > > > > > > @@ -303,6 +303,8 @@ >>> > > > > > > ngx_console_handler(u_long type) >>> > > > > > > { >>> > > > > > > char *msg; >>> > > > > > > + ngx_cycle_t *cycle; >>> > > > > > > + cycle = (ngx_cycle_t *) ngx_cycle; >>> > > > > > > >>> > > > > > > switch (type) { >>> > > > > > > >>> > > > > > > @@ -316,6 +318,7 @@ >>> > > > > > > >>> > > > > > > case CTRL_CLOSE_EVENT: >>> > > > > > > msg = "console closing, exiting"; >>> > > > > > > + ngx_terminate_worker_processes(cycle); >>> > > > > > > break; >>> > > > > > > >>> > > > > > > case CTRL_LOGOFF_EVENT: >>> > > > > > >>> > > > > > Звать ngx_terminate_worker_processes() - это не очень хорошая >>> > > > > > идея, это всё-таки аварийный механизм, и может приводить к >>> > > > > > нехорошему. Тут имеет смысл как минимум попытаться штатно >>> > > > > > завершить рабочие процессы. >>> > > > > > >>> > > > > > -- >>> > > > > > Maxim Dounin >>> > > > > > http://nginx.org/en/donation.html >>> > > > > > >>> > > > > > _______________________________________________ >>> > > > > > nginx-ru mailing list >>> > > > > > nginx-ru at nginx.org >>> > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> > > > >>> > > > > _______________________________________________ >>> > > > > nginx-ru mailing list >>> > > > > nginx-ru at nginx.org >>> > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> > > > >>> > > > >>> > > > -- >>> > > > Maxim Dounin >>> > > > http://nginx.org/en/donation.html >>> > > > >>> > > > _______________________________________________ >>> > > > nginx-ru mailing list >>> > > > nginx-ru at nginx.org >>> > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> > > > >>> > >>> > > _______________________________________________ >>> > > nginx-ru mailing list >>> > > nginx-ru at nginx.org >>> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> > >>> > >>> > -- >>> > Maxim Dounin >>> > http://nginx.org/en/donation.html >>> > >>> > _______________________________________________ >>> > nginx-ru mailing list >>> > nginx-ru at nginx.org >>> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> > >> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> -- >> Maxim Dounin >> http://nginx.org/en/donation.html >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Thu Mar 28 12:03:56 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 28 Mar 2013 16:03:56 +0400 Subject: Request Entity Too Large In-Reply-To: <51541A75.8000902@webmaster.spb.ru> References: <515355CD.3050900@kpi.ua> <5153665A.5010104@kpi.ua> <20130327223803.GM62550@mdounin.ru> <51541A75.8000902@webmaster.spb.ru> Message-ID: <20130328120355.GR62550@mdounin.ru> Hello! On Thu, Mar 28, 2013 at 02:24:53PM +0400, denis wrote: > 28.03.2013 2:38, Maxim Dounin пишет: > >>Не думал, что порядок вставки инклюда с виртуалхостами влияет на к > >>ним применение директив описанных в http { } > >Я стесняюсь спросить - а что показывает nginx -V? В nginx'е из > >коробки - влиять не должно, но сторонние модули такие модули. > > > Опыт показывает, что влияет очень сильно, вплоть до того, что > поддомены приходилось описывать с именами вида 000_sub.domain, иначе > первым видело основной блок и привет. (инклуд вида sites/*) > Хотя явно столкнулись только с 1 версией, не помню уже какой, но > теперь поддомены всегда называем так, чем ниже уровень, тем больше > нулей. > Более того, на 1 сервере даже игнорировались эти нули и файлы > читались в порядке их создания. Явный баг был. "Правда, только ... и не выиграл, а проиграл." (c) В некоторых случаях порядок написания директив или блоков в конфиге, действительно, важен. Так, при описании нескольких виртуальных серверов на одном и том же listen-сокете по умолчанию используется тот виртуальный сервер, что описан первым: http://nginx.org/ru/docs/http/ngx_http_core_module.html#listen : Если у директивы есть параметр default_server, то сервер, в : котором описана эта директива, будет сервером по умолчанию для : указанной пары адрес:порт. Если же директив с параметром : default_server нет, то сервером по умолчанию будет первый сервер, : в котором описана пара адрес:порт. При этом директива include - не гарантирует какой-либо порядок включения файлов при использовании масок, что плохо отражается на работоспособности конфигов, использующих директиву include для включения множества блоков server{} и при этом не использующих параметр default_server директивы listen. Очевидных решений два: 1) Не использовать include "вида sites/*". Вообще конфигурить nginx одним файлом - гораздо приятнее и удобнее, а главное - понятнее, особенно новичкам. 2) Расставлять "listen ... default_server" правильно. Отдельно может доставить попытка использовать имена серверов, заданные регулярными выражениями, ибо оные регулярные выражения - проверяются в порядке описания в конфигурационном файле (http://nginx.org/r/server_name/ru). Каковой порядок, как мы уже выяснили выше, в случае "include sites/*" не определён. Всё это относится к типичных ошибкам при конфигурировании nginx'а вообще, и к проблемам использованного по умолчанию конфига во многих пакетах в linux'е - в частности. И, без сомнения, может являться причиной наблюдаемых проблем. Однако проблема в этом случае - в неконсистентности конфига, загружаемого по "include sites/*", а не в том, что стоит раньше, client_max_body_size - или include. > И кстати порядок имеет значение, и когда описываем limit_zone, и > кэши, и proxy_pass... > Очень грустно, что нет вывода итоговой конфигурации, сильно > облегчило бы жизнь. Думаю, задача максимум в 10 строк решается, > nginx-у делаем ключик типа апачевского -S и на него вывод. Может быть, но в ситуации, когда порядок вообще говоря не определён - подобный вывод только собъёт с толку. -- Maxim Dounin http://nginx.org/en/donation.html From anatoly at sonru.com Thu Mar 28 12:34:21 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Thu, 28 Mar 2013 12:34:21 +0000 Subject: =?UTF-8?B?0L3QtdCx0LvQvtC60LjRgNGD0Y7RidC40Lkg0LDQv9C70L7QsNC0?= Message-ID: Вопрос по неблокирующему аплоаду больших файлов, в идеале без необходимости использовать проксирование на upstream. 2 варианта: 1) nginx-upload-module 2) lua-resty-upload Первый поломался с выходом nginx 1.3.9 https://github.com/vkholodkov/nginx-upload-module/issues/41 Второй требует 2 дополнительных модуля (devkit, lua), но еще не production-ready Что выбрать? Анатолий From denis at webmaster.spb.ru Thu Mar 28 13:29:22 2013 From: denis at webmaster.spb.ru (denis) Date: Thu, 28 Mar 2013 17:29:22 +0400 Subject: Request Entity Too Large In-Reply-To: <20130328120355.GR62550@mdounin.ru> References: <515355CD.3050900@kpi.ua> <5153665A.5010104@kpi.ua> <20130327223803.GM62550@mdounin.ru> <51541A75.8000902@webmaster.spb.ru> <20130328120355.GR62550@mdounin.ru> Message-ID: <515445B2.3010009@webmaster.spb.ru> 28.03.2013 16:03, Maxim Dounin пишет: > При этом директива include - не гарантирует какой-либо порядок > включения файлов при использовании масок, что плохо отражается на > работоспособности конфигов, использующих директиву include для > включения множества блоков server{} и при этом не использующих > параметр default_server директивы listen. При чём тут вообще default_server? У меня он задаётся в отдельном конфиге, 000_default, и с этим проблем нет. > Очевидных решений два: > > 1) Не использовать include "вида sites/*". Вообще конфигурить > nginx одним файлом - гораздо приятнее и удобнее, а главное - > понятнее, особенно новичкам. Ага. Особенно когда сайтов не 1-2, а десятков 5, причём конфигурация типовая. Плюс на каждый - ещё пяток server-секций, с редиректами на основной сайт. И теперь представим, что нам надо отключить 1 сайт с его редиректами-алиасами. Автоматом (не ручками). В случае с conf/* - просто удаляем/переносим 1 файл, и ВСЁ. А в 1... привет неделя секса с sed? Вручную? А если надо поручить такое отключение тому самому "новичку"? Усложним - отключать и подключать домены будем по нескольку раз в день. Теперь понадобилось добавить 1 формат картинок на все домены. Правлю conf/static.conf например, и всё, на всех доменах нормальный формат. А с единым - привет сед? Плюс хорошо бы потом проверить все домены, что у всех единая строка с картинками. А теперь добавим еще location всем основным доменам. Тут я уже даже не представляю, как это сделать кроме как вручную каждому сайту. Теперь добавим конфиги в систему контроля версий. Что удобнее контролировать, когда у нас 1 файл и надо откатить 1 домен из старой ревизии, при этом сохранив десяток появившихся с того момента доменов, или когда все домены в отдельных файлах? Да, а на 1 сервере у меня около 1к доменов. И вариант "поправить вручную" идёт лесом, молча и сразу. Про понятнее - найти что-то глазами в 100кб конфиге сильно сложнее, чем в пачке логически раскиданных, вдобавок суммарно далеко не 100кб (вспоминаем вынесение типовых блоков в 1 файл). Плюс grep -l всегда поможет найти нужный файл в пару кб, а его уже глазами целиком ухватить можно. И да, если используется ispmanager, несколько раз он бил мне этот "единый конфиг", поэтому давно конфиг разбивается на сайты и инклудится. Потом очень геморно - переписывать настройки под 2-10 сайтов, которые он каким-то образом дропнул. Так что в каком-то странном мире Вы живете. > 2) Расставлять "listen ... default_server" правильно. Еще раз, при чём тут вообще default_server > Отдельно может доставить попытка использовать имена серверов, > заданные регулярными выражениями, ибо оные регулярные выражения - > проверяются в порядке описания в конфигурационном файле > (http://nginx.org/r/server_name/ru). Каковой порядок, как мы уже > выяснили выше, в случае "include sites/*" не определён. Практика показывает, что нормально всё работает. Есть особенности с тем, что нельзя описывать главный сайт с точкой или *, и тогда всё работает. Плюс опять же, 0_sub.site. Уже приводил линк на эту тему, http://dragonflybsd.blogspot.ru/2012/07/nginx-regex-servername.html > Может быть, но в ситуации, когда порядок вообще говоря не > определён - подобный вывод только собъёт с толку. Он покажет, как нгинх распарсил конфиги, в каком порядке загрузил файлы итд. From sytar.alex at gmail.com Thu Mar 28 13:34:26 2013 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Thu, 28 Mar 2013 17:34:26 +0400 Subject: Request Entity Too Large In-Reply-To: <515445B2.3010009@webmaster.spb.ru> References: <515355CD.3050900@kpi.ua> <5153665A.5010104@kpi.ua> <20130327223803.GM62550@mdounin.ru> <51541A75.8000902@webmaster.spb.ru> <20130328120355.GR62550@mdounin.ru> <515445B2.3010009@webmaster.spb.ru> Message-ID: 28 марта 2013 г., 17:29 пользователь denis написал: >> 1) Не использовать include "вида sites/*". Вообще конфигурить >> nginx одним файлом - гораздо приятнее и удобнее, а главное - >> понятнее, особенно новичкам. > > Ага. Особенно когда сайтов не 1-2, а десятков 5, причём конфигурация > типовая. Плюс на каждый - ещё пяток server-секций, с редиректами на основной > сайт. И теперь представим, что нам надо отключить 1 сайт с его > редиректами-алиасами. Автоматом (не ручками). В случае с conf/* - просто > удаляем/переносим 1 файл, и ВСЁ. А в 1... привет неделя секса с sed? > Вручную? А если надо поручить такое отключение тому самому "новичку"? > Усложним - отключать и подключать домены будем по нескольку раз в день. > Теперь понадобилось добавить 1 формат картинок на все домены. Правлю > conf/static.conf например, и всё, на всех доменах нормальный формат. > А с единым - привет сед? Плюс хорошо бы потом проверить все домены, что у > всех единая строка с картинками. > А теперь добавим еще location всем основным доменам. Тут я уже даже не > представляю, как это сделать кроме как вручную каждому сайту. > Теперь добавим конфиги в систему контроля версий. Что удобнее > контролировать, когда у нас 1 файл и надо откатить 1 домен из старой > ревизии, при этом сохранив десяток появившихся с того момента доменов, или > когда все домены в отдельных файлах? > > Да, а на 1 сервере у меня около 1к доменов. И вариант "поправить вручную" > идёт лесом, молча и сразу. > > Про понятнее - найти что-то глазами в 100кб конфиге сильно сложнее, чем в > пачке логически раскиданных, вдобавок суммарно далеко не 100кб (вспоминаем > вынесение типовых блоков в 1 файл). Плюс grep -l всегда поможет найти нужный > файл в пару кб, а его уже глазами целиком ухватить можно. > > И да, если используется ispmanager, несколько раз он бил мне этот "единый > конфиг", поэтому давно конфиг разбивается на сайты и инклудится. Потом очень > геморно - переписывать настройки под 2-10 сайтов, которые он каким-то > образом дропнул. > > Так что в каком-то странном мире Вы живете. Я бы резюмировал бы так - дайте возможность вносить многострочные комментарии From denis at webmaster.spb.ru Thu Mar 28 13:50:07 2013 From: denis at webmaster.spb.ru (denis) Date: Thu, 28 Mar 2013 17:50:07 +0400 Subject: Request Entity Too Large In-Reply-To: References: <515355CD.3050900@kpi.ua> <5153665A.5010104@kpi.ua> <20130327223803.GM62550@mdounin.ru> <51541A75.8000902@webmaster.spb.ru> <20130328120355.GR62550@mdounin.ru> <515445B2.3010009@webmaster.spb.ru> Message-ID: <51544A8F.9080208@webmaster.spb.ru> 28.03.2013 17:34, Aleksandr Sytar пишет: > Я бы резюмировал бы так - дайте возможность вносить многострочные комментарии Частично закроет только 1 проблему из всех перечисленных. Опять же, сложно автоматизировать "отключить основной сайт и его 5 алиасов", особенно когда алиасы раскиданы по конфигу и каждый надо комментировать отдельно. И снова это будет хитрый скрипт с недельной отладкой и потенциальными багами. При том, что задача решается просто вынесением сайтов по файлам, возникает вопрос: нахрена козе баян? (зачем так извращаться?) И вообще. Ну не определен порядок. Так у нас сами сайты и не пересекаются, и не имеет значения, в каком порядке считаются они из конфига, смотреться будет по макс совпадению. Проблема может быть только с независимыми поддоменами, но опять же, если смотрится по макс совпадению (даже в регэкспах) - проблем там немного. Если без регэкспов - просто поддомен описать в том же файле, что и сам домен, просто выше, и дальше домен можно хоть как * описывать - работает всё. С регэкспами чуть сложнее, да, но понять как они обрабатываются и учитывать при написании конфига. From onokonem at gmail.com Thu Mar 28 13:52:54 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 28 Mar 2013 17:52:54 +0400 Subject: Request Entity Too Large In-Reply-To: <20130328120355.GR62550@mdounin.ru> References: <515355CD.3050900@kpi.ua> <5153665A.5010104@kpi.ua> <20130327223803.GM62550@mdounin.ru> <51541A75.8000902@webmaster.spb.ru> <20130328120355.GR62550@mdounin.ru> Message-ID: > При этом директива include - не гарантирует какой-либо порядок > включения файлов при использовании масок, что плохо отражается на Вот это сюрприз! Может быть - сделаете нам гарантию алфавитного порядка? Хотите - я feature request в track оформлю? :) From vbart at nginx.com Thu Mar 28 14:45:03 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 28 Mar 2013 18:45:03 +0400 Subject: =?UTF-8?B?UmU6INC90LXQsdC70L7QutC40YDRg9GO0YnQuNC5INCw0L/Qu9C+0LDQtA==?= In-Reply-To: References: Message-ID: <201303281845.03613.vbart@nginx.com> On Thursday 28 March 2013 16:34:21 Anatoly Mikhailov wrote: > Вопрос по неблокирующему аплоаду больших файлов, в идеале без необходимости > использовать проксирование на upstream. > > 2 варианта: > 1) nginx-upload-module > 2) lua-resty-upload > > Первый поломался с выходом nginx 1.3.9 > https://github.com/vkholodkov/nginx-upload-module/issues/41 Второй требует > 2 дополнительных модуля (devkit, lua), но еще не production-ready > > Что выбрать? > Пользоваться штатными средствами. http://nginx.org/r/client_body_in_file_only/ru -- Валентин Бартенев http://nginx.org/en/donation.html From vbart at nginx.com Thu Mar 28 14:50:30 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 28 Mar 2013 18:50:30 +0400 Subject: Request Entity Too Large In-Reply-To: References: <515355CD.3050900@kpi.ua> <20130328120355.GR62550@mdounin.ru> Message-ID: <201303281850.30086.vbart@nginx.com> On Thursday 28 March 2013 17:52:54 Daniel Podolsky wrote: > > При этом директива include - не гарантирует какой-либо порядок > > включения файлов при использовании масок, что плохо отражается на > > Вот это сюрприз! Может быть - сделаете нам гарантию алфавитного порядка? > > Хотите - я feature request в track оформлю? :) http://nginx.org/ru/CHANGES.ru 1.3.10: *) Изменение: теперь при использовании директивы include с маской на Unix-системах включаемые файлы сортируются в алфавитном порядке. -- Валентин Бартенев http://nginx.org/en/donation.html From mdounin at mdounin.ru Thu Mar 28 15:02:00 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 28 Mar 2013 19:02:00 +0400 Subject: Request Entity Too Large In-Reply-To: References: <515355CD.3050900@kpi.ua> <5153665A.5010104@kpi.ua> <20130327223803.GM62550@mdounin.ru> <51541A75.8000902@webmaster.spb.ru> <20130328120355.GR62550@mdounin.ru> Message-ID: <20130328150159.GU62550@mdounin.ru> Hello! On Thu, Mar 28, 2013 at 05:52:54PM +0400, Daniel Podolsky wrote: > > При этом директива include - не гарантирует какой-либо порядок > > включения файлов при использовании масок, что плохо отражается на > Вот это сюрприз! Может быть - сделаете нам гарантию алфавитного порядка? > > Хотите - я feature request в track оформлю? :) Нет. (c) Фарид Вагапов Занафига мне те feature request'ы без патчей? :) Если быть совсем точным, то на UNIX-системах начиная с 1.3.10+ / 1.2.7+ сортировка таки делается. Но например на win32 - поведение будет зависеть от файловой системы. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Mar 28 15:20:11 2013 From: nginx-forum at nginx.us (Nikem) Date: Thu, 28 Mar 2013 11:20:11 -0400 Subject: nginx-1.3.15 In-Reply-To: <51541F86.7000709@nginx.com> References: <51541F86.7000709@nginx.com> Message-ID: <6a1c25802d61050a65af6140cb79e0d0.NginxMailingListRussian@forum.nginx.org> И вот тут: http://wiki.nginx.org/Install#Development , по-прежнему ссылка на версию 1.3.10. Можно бы обновить :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237805,237908#msg-237908 From mdounin at mdounin.ru Thu Mar 28 15:29:30 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 28 Mar 2013 19:29:30 +0400 Subject: Request Entity Too Large In-Reply-To: <515445B2.3010009@webmaster.spb.ru> References: <515355CD.3050900@kpi.ua> <5153665A.5010104@kpi.ua> <20130327223803.GM62550@mdounin.ru> <51541A75.8000902@webmaster.spb.ru> <20130328120355.GR62550@mdounin.ru> <515445B2.3010009@webmaster.spb.ru> Message-ID: <20130328152930.GV62550@mdounin.ru> Hello! On Thu, Mar 28, 2013 at 05:29:22PM +0400, denis wrote: > 28.03.2013 16:03, Maxim Dounin пишет: > >При этом директива include - не гарантирует какой-либо порядок > >включения файлов при использовании масок, что плохо отражается на > >работоспособности конфигов, использующих директиву include для > >включения множества блоков server{} и при этом не использующих > >параметр default_server директивы listen. > При чём тут вообще default_server? У меня он задаётся в отдельном > конфиге, 000_default, и с этим проблем нет. Тогда в чём ваша проблема с "первым видело основной блок и привет"? Если включаемые файлы написаны корректно, то они не должны зависеть от порядка включения. > >Очевидных решений два: > > > >1) Не использовать include "вида sites/*". Вообще конфигурить > >nginx одним файлом - гораздо приятнее и удобнее, а главное - > >понятнее, особенно новичкам. > Ага. Особенно когда сайтов не 1-2, а десятков 5, причём конфигурация > типовая. Плюс на каждый - ещё пяток server-секций, с редиректами на > основной сайт. И теперь представим, что нам надо отключить 1 сайт с > его редиректами-алиасами. Автоматом (не ручками). В случае с conf/* Задача автического управления большими конфигами - она 1) совсем отдельная, 2) файликами всё равно полноценно не решается, и 3) от использования или не использования "include *" никак не зависит, т.к. скрипту всё равно, что сделать на выходе. В то же время, плач на тему "у меня ничего не работает" - сводящийся к тому, что кривой конфиг получился из-за использования вопрошающим "include *" - я тут наблюдаю с поразительной регулярностью уже который год. Так что несмотря на все кажущиеся достоинства "include *" - я крайне негативно отношусь к этому механизму. [...] > >Может быть, но в ситуации, когда порядок вообще говоря не > >определён - подобный вывод только собъёт с толку. > Он покажет, как нгинх распарсил конфиги, в каком порядке загрузил файлы итд. Чем вам поможет порядок, в котором nginx загрузил файлы в этот раз, если в следующий раз - этот порядок вполне может быть другим? -- Maxim Dounin http://nginx.org/en/donation.html From anatoly at sonru.com Thu Mar 28 16:19:47 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Thu, 28 Mar 2013 16:19:47 +0000 Subject: =?UTF-8?B?UmU6INC90LXQsdC70L7QutC40YDRg9GO0YnQuNC5INCw0L/Qu9C+0LDQtA==?= In-Reply-To: <201303281845.03613.vbart@nginx.com> References: <201303281845.03613.vbart@nginx.com> Message-ID: <9523D230-36B7-4D4E-B3E7-71AA4EFF3E8E@sonru.com> On Mar 28, 2013, at 2:45 PM, Валентин Бартенев wrote: > On Thursday 28 March 2013 16:34:21 Anatoly Mikhailov wrote: >> Вопрос по неблокирующему аплоаду больших файлов, в идеале без необходимости >> использовать проксирование на upstream. >> >> 2 варианта: >> 1) nginx-upload-module >> 2) lua-resty-upload >> >> Первый поломался с выходом nginx 1.3.9 >> https://github.com/vkholodkov/nginx-upload-module/issues/41 Второй требует >> 2 дополнительных модуля (devkit, lua), но еще не production-ready >> >> Что выбрать? >> > > Пользоваться штатными средствами. > > http://nginx.org/r/client_body_in_file_only/ru уже почти готов это взять это в продакшн, но не хватает примеров и подробной документации, погуглил, ничего не нашел... > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Thu Mar 28 16:20:28 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 28 Mar 2013 20:20:28 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBuZ2lueC93aW4zMg==?= In-Reply-To: References: <20130326112719.GM62550@mdounin.ru> <20130326120818.GN62550@mdounin.ru> <20130327122034.GY62550@mdounin.ru> <20130327133853.GA62550@mdounin.ru> Message-ID: <20130328162028.GW62550@mdounin.ru> Hello! On Thu, Mar 28, 2013 at 06:03:05PM +0600, Илья Шипицин wrote: > Добрый день! > > поправил 0 --> TRUE в WaitForMultipleObjects, чтобы дождаться > завершения всех потомков, патч: > > --- src/os/win32/ngx_process_cycle.c.orig 2013-03-27 > 09:53:48.000000000 +0600 > +++ src/os/win32/ngx_process_cycle.c 2013-03-28 17:58:49.000000000 +0600 > @@ -303,7 +303,10 @@ > ngx_console_handler(u_long type) > { > char *msg; > - > + ngx_int_t n; > + u_long nev, timeout, ev; > + HANDLE events[MAXIMUM_WAIT_OBJECTS]; > + > switch (type) { > > case CTRL_C_EVENT: > @@ -337,6 +340,18 @@ > "SetEvent(\"%s\") failed", ngx_stop_event_name); > } > > + nev = 0; > + for (n = 0; n < ngx_last_process; n++) { > + if (ngx_processes[n].handle) { > + events[nev++] = ngx_processes[n].handle; > + } > + } > + > + if(nev != 0){ > + timeout = INFINITE; > + ev = WaitForMultipleObjects(nev, events, TRUE, timeout); > + } > + > return 1; > } Насколько я понимаю, так может быть больно, если основной тред мастера таки успеет закрыть event'ы раньше, чем мы их попытаемся использовать. Я бы строил нормальную синхронизацию именно с завершением основного треда мастера (а тот, в свою очередь, пусть дожидается всех остальных - как он, собственно, и сейчас делает). -- Maxim Dounin http://nginx.org/en/donation.html From vbart at nginx.com Thu Mar 28 16:42:50 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 28 Mar 2013 20:42:50 +0400 Subject: =?UTF-8?B?UmU6INC90LXQsdC70L7QutC40YDRg9GO0YnQuNC5INCw0L/Qu9C+0LDQtA==?= In-Reply-To: <9523D230-36B7-4D4E-B3E7-71AA4EFF3E8E@sonru.com> References: <201303281845.03613.vbart@nginx.com> <9523D230-36B7-4D4E-B3E7-71AA4EFF3E8E@sonru.com> Message-ID: <201303282042.50238.vbart@nginx.com> On Thursday 28 March 2013 20:19:47 Anatoly Mikhailov wrote: > On Mar 28, 2013, at 2:45 PM, Валентин Бартенев wrote: > > On Thursday 28 March 2013 16:34:21 Anatoly Mikhailov wrote: > >> Вопрос по неблокирующему аплоаду больших файлов, в идеале без > >> необходимости использовать проксирование на upstream. > >> > >> 2 варианта: > >> 1) nginx-upload-module > >> 2) lua-resty-upload > >> > >> Первый поломался с выходом nginx 1.3.9 > >> https://github.com/vkholodkov/nginx-upload-module/issues/41 Второй > >> требует 2 дополнительных модуля (devkit, lua), но еще не > >> production-ready > >> > >> Что выбрать? > > > > Пользоваться штатными средствами. > > > > http://nginx.org/r/client_body_in_file_only/ru > > уже почти готов это взять это в продакшн, но не хватает примеров > и подробной документации, погуглил, ничего не нашел... > Хорошо бы хоть примерное описание того, что требуется. Что подразумевается под "неблокирующий аплоад" мне лишь удалось догадаться из перечисленных модулей. Использовать client_body_in_file_only очень просто. Включаете (on или clean) и далее у вас в переменной $request_body_file путь к загруженному файлу. Что с этим файлом делать - решать вам. Типичный сценарий - передать путь на бэкенд, чтобы тот переместил файл в хранилище и добавил запись об этом в БД. -- Валентин Бартенев http://nginx.org/en/donation.html From postmaster at softsearch.ru Thu Mar 28 16:45:42 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 28 Mar 2013 20:45:42 +0400 Subject: =?UTF-8?B?UmVbMl06INC90LXQsdC70L7QutC40YDRg9GO0YnQuNC5INCw0L/Qu9C+0LDQtA==?= In-Reply-To: <201303282042.50238.vbart@nginx.com> References: <201303281845.03613.vbart@nginx.com> <9523D230-36B7-4D4E-B3E7-71AA4EFF3E8E@sonru.com> <201303282042.50238.vbart@nginx.com> Message-ID: <12910152983.20130328204542@softsearch.ru> Здравствуйте, Валентин. > Хорошо бы хоть примерное описание того, что требуется. Что подразумевается под > "неблокирующий аплоад" мне лишь удалось догадаться из перечисленных модулей. Видимо имелось ввиду информировать юзверя о ходе закачки. -- С уважением, Михаил mailto:postmaster at softsearch.ru From vbart at nginx.com Thu Mar 28 16:54:51 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 28 Mar 2013 20:54:51 +0400 Subject: =?UTF-8?B?UmU6INC90LXQsdC70L7QutC40YDRg9GO0YnQuNC5INCw0L/Qu9C+0LDQtA==?= In-Reply-To: <12910152983.20130328204542@softsearch.ru> References: <201303282042.50238.vbart@nginx.com> <12910152983.20130328204542@softsearch.ru> Message-ID: <201303282054.51312.vbart@nginx.com> On Thursday 28 March 2013 20:45:42 Михаил Монашёв wrote: > Здравствуйте, Валентин. > > > Хорошо бы хоть примерное описание того, что требуется. Что > > подразумевается под "неблокирующий аплоад" мне лишь удалось догадаться > > из перечисленных модулей. > > Видимо имелось ввиду информировать юзверя о ходе закачки. Но "nginx-upload-module" этого не умеет. Информировать юзверя нужно с помощью XMLHttpRequest2, и не морочить себе голову. -- Валентин Бартенев http://nginx.org/en/donation.html From a.vasilishin at kpi.ua Thu Mar 28 17:52:30 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Thu, 28 Mar 2013 19:52:30 +0200 Subject: Request Entity Too Large In-Reply-To: <20130328113433.GQ62550@mdounin.ru> References: <515355CD.3050900@kpi.ua> <5153665A.5010104@kpi.ua> <20130327223803.GM62550@mdounin.ru> <515405B9.4050603@kpi.ua> <20130328113433.GQ62550@mdounin.ru> Message-ID: <5154835E.2030106@kpi.ua> Дико извиняюсь! Аж самому стало стыдно и немного интересно, как оно работало раньше. В общем было еще include /etc/nginx/sites-enabled/*; это уже когда от безысходности начал приводить конфиг к общему виду (как на других серверах) дописал машинально .conf и отправил строку с инклюдом в самый низ http {} а в директории /etc/nginx/sites-enabled/ лежал старый конфиг с расширением conf.1 в котором client_max_body_size 10m; и в нем же есть server_name _default куда, как я присмотрелся еще раз в логи, и попал запрос. 2013/03/27 22:18:13 [notice] 26193#0: *6484 a client request body is buffered to a temporary file /tmp/0000005612, client: 10.0.0.5, server: _default, request: "POST /encoder2/ajax/update/coding-files/ HTTP/1.1", host: "10.0.0.12", referrer: "http://10.0.0.12/encoder2/" Ради эксперимента перенес назад (над client_max_body_size 2048m; ) строку include /etc/nginx/sites-enabled/*.conf; и сделал рестарт, все работает никаких ошибок не выдает. Еще раз извиняюсь за излишнюю панику. From ano at bestmx.ru Thu Mar 28 19:54:48 2013 From: ano at bestmx.ru (Andrey N. Oktyabrski) Date: Thu, 28 Mar 2013 23:54:48 +0400 Subject: =?UTF-8?B?UmU6INC90LXQsdC70L7QutC40YDRg9GO0YnQuNC5INCw0L/Qu9C+0LDQtA==?= In-Reply-To: <201303281845.03613.vbart@nginx.com> References: <201303281845.03613.vbart@nginx.com> Message-ID: <5154A008.5060701@bestmx.ru> On 28.03.2013 18:45, Валентин Бартенев wrote: > On Thursday 28 March 2013 16:34:21 Anatoly Mikhailov wrote: >> Вопрос по неблокирующему аплоаду больших файлов, в идеале без необходимости >> использовать проксирование на upstream. >> >> 2 варианта: >> 1) nginx-upload-module >> 2) lua-resty-upload >> >> Первый поломался с выходом nginx 1.3.9 >> https://github.com/vkholodkov/nginx-upload-module/issues/41 Второй требует >> 2 дополнительных модуля (devkit, lua), но еще не production-ready >> >> Что выбрать? > > Пользоваться штатными средствами. > > http://nginx.org/r/client_body_in_file_only/ru Вот бы штатными средствами было вот это реализовано, так можно было бы и пользоваться: http://www.grid.net.ru/nginx/resumable_uploads.ru.html From vbart at nginx.com Thu Mar 28 20:30:17 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 29 Mar 2013 00:30:17 +0400 Subject: =?UTF-8?B?UmU6INC90LXQsdC70L7QutC40YDRg9GO0YnQuNC5INCw0L/Qu9C+0LDQtA==?= In-Reply-To: <5154A008.5060701@bestmx.ru> References: <201303281845.03613.vbart@nginx.com> <5154A008.5060701@bestmx.ru> Message-ID: <201303290030.17949.vbart@nginx.com> On Thursday 28 March 2013 23:54:48 Andrey N. Oktyabrski wrote: > On 28.03.2013 18:45, Валентин Бартенев wrote: > > On Thursday 28 March 2013 16:34:21 Anatoly Mikhailov wrote: > >> Вопрос по неблокирующему аплоаду больших файлов, в идеале без > >> необходимости использовать проксирование на upstream. > >> > >> 2 варианта: > >> 1) nginx-upload-module > >> 2) lua-resty-upload > >> > >> Первый поломался с выходом nginx 1.3.9 > >> https://github.com/vkholodkov/nginx-upload-module/issues/41 Второй > >> требует 2 дополнительных модуля (devkit, lua), но еще не > >> production-ready > >> > >> Что выбрать? > > > > Пользоваться штатными средствами. > > > > http://nginx.org/r/client_body_in_file_only/ru > > Вот бы штатными средствами было вот это реализовано, так можно было бы и > пользоваться: > http://www.grid.net.ru/nginx/resumable_uploads.ru.html > Сделать всякого можно, был бы только спрос. -- Валентин Бартенев http://nginx.org/en/donation.html From denis at webmaster.spb.ru Thu Mar 28 20:52:50 2013 From: denis at webmaster.spb.ru (denis) Date: Fri, 29 Mar 2013 00:52:50 +0400 Subject: Request Entity Too Large In-Reply-To: <20130328152930.GV62550@mdounin.ru> References: <515355CD.3050900@kpi.ua> <5153665A.5010104@kpi.ua> <20130327223803.GM62550@mdounin.ru> <51541A75.8000902@webmaster.spb.ru> <20130328120355.GR62550@mdounin.ru> <515445B2.3010009@webmaster.spb.ru> <20130328152930.GV62550@mdounin.ru> Message-ID: <5154ADA2.7020106@webmaster.spb.ru> 28.03.2013 19:29, Maxim Dounin пишет: > Hello! > > On Thu, Mar 28, 2013 at 05:29:22PM +0400, denis wrote: > >> 28.03.2013 16:03, Maxim Dounin пишет: >>> При этом директива include - не гарантирует какой-либо порядок >>> включения файлов при использовании масок, что плохо отражается на >>> работоспособности конфигов, использующих директиву include для >>> включения множества блоков server{} и при этом не использующих >>> параметр default_server директивы listen. >> При чём тут вообще default_server? У меня он задаётся в отдельном >> конфиге, 000_default, и с этим проблем нет. > Тогда в чём ваша проблема с "первым видело основной блок и > привет"? основной блок == основной домен... то есть описываем site.ru www.site.ru, и им же захватывало прочие поддомены этого домена. Подробнее уже не скажу, год+ прошёл. Возможно просто баг был. > Задача автического управления большими конфигами - она 1) совсем > отдельная, 2) файликами всё равно полноценно не решается, и 3) от > использования или не использования "include *" никак не зависит, > т.к. скрипту всё равно, что сделать на выходе. 2 - а чем решается? > В то же время, плач на тему "у меня ничего не работает" - > сводящийся к тому, что кривой конфиг получился из-за использования > вопрошающим "include *" - я тут наблюдаю с поразительной > регулярностью уже который год. Там все ошибки -- невнимательность/непонимание пользователей, что в итоге и выясняется. Но сильно мешает отладке отсутствие вменяемого конфтеста + вывода, какой (под)домен в каком конфиге и на какой строке начинает описание, а-ля апач хотя бы. Плюс полный листинг итоговой конфигурации помогает увидеть "нежданчика" в виде установленной переменной/локейшена/итд там, где его никто не ждал. В любом случае механизм инклудов нужный, но требует аккуратности, да. Именно поэтому я предпочитаю, когда всё по файлам, всё проверено и генерируется автоматически + контроль версий. Почти все проблемы - человеческий фактор, и без него сюрпризов почти не бывает (поэтому и указываю так на sed и проблемы скриптования изменений). >> Он покажет, как нгинх распарсил конфиги, в каком порядке загрузил файлы итд. > Чем вам поможет порядок, в котором nginx загрузил файлы в этот > раз, если в следующий раз - этот порядок вполне может быть другим? Просто так порядок сам не изменится. Опять же, делаем полный листинг, сверяем с ожиданиями, и в идеале с тем, что было до этого. From anatoly at sonru.com Thu Mar 28 23:08:14 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Thu, 28 Mar 2013 23:08:14 +0000 Subject: =?UTF-8?B?UmU6INC90LXQsdC70L7QutC40YDRg9GO0YnQuNC5INCw0L/Qu9C+0LDQtA==?= In-Reply-To: <201303290030.17949.vbart@nginx.com> References: <201303281845.03613.vbart@nginx.com> <5154A008.5060701@bestmx.ru> <201303290030.17949.vbart@nginx.com> Message-ID: On Mar 28, 2013, at 8:30 PM, Валентин Бартенев wrote: > On Thursday 28 March 2013 23:54:48 Andrey N. Oktyabrski wrote: >> On 28.03.2013 18:45, Валентин Бартенев wrote: >>> On Thursday 28 March 2013 16:34:21 Anatoly Mikhailov wrote: >>>> Вопрос по неблокирующему аплоаду больших файлов, в идеале без >>>> необходимости использовать проксирование на upstream. >>>> >>>> 2 варианта: >>>> 1) nginx-upload-module >>>> 2) lua-resty-upload >>>> >>>> Первый поломался с выходом nginx 1.3.9 >>>> https://github.com/vkholodkov/nginx-upload-module/issues/41 Второй >>>> требует 2 дополнительных модуля (devkit, lua), но еще не >>>> production-ready >>>> >>>> Что выбрать? >>> >>> Пользоваться штатными средствами. >>> >>> http://nginx.org/r/client_body_in_file_only/ru >> >> Вот бы штатными средствами было вот это реализовано, так можно было бы и >> пользоваться: >> http://www.grid.net.ru/nginx/resumable_uploads.ru.html >> > > Сделать всякого можно, был бы только спрос. если хорошо задокументировать, то спрос будет обязательно, погуглив, можно только найти nginx_upload_module и lua модуль, но про client_body_in_file так просто не найдешь, хотя если покопать: - http://forum.nginx.org/read.php?2,223189,223198#msg-223198 - http://forum.nginx.org/read.php?2,227175,227177 - http://mailman.nginx.org/pipermail/nginx/2012-September/035447.html кстати, сейчас тестируем штатное решение - это то, что нужно, спасибо! > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vas at mpeks.tomsk.su Fri Mar 29 02:16:37 2013 From: vas at mpeks.tomsk.su (Victor Sudakov) Date: Fri, 29 Mar 2013 09:16:37 +0700 Subject: nginx as TCP proxy In-Reply-To: <20130327090716.GE89105@lo0.su> References: <20130326132351.GA64530@admin.sibptus.tomsk.ru> <20130327090716.GE89105@lo0.su> Message-ID: <20130329021637.GA57625@admin.sibptus.tomsk.ru> Ruslan Ermilov wrote: [dd] > > Однако, порт FreeBSD использует версию 0.26 этого модуля, > которой уже 10 месяцев: > https://github.com/yaoweibin/nginx_tcp_proxy_module/tags > > Правильная последовательность действий видимо такая: > > - попросить автора модуля (Weibin Yao ) выпустить > новую версию модуля; > > - попросить ответственного за порт www/nginx-devel обновить порт. Спасибо за пояснение. Weibin Yao сказал, "Can you fetch the latest tcp proxy module? This bug should be fixed in the latest revision." Не буду ждать, когда в портах появится latest revision, попробую лучше haproxy. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov at sibptus.tomsk.ru From ano at bestmx.ru Fri Mar 29 03:21:24 2013 From: ano at bestmx.ru (Andrey N. Oktyabrski) Date: Fri, 29 Mar 2013 07:21:24 +0400 Subject: resumable upload In-Reply-To: <201303290030.17949.vbart@nginx.com> References: <201303281845.03613.vbart@nginx.com> <5154A008.5060701@bestmx.ru> <201303290030.17949.vbart@nginx.com> Message-ID: <515508B4.9040202@bestmx.ru> On 29.03.2013 00:30, Валентин Бартенев wrote: >>> Пользоваться штатными средствами. >>> >>> http://nginx.org/r/client_body_in_file_only/ru >> >> Вот бы штатными средствами было вот это реализовано, так можно было бы и >> пользоваться: >> http://www.grid.net.ru/nginx/resumable_uploads.ru.html > > Сделать всякого можно, был бы только спрос. А сколько человек можно назвать спросом? :-) Вот мне надо, один уже есть. У нас таким образом приложение со смартфона на сервер грузит большие файлы. From dedukhin at mail.ru Fri Mar 29 05:39:35 2013 From: dedukhin at mail.ru (Dmitry Dedukhin) Date: Fri, 29 Mar 2013 09:39:35 +0400 Subject: =?UTF-8?B?UmU6INC90LXQsdC70L7QutC40YDRg9GO0YnQuNC5INCw0L/Qu9C+0LDQtA==?= In-Reply-To: References: <201303281845.03613.vbart@nginx.com> <5154A008.5060701@bestmx.ru> <201303290030.17949.vbart@nginx.com> Message-ID: <51552917.8080100@mail.ru> 29.03.2013 3:08, Anatoly Mikhailov пишет: > On Mar 28, 2013, at 8:30 PM, Валентин Бартенев wrote: > >> On Thursday 28 March 2013 23:54:48 Andrey N. Oktyabrski wrote: >>> On 28.03.2013 18:45, Валентин Бартенев wrote: >>>> On Thursday 28 March 2013 16:34:21 Anatoly Mikhailov wrote: >>>>> Вопрос по неблокирующему аплоаду больших файлов, в идеале без >>>>> необходимости использовать проксирование на upstream. >>>>> >>>>> 2 варианта: >>>>> 1) nginx-upload-module >>>>> 2) lua-resty-upload >>>>> >>>>> Первый поломался с выходом nginx 1.3.9 >>>>> https://github.com/vkholodkov/nginx-upload-module/issues/41 Второй >>>>> требует 2 дополнительных модуля (devkit, lua), но еще не >>>>> production-ready >>>>> >>>>> Что выбрать? >>>> Пользоваться штатными средствами. >>>> >>>> http://nginx.org/r/client_body_in_file_only/ru >>> Вот бы штатными средствами было вот это реализовано, так можно было бы и >>> пользоваться: >>> http://www.grid.net.ru/nginx/resumable_uploads.ru.html >>> >> Сделать всякого можно, был бы только спрос. > если хорошо задокументировать, то спрос будет обязательно, > погуглив, можно только найти nginx_upload_module и lua модуль, > но про client_body_in_file так просто не найдешь, хотя если покопать: > - http://forum.nginx.org/read.php?2,223189,223198#msg-223198 > - http://forum.nginx.org/read.php?2,227175,227177 > - http://mailman.nginx.org/pipermail/nginx/2012-September/035447.html > > кстати, сейчас тестируем штатное решение - это то, что нужно, спасибо! В случае multipart POST запроса и штатного решения бэкенд должен будет распарсить тело запроса из файла, также как и обычно. В случае загрузки большого файла (речь идет про несколько гигабайт) парсинг может занять вполне ощутимое время, в течение которого браузер клиента будет ждать ответа. Помимо всего прочего (подсчет хеш-сумм и возобновляемая загрузка) upload модуль хорош тем, что этот парсинг осуществляет на лету и на бэкенд приходит небольшое тело запроса с уже вычлененным из него файлом, что существенно ускоряет время ответа клиенту и разгружает бэкенд. From igor at sysoev.ru Fri Mar 29 07:09:43 2013 From: igor at sysoev.ru (Igor Sysoev) Date: Fri, 29 Mar 2013 11:09:43 +0400 Subject: Request Entity Too Large In-Reply-To: References: <515355CD.3050900@kpi.ua> <5153665A.5010104@kpi.ua> <20130327223803.GM62550@mdounin.ru> <51541A75.8000902@webmaster.spb.ru> <20130328120355.GR62550@mdounin.ru> <515445B2.3010009@webmaster.spb.ru> Message-ID: <1F222C8B-F3B2-466B-89BF-1A2660733B0D@sysoev.ru> On Mar 28, 2013, at 17:34 , Aleksandr Sytar wrote: > Я бы резюмировал бы так - дайте возможность вносить многострочные комментарии Наверное, это стоит сделать в виде: disable server { ... } disable location /dir/ { ... } и в более общем виде disable { ... } Более короткое слово "off" хуже, потому что его сложно искать - будет совпадений с флагами директив - on/off. -- Igor Sysoev http://nginx.com/services.html From anatoly at sonru.com Fri Mar 29 09:09:42 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Fri, 29 Mar 2013 09:09:42 +0000 Subject: resumable upload In-Reply-To: <515508B4.9040202@bestmx.ru> References: <201303281845.03613.vbart@nginx.com> <5154A008.5060701@bestmx.ru> <201303290030.17949.vbart@nginx.com> <515508B4.9040202@bestmx.ru> Message-ID: On Mar 29, 2013, at 3:21 AM, Andrey N. Oktyabrski wrote: > On 29.03.2013 00:30, Валентин Бартенев wrote: >>>> Пользоваться штатными средствами. >>>> >>>> http://nginx.org/r/client_body_in_file_only/ru >>> >>> Вот бы штатными средствами было вот это реализовано, так можно было бы и >>> пользоваться: >>> http://www.grid.net.ru/nginx/resumable_uploads.ru.html >> >> Сделать всякого можно, был бы только спрос. > А сколько человек можно назвать спросом? :-) Вот мне надо, один уже есть. У нас таким образом приложение со смартфона на сервер грузит большие файлы. > да и что тут говорить, весьма популярный проект с 10K watchers восхваляет nginx_upload_module так как будто это единственное решение > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From anatoly at sonru.com Fri Mar 29 09:10:10 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Fri, 29 Mar 2013 09:10:10 +0000 Subject: resumable upload In-Reply-To: References: <201303281845.03613.vbart@nginx.com> <5154A008.5060701@bestmx.ru> <201303290030.17949.vbart@nginx.com> <515508B4.9040202@bestmx.ru> Message-ID: On Mar 29, 2013, at 9:09 AM, Anatoly Mikhailov wrote: > > On Mar 29, 2013, at 3:21 AM, Andrey N. Oktyabrski wrote: > >> On 29.03.2013 00:30, Валентин Бартенев wrote: >>>>> Пользоваться штатными средствами. >>>>> >>>>> http://nginx.org/r/client_body_in_file_only/ru >>>> >>>> Вот бы штатными средствами было вот это реализовано, так можно было бы и >>>> пользоваться: >>>> http://www.grid.net.ru/nginx/resumable_uploads.ru.html >>> >>> Сделать всякого можно, был бы только спрос. >> А сколько человек можно назвать спросом? :-) Вот мне надо, один уже есть. У нас таким образом приложение со смартфона на сервер грузит большие файлы. >> > > да и что тут говорить, весьма популярный проект с 10K watchers восхваляет > nginx_upload_module так как будто это единственное решение https://github.com/blueimp/jQuery-File-Upload/wiki/Uploading-to-nginx-using-the-nginx-upload-module > >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From anatoly at sonru.com Fri Mar 29 09:27:01 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Fri, 29 Mar 2013 09:27:01 +0000 Subject: =?UTF-8?B?UmU6INC90LXQsdC70L7QutC40YDRg9GO0YnQuNC5INCw0L/Qu9C+0LDQtA==?= In-Reply-To: References: <201303281845.03613.vbart@nginx.com> <5154A008.5060701@bestmx.ru> <201303290030.17949.vbart@nginx.com> Message-ID: <5FFC5D5B-95B3-4579-9306-6450364C021F@sonru.com> On Mar 28, 2013, at 11:08 PM, Anatoly Mikhailov wrote: > > On Mar 28, 2013, at 8:30 PM, Валентин Бартенев wrote: > >> On Thursday 28 March 2013 23:54:48 Andrey N. Oktyabrski wrote: >>> On 28.03.2013 18:45, Валентин Бартенев wrote: >>>> On Thursday 28 March 2013 16:34:21 Anatoly Mikhailov wrote: >>>>> Вопрос по неблокирующему аплоаду больших файлов, в идеале без >>>>> необходимости использовать проксирование на upstream. >>>>> >>>>> 2 варианта: >>>>> 1) nginx-upload-module >>>>> 2) lua-resty-upload >>>>> >>>>> Первый поломался с выходом nginx 1.3.9 >>>>> https://github.com/vkholodkov/nginx-upload-module/issues/41 Второй >>>>> требует 2 дополнительных модуля (devkit, lua), но еще не >>>>> production-ready >>>>> >>>>> Что выбрать? >>>> >>>> Пользоваться штатными средствами. >>>> >>>> http://nginx.org/r/client_body_in_file_only/ru >>> >>> Вот бы штатными средствами было вот это реализовано, так можно было бы и >>> пользоваться: >>> http://www.grid.net.ru/nginx/resumable_uploads.ru.html >>> >> >> Сделать всякого можно, был бы только спрос. > > если хорошо задокументировать, то спрос будет обязательно, > погуглив, можно только найти nginx_upload_module и lua модуль, > но про client_body_in_file так просто не найдешь, хотя если покопать: > - http://forum.nginx.org/read.php?2,223189,223198#msg-223198 > - http://forum.nginx.org/read.php?2,227175,227177 > - http://mailman.nginx.org/pipermail/nginx/2012-September/035447.html > > кстати, сейчас тестируем штатное решение - это то, что нужно, спасибо! > есть возможность отправить POST без multi-part data заголовков с формы, что штатный модуль все правильно распарсил? >> >> -- >> Валентин Бартенев >> http://nginx.org/en/donation.html >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Fri Mar 29 13:02:14 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 29 Mar 2013 17:02:14 +0400 Subject: resumable upload In-Reply-To: <515508B4.9040202@bestmx.ru> References: <201303290030.17949.vbart@nginx.com> <515508B4.9040202@bestmx.ru> Message-ID: <201303291702.14246.vbart@nginx.com> On Friday 29 March 2013 07:21:24 Andrey N. Oktyabrski wrote: > On 29.03.2013 00:30, Валентин Бартенев wrote: > >>> Пользоваться штатными средствами. > >>> > >>> http://nginx.org/r/client_body_in_file_only/ru > >> > >> Вот бы штатными средствами было вот это реализовано, так можно было бы и > >> пользоваться: > >> http://www.grid.net.ru/nginx/resumable_uploads.ru.html > > > > Сделать всякого можно, был бы только спрос. > > А сколько человек можно назвать спросом? :-) Вот мне надо, один уже > есть. У нас таким образом приложение со смартфона на сервер грузит > большие файлы. Просто когда дело заходит о том, что на грамотную реализацию и последующую поддержку этого кода нужно потратить сколько-то человеко-часов, которые должен кто-то оплатить, то часто выясняется, что большинству вопрошающих не очень то оно и нужно было. Счетчиками обычно заведуют тут: http://nginx.com/services.html =) -- Валентин Бартенев http://nginx.org/en/donation.html From vbart at nginx.com Fri Mar 29 13:15:34 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 29 Mar 2013 17:15:34 +0400 Subject: =?UTF-8?B?UmU6INC90LXQsdC70L7QutC40YDRg9GO0YnQuNC5INCw0L/Qu9C+0LDQtA==?= In-Reply-To: <5FFC5D5B-95B3-4579-9306-6450364C021F@sonru.com> References: <5FFC5D5B-95B3-4579-9306-6450364C021F@sonru.com> Message-ID: <201303291715.34502.vbart@nginx.com> On Friday 29 March 2013 13:27:01 Anatoly Mikhailov wrote: > On Mar 28, 2013, at 11:08 PM, Anatoly Mikhailov wrote: > > On Mar 28, 2013, at 8:30 PM, Валентин Бартенев wrote: > >> On Thursday 28 March 2013 23:54:48 Andrey N. Oktyabrski wrote: > >>> On 28.03.2013 18:45, Валентин Бартенев wrote: > >>>> On Thursday 28 March 2013 16:34:21 Anatoly Mikhailov wrote: > >>>>> Вопрос по неблокирующему аплоаду больших файлов, в идеале без > >>>>> необходимости использовать проксирование на upstream. > >>>>> > >>>>> 2 варианта: > >>>>> 1) nginx-upload-module > >>>>> 2) lua-resty-upload > >>>>> > >>>>> Первый поломался с выходом nginx 1.3.9 > >>>>> https://github.com/vkholodkov/nginx-upload-module/issues/41 Второй > >>>>> требует 2 дополнительных модуля (devkit, lua), но еще не > >>>>> production-ready > >>>>> > >>>>> Что выбрать? > >>>> > >>>> Пользоваться штатными средствами. > >>>> > >>>> http://nginx.org/r/client_body_in_file_only/ru > >>> > >>> Вот бы штатными средствами было вот это реализовано, так можно было бы > >>> и пользоваться: > >>> http://www.grid.net.ru/nginx/resumable_uploads.ru.html > >> > >> Сделать всякого можно, был бы только спрос. > > > > если хорошо задокументировать, то спрос будет обязательно, > > погуглив, можно только найти nginx_upload_module и lua модуль, > > но про client_body_in_file так просто не найдешь, хотя если покопать: > > - http://forum.nginx.org/read.php?2,223189,223198#msg-223198 > > - http://forum.nginx.org/read.php?2,227175,227177 > > - http://mailman.nginx.org/pipermail/nginx/2012-September/035447.html > > > > кстати, сейчас тестируем штатное решение - это то, что нужно, спасибо! > > есть возможность отправить POST без multi-part data заголовков с формы, > что штатный модуль все правильно распарсил? > Есть. XMLHttpRequest2 умеет посылать файлы, не оборачивая их, и не кодируя тем или иным образом. Но разумеется если хотите покрыть всех пользователей: http://caniuse.com/#feat=xhr2 то нужен fallback на старый дедовский метод. -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri Mar 29 13:26:52 2013 From: nginx-forum at nginx.us (pioneer32) Date: Fri, 29 Mar 2013 09:26:52 -0400 Subject: =?UTF-8?B?bmdpbngrbWVtY2FjaGVkINC60L7QtCDQvtGC0LLQtdGC0LAg0L7RgtC70LjRh9C9?= =?UTF-8?B?0YvQuSDQvtGCIDIwMCBPSw==?= Message-ID: Всем доброго времени суток. Возникла следующая необходимость заменить код ответа при "попадание в кэш" на "203 Non-Authoritative Information". Вот вырезка из конфига: location = /test/ { memcached_pass 127.0.0.1:11211; error_page 404 502 504 = @fallback_test; add_header Content-Type text/html; return 203; } Дает пустой ответ, даже если ее заменить на return 200 - тело ответа будет пустым. Ответ будет только в случае исключения команды return из данного location. Linux http 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux debian 7.0 nginx version: nginx/1.2.1 Весь мануал вдоль и поперек излазил. Подскажите пожалуйста как это сделать. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237945,237945#msg-237945 From chipitsine at gmail.com Fri Mar 29 13:32:32 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Fri, 29 Mar 2013 19:32:32 +0600 Subject: resumable upload In-Reply-To: <201303291702.14246.vbart@nginx.com> References: <201303290030.17949.vbart@nginx.com> <515508B4.9040202@bestmx.ru> <201303291702.14246.vbart@nginx.com> Message-ID: а расскажите в двух словах, почему надо аплоады именно на nginx-е делать, а например не на php в режиме fastcgi ? 29 марта 2013 г., 19:02 пользователь Валентин Бартенев написал: > On Friday 29 March 2013 07:21:24 Andrey N. Oktyabrski wrote: >> On 29.03.2013 00:30, Валентин Бартенев wrote: >> >>> Пользоваться штатными средствами. >> >>> >> >>> http://nginx.org/r/client_body_in_file_only/ru >> >> >> >> Вот бы штатными средствами было вот это реализовано, так можно было бы и >> >> пользоваться: >> >> http://www.grid.net.ru/nginx/resumable_uploads.ru.html >> > >> > Сделать всякого можно, был бы только спрос. >> >> А сколько человек можно назвать спросом? :-) Вот мне надо, один уже >> есть. У нас таким образом приложение со смартфона на сервер грузит >> большие файлы. > > Просто когда дело заходит о том, что на грамотную реализацию и последующую > поддержку этого кода нужно потратить сколько-то человеко-часов, которые должен > кто-то оплатить, то часто выясняется, что большинству вопрошающих не очень то > оно и нужно было. > > Счетчиками обычно заведуют тут: http://nginx.com/services.html =) > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From maksim at woyager.ru Fri Mar 29 13:56:47 2013 From: maksim at woyager.ru (Maksim Anfilatov) Date: Fri, 29 Mar 2013 17:56:47 +0400 Subject: =?UTF-8?B?UmU6IG5naW54K21lbWNhY2hlZCDQutC+0LQg0L7RgtCy0LXRgtCwINC+0YLQu9C4?= =?UTF-8?B?0YfQvdGL0Lkg0L7RgiAyMDAgT0s=?= In-Reply-To: References: Message-ID: Memcached модуль умеет возвращать только 200 и 404 коды. Return работает независимо от memcached. 29.03.2013 17:27 пользователь "pioneer32" написал: > Всем доброго времени суток. > > Возникла следующая необходимость заменить код ответа при "попадание в кэш" > на "203 Non-Authoritative Information". > > Вот вырезка из конфига: > > location = /test/ { > memcached_pass 127.0.0.1:11211; > error_page 404 502 504 = @fallback_test; > add_header Content-Type text/html; > return 203; > } > > Дает пустой ответ, даже если ее заменить на return 200 - тело ответа будет > пустым. Ответ будет только в случае исключения команды return из данного > location. > > Linux http 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux > debian 7.0 > nginx version: nginx/1.2.1 > > Весь мануал вдоль и поперек излазил. > Подскажите пожалуйста как это сделать. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,237945,237945#msg-237945 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Fri Mar 29 14:48:01 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 29 Mar 2013 18:48:01 +0400 Subject: resumable upload In-Reply-To: References: <201303291702.14246.vbart@nginx.com> Message-ID: <201303291848.01999.vbart@nginx.com> On Friday 29 March 2013 17:32:32 Илья Шипицин wrote: > а расскажите в двух словах, почему надо аплоады именно на nginx-е > делать, а например не на php в режиме fastcgi ? > Люди хотят экономить ресурсы, не прокачивать файлы лишний через сокет и php. А если файл очень большой, то операция: сбросить тело в файл на диск -> прочитать его -> отправить в сокет -> получить на той стороне -> опять записать на диск - может быть слишком ресурсоёмкой. -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri Mar 29 17:38:12 2013 From: nginx-forum at nginx.us (pioneer32) Date: Fri, 29 Mar 2013 13:38:12 -0400 Subject: =?UTF-8?B?UmU6IG5naW54K21lbWNhY2hlZCDQutC+0LQg0L7RgtCy0LXRgtCwINC+0YLQu9C4?= =?UTF-8?B?0YfQvdGL0Lkg0L7RgiAyMDAgT0s=?= In-Reply-To: References: Message-ID: <20503d2b36a09e8635cf6df06192e684.NginxMailingListRussian@forum.nginx.org> Благодярю за ответ. В принципе про 200 и 404 (и 500-е при ошибках) из мемкешеда я уже экспериментальным путем понял. Про независимость return - понятно Maksim Anfilatov Wrote: ------------------------------------------------------- > Memcached модуль умеет возвращать только 200 и 404 коды. > Return работает независимо от memcached. > 29.03.2013 17:27 пользователь "pioneer32" > написал: > > > Всем доброго времени суток. > > > > Возникла следующая необходимость заменить код ответа при "попадание > в кэш" > > на "203 Non-Authoritative Information". > > > > Вот вырезка из конфига: > > > > location = /test/ { > > memcached_pass 127.0.0.1:11211; > > error_page 404 502 504 = @fallback_test; > > add_header Content-Type text/html; > > return 203; > > } > > > > Дает пустой ответ, даже если ее заменить на return 200 - тело ответа > будет > > пустым. Ответ будет только в случае исключения команды return из > данного > > location. > > > > Linux http 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux > > debian 7.0 > > nginx version: nginx/1.2.1 > > > > Весь мануал вдоль и поперек излазил. > > Подскажите пожалуйста как это сделать. > > > > Posted at Nginx Forum: > > http://forum.nginx.org/read.php?21,237945,237945#msg-237945 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237945,237960#msg-237960 From ano at bestmx.ru Fri Mar 29 19:38:53 2013 From: ano at bestmx.ru (Andrey N. Oktyabrski) Date: Fri, 29 Mar 2013 23:38:53 +0400 Subject: resumable upload In-Reply-To: <201303291702.14246.vbart@nginx.com> References: <201303290030.17949.vbart@nginx.com> <515508B4.9040202@bestmx.ru> <201303291702.14246.vbart@nginx.com> Message-ID: <5155EDCD.20102@bestmx.ru> On 29.03.2013 17:02, Валентин Бартенев wrote: > Просто когда дело заходит о том, что на грамотную реализацию и последующую > поддержку этого кода нужно потратить сколько-то человеко-часов, которые должен > кто-то оплатить, то часто выясняется, что большинству вопрошающих не очень то > оно и нужно было. Большинство вопрошающих вполне устраивал upload_module. P.S. Пожалуй, это тупиковая ветвь дискуссии. From anatoly at sonru.com Fri Mar 29 22:46:00 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Fri, 29 Mar 2013 22:46:00 +0000 Subject: resumable upload In-Reply-To: <5155EDCD.20102@bestmx.ru> References: <201303290030.17949.vbart@nginx.com> <515508B4.9040202@bestmx.ru> <201303291702.14246.vbart@nginx.com> <5155EDCD.20102@bestmx.ru> Message-ID: <9CEAD2FD-1F6F-49B4-AC02-347146BEA4F3@sonru.com> On Mar 29, 2013, at 7:38 PM, Andrey N. Oktyabrski wrote: > On 29.03.2013 17:02, Валентин Бартенев wrote: >> Просто когда дело заходит о том, что на грамотную реализацию и последующую >> поддержку этого кода нужно потратить сколько-то человеко-часов, которые должен >> кто-то оплатить, то часто выясняется, что большинству вопрошающих не очень то >> оно и нужно было. > Большинство вопрошающих вполне устраивал upload_module. > > P.S. Пожалуй, это тупиковая ветвь дискуссии. тупиковая, он поломался с nginx 1.3.9, а автор этого плагина забил на поддержку уже как полгода. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Sat Mar 30 07:39:46 2013 From: nginx-forum at nginx.us (dest) Date: Sat, 30 Mar 2013 03:39:46 -0400 Subject: HTTP_X_LIVETOOL In-Reply-To: <4F26CEDD.6050506@berloga.ru> References: <4F26CEDD.6050506@berloga.ru> Message-ID: <6411fc4abe153b3f30cb812d873a45cc.NginxMailingListRussian@forum.nginx.org> К сожалению, не слышал. Слышал только про Поиск Livetool. Вроде нормальный поисковик, хотя в отзывах, которые я читал есть как положительные, так и негативные отзывы. Но в целом пользоваться livetool вроде как удобно. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,221800,237971#msg-237971