From vbart на nginx.com Tue Mar 1 09:26:27 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 01 Mar 2016 12:26:27 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLRitC10LTQsNC10YIg0LLRgdC1INC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0L7RgNC90L7QtSDQstGA0LXQvNGP?= In-Reply-To: References: <18213235.syk67x0ErK@vbart-laptop> Message-ID: <4629949.BWO9MIbDGa@vbart-laptop> On Monday 29 February 2016 15:18:19 mikhal123 wrote: > Валентин Бартенев Wrote: > > > Директиву необходимо добавить на основной уровень конфигурации (the main > context of your NGINX сonfiguration file), а у вас она находится на уровне > http. > > не хотелось бы светить данные сайта, поэтому в субботу скинул на почту > debug-лог при зацикливании процесса. дошел ли? > если на почту не вариант, то могу выложить ссылку сюда (но тогда сначала > придется обезличить его) > Лог получил. У вас в процессе работы nginx что-то с файлами происходит, они как-то изменяются, редактируются, обновляются? -- Валентин Бартенев From nginx-forum на forum.nginx.org Tue Mar 1 15:52:08 2016 From: nginx-forum на forum.nginx.org (mikhal123) Date: Tue, 01 Mar 2016 10:52:08 -0500 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLRitC10LTQsNC10YIg0LLRgdC1INC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0L7RgNC90L7QtSDQstGA0LXQvNGP?= In-Reply-To: <4629949.BWO9MIbDGa@vbart-laptop> References: <4629949.BWO9MIbDGa@vbart-laptop> Message-ID: <3bcc0f5513f6b24fe7440f0c7578290a.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: > Лог получил. У вас в процессе работы nginx что-то с файлами происходит, они как-то изменяются, редактируются, обновляются? Да. Именно тот файл, из-за которого судя по логам все и происходит, обновляется один раз в 15 секунд. Крон дергает небольшой пхп-скриптик, который делает простейшую запись в этот файл. Если это существенно, то выглядит вот так: $handler = fopen($filename, "w+"); fwrite($handler, $output); fflush($handler); fclose($handler); Posted at Nginx Forum: https://forum.nginx.org/read.php?21,264701,264972#msg-264972 From vbart на nginx.com Tue Mar 1 16:02:04 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 01 Mar 2016 19:02:04 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLRitC10LTQsNC10YIg0LLRgdC1INC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0L7RgNC90L7QtSDQstGA0LXQvNGP?= In-Reply-To: <3bcc0f5513f6b24fe7440f0c7578290a.NginxMailingListRussian@forum.nginx.org> References: <4629949.BWO9MIbDGa@vbart-laptop> <3bcc0f5513f6b24fe7440f0c7578290a.NginxMailingListRussian@forum.nginx.org> Message-ID: <1723094.2hlC8p4jfZ@vbart-workstation> On Tuesday 01 March 2016 10:52:08 mikhal123 wrote: > Валентин Бартенев Wrote: > > > Лог получил. У вас в процессе работы nginx что-то с файлами происходит, > они как-то изменяются, редактируются, обновляются? > > Да. Именно тот файл, из-за которого судя по логам все и происходит, > обновляется один раз в 15 секунд. > Крон дергает небольшой пхп-скриптик, который делает простейшую запись в этот > файл. > Если это существенно, то выглядит вот так: > $handler = fopen($filename, "w+"); > fwrite($handler, $output); > fflush($handler); > fclose($handler); > [..] Это всё и объясняет. Нельзя изменять файлы, которые раздаются. Клиент получит мусор, а вы получите странную ошибку или такое вот зацикливание. Если вы хотите переписать файл, то делать это нужно атомарно, иначе представления nginx об отдаваемом файле и его размере разойдутся с фактическим на файловой системе. У вас вероятность этого события была увеличена ещё в несколько раз включенным "open_file_cache". -- Валентин Бартенев From mdounin на mdounin.ru Tue Mar 1 16:10:02 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 1 Mar 2016 19:10:02 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLRitC10LTQsNC10YIg0LLRgdC1INC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0L7RgNC90L7QtSDQstGA0LXQvNGP?= In-Reply-To: <1723094.2hlC8p4jfZ@vbart-workstation> References: <4629949.BWO9MIbDGa@vbart-laptop> <3bcc0f5513f6b24fe7440f0c7578290a.NginxMailingListRussian@forum.nginx.org> <1723094.2hlC8p4jfZ@vbart-workstation> Message-ID: <20160301161002.GB31796@mdounin.ru> Hello! On Tue, Mar 01, 2016 at 07:02:04PM +0300, Валентин Бартенев wrote: > On Tuesday 01 March 2016 10:52:08 mikhal123 wrote: > > Валентин Бартенев Wrote: > > > > > Лог получил. У вас в процессе работы nginx что-то с файлами происходит, > > они как-то изменяются, редактируются, обновляются? > > > > Да. Именно тот файл, из-за которого судя по логам все и происходит, > > обновляется один раз в 15 секунд. > > Крон дергает небольшой пхп-скриптик, который делает простейшую запись в этот > > файл. > > Если это существенно, то выглядит вот так: > > $handler = fopen($filename, "w+"); > > fwrite($handler, $output); > > fflush($handler); > > fclose($handler); > > > [..] > > Это всё и объясняет. Нельзя изменять файлы, которые раздаются. Клиент > получит мусор, а вы получите странную ошибку или такое вот зацикливание. > > Если вы хотите переписать файл, то делать это нужно атомарно, иначе > представления nginx об отдаваемом файле и его размере разойдутся с > фактическим на файловой системе. У вас вероятность этого события была > увеличена ещё в несколько раз включенным "open_file_cache". А где там зацикливание? Мусор клиенту - это понятный и неизбежный результат неатомарного обновления файлов, но зацикливаний хотелось бы не допускать ни при каких обстоятельствах. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Tue Mar 1 16:25:17 2016 From: nginx-forum на forum.nginx.org (mikhal123) Date: Tue, 01 Mar 2016 11:25:17 -0500 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLRitC10LTQsNC10YIg0LLRgdC1INC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0L7RgNC90L7QtSDQstGA0LXQvNGP?= In-Reply-To: <1723094.2hlC8p4jfZ@vbart-workstation> References: <1723094.2hlC8p4jfZ@vbart-workstation> Message-ID: <74e552114fc220aafd4bc5d79c934f17.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Tuesday 01 March 2016 10:52:08 mikhal123 wrote: > > Валентин Бартенев Wrote: > > > Это всё и объясняет. Нельзя изменять файлы, которые раздаются. Клиент получит мусор, а вы получите странную ошибку или такое вот зацикливание. > > Если вы хотите переписать файл, то делать это нужно атомарно, иначе представления nginx об отдаваемом файле и его размере разойдутся с фактическим на файловой системе. У вас вероятность этого события была увеличена ещё в несколько раз включенным "open_file_cache". Хм, что-то я не совсем понимаю ... Вы утверждаете, что вот такие вот графики http://i023.radikal.ru/1602/db/01658625aa1f.png для nginx являются нормой? Что если представления nginx об отдаваемом файле и его размере по каким-то причинам разойдутся с фактическим на файловой системе, то он считает себя вправе войти в бесконечный цикл с пребыванием по большей части в контексте system? Тогда хотелось бы уточнить три момента: 1) данное поведение является официально задокументированным? 2) как оно соотносится с такими задекларируемыми свойствами nginx, как минимальное использование ресурсов и надежность? 3) не планируете ли вы изменить данное поведение, исключив возможность бесконечных циклов и всего такого? и просто ради понимания - почему же все это началось только после перехода с Debian 8? до этого в точной такой же конфигурации nginx и при перезаписывании файла все отлично работало (без мусора в ответах, безконечных циклов и т.д) как минимум два года Posted at Nginx Forum: https://forum.nginx.org/read.php?21,264701,264975#msg-264975 From nginx-forum на forum.nginx.org Tue Mar 1 16:27:44 2016 From: nginx-forum на forum.nginx.org (mikhal123) Date: Tue, 01 Mar 2016 11:27:44 -0500 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLRitC10LTQsNC10YIg0LLRgdC1INC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0L7RgNC90L7QtSDQstGA0LXQvNGP?= In-Reply-To: <20160301161002.GB31796@mdounin.ru> References: <20160301161002.GB31796@mdounin.ru> Message-ID: <03dc08f56483968a8d92d9cad5e7331c.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: ------------------------------------------------------- > А где там зацикливание? Мусор клиенту - это понятный и неизбежный > результат неатомарного обновления файлов, но зацикливаний хотелось > бы не допускать ни при каких обстоятельствах. вот-вот, мне как-то тоже непонятна "нормальность" зацикливания :) зацикливание вот тут:http://i023.radikal.ru/1602/db/01658625aa1f.png strace: бесконечное повторение epoll_ctl(18, EPOLL_CTL_MOD, 11, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=1467215760, u64=139725343289232}}) = 0 epoll_wait(18, {{EPOLLOUT, {u32=1467215760, u64=139725343289232}}}, 512, 500) = 1 epoll_ctl(18, EPOLL_CTL_MOD, 11, {EPOLLIN|EPOLLRDHUP|EPOLLET, {u32=1467215760, u64=139725343289232}}) = 0 futex(0x746234, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x746230, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1 futex(0x7461f0, FUTEX_WAKE_PRIVATE, 1) = 1 epoll_wait(18, {{EPOLLIN, {u32=7338688, u64=7338688}}}, 512, 500) = 1 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,264701,264976#msg-264976 From mdounin на mdounin.ru Tue Mar 1 17:48:50 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 1 Mar 2016 20:48:50 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLRitC10LTQsNC10YIg0LLRgdC1INC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0L7RgNC90L7QtSDQstGA0LXQvNGP?= In-Reply-To: <74e552114fc220aafd4bc5d79c934f17.NginxMailingListRussian@forum.nginx.org> References: <1723094.2hlC8p4jfZ@vbart-workstation> <74e552114fc220aafd4bc5d79c934f17.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160301174850.GE31796@mdounin.ru> Hello! On Tue, Mar 01, 2016 at 11:25:17AM -0500, mikhal123 wrote: > Валентин Бартенев Wrote: > ------------------------------------------------------- > > On Tuesday 01 March 2016 10:52:08 mikhal123 wrote: > > > Валентин Бартенев Wrote: > > > > > Это всё и объясняет. Нельзя изменять файлы, которые раздаются. Клиент > получит мусор, а вы получите странную ошибку или такое вот зацикливание. > > > > Если вы хотите переписать файл, то делать это нужно атомарно, иначе > представления nginx об отдаваемом файле и его размере разойдутся с > фактическим на файловой системе. У вас вероятность этого события была > увеличена ещё в несколько раз включенным "open_file_cache". > > Хм, что-то я не совсем понимаю ... > > Вы утверждаете, что вот такие вот графики > http://i023.radikal.ru/1602/db/01658625aa1f.png для nginx являются нормой? > Что если представления nginx об отдаваемом файле и его размере по каким-то > причинам разойдутся с фактическим на файловой системе, то он считает себя > вправе войти в бесконечный цикл с пребыванием по большей части в контексте > system? Это, безусловно, ошибка - должна быть ругань в логе, а не цикл. E.g, при выключенном sendfile'е - будет что-то вроде: [alert] ... read() read only ... of ... from "..." А на FreeBSD и при использовании sendfile() в таком случае будет: [alert] ... sendfile() reported that "..." was truncated at ... На Linux'е интерфейс sendfile() несколько другой, и явного детектирования таких ошибок сейчас nginx делать не умеет. Когда-нибудь обязательно научим, тем более, что при использовании thread'ов это стало нехорошо проявляться. Следует, однако, понимать, что в случае неатомарного обновления файлов клиент имеет все шансы получить произвольную смесь из старого и нового файлов (не говоря уже о новом содержимом, обрезанном по старому размеру), и делать так - не надо. А если вы так делаете - то надо быть готовым как минимум к мусору в ответах, а как максимум - и к более другим проблемам. [...] > и просто ради понимания - почему же все это началось только после перехода с > Debian 8? > до этого в точной такой же конфигурации nginx и при перезаписывании файла > все отлично работало (без мусора в ответах, безконечных циклов и т.д) как > минимум два года "В точно такой же конфигурации" - это вряд ли. Два года назад в nginx'е не было поддержи "aio threads", а на цикл вы наступили именно из-за неё - в обычной ситуации на Linux'е соединение просто повиснет до таймаута. Что до мусора, то тут всё зависит от везения и конкретного формата данных. Если специально не пытаться ловить повреждения данных - можно долго ничего не замечать, списывая проблемы на подземный стук. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Tue Mar 1 18:05:37 2016 From: nginx-forum на forum.nginx.org (mikhal123) Date: Tue, 01 Mar 2016 13:05:37 -0500 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLRitC10LTQsNC10YIg0LLRgdC1INC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0L7RgNC90L7QtSDQstGA0LXQvNGP?= In-Reply-To: <20160301174850.GE31796@mdounin.ru> References: <20160301174850.GE31796@mdounin.ru> Message-ID: <8e4b125876890e184b99a74dd0b40798.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: > Это, безусловно, ошибка - должна быть ругань в логе, а не цикл. > E.g, при выключенном sendfile'е - будет что-то вроде: > > [alert] ... read() read only ... of ... from "..." > > А на FreeBSD и при использовании sendfile() в таком случае будет: > > [alert] ... sendfile() reported that "..." was truncated at ... > > На Linux'е интерфейс sendfile() несколько другой, и явного > детектирования таких ошибок сейчас nginx делать не умеет. > Когда-нибудь обязательно научим, тем более, что при использовании > thread'ов это стало нехорошо проявляться. > > Следует, однако, понимать, что в случае неатомарного обновления > файлов клиент имеет все шансы получить произвольную смесь из > старого и нового файлов (не говоря уже о новом содержимом, > обрезанном по старому размеру), и делать так - не надо. А если вы > так делаете - то надо быть готовым как минимум к мусору в ответах, > а как максимум - и к более другим проблемам. > > "В точно такой же конфигурации" - это вряд ли. Два года назад в > nginx'е не было поддержи "aio threads", а на цикл вы наступили > именно из-за неё - в обычной ситуации на Linux'е соединение просто > повиснет до таймаута. > > Что до мусора, то тут всё зависит от везения и конкретного формата > данных. Если специально не пытаться ловить повреждения данных - > можно долго ничего не замечать, списывая проблемы на подземный > стук. По поводу iao threads согласен, запамятовал что включил его после обновления Про ошибки [alert] ... read() read only ... of ... from "..." помню, встречал. В моем случае решается несложно - обновляемый файл (а мне нужно его обновлять, тут никуда не деться) всегда дополняется пробелами до заранее заданного размера, и nginx остается доволен Но проблему с зацикливанием, как я понимаю, в ближайшее время вы не сможете решить, и как самый простой вариант - отключить aio threads до лучших времен? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,264701,264984#msg-264984 From mdounin на mdounin.ru Tue Mar 1 18:24:19 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 1 Mar 2016 21:24:19 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLRitC10LTQsNC10YIg0LLRgdC1INC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0L7RgNC90L7QtSDQstGA0LXQvNGP?= In-Reply-To: <8e4b125876890e184b99a74dd0b40798.NginxMailingListRussian@forum.nginx.org> References: <20160301174850.GE31796@mdounin.ru> <8e4b125876890e184b99a74dd0b40798.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160301182419.GG31796@mdounin.ru> Hello! On Tue, Mar 01, 2016 at 01:05:37PM -0500, mikhal123 wrote: > Maxim Dounin Wrote: > > Это, безусловно, ошибка - должна быть ругань в логе, а не цикл. > > E.g, при выключенном sendfile'е - будет что-то вроде: > > > > [alert] ... read() read only ... of ... from "..." > > > > А на FreeBSD и при использовании sendfile() в таком случае будет: > > > > [alert] ... sendfile() reported that "..." was truncated at ... > > > > На Linux'е интерфейс sendfile() несколько другой, и явного > > детектирования таких ошибок сейчас nginx делать не умеет. > > Когда-нибудь обязательно научим, тем более, что при использовании > > thread'ов это стало нехорошо проявляться. > > > > Следует, однако, понимать, что в случае неатомарного обновления > > файлов клиент имеет все шансы получить произвольную смесь из > > старого и нового файлов (не говоря уже о новом содержимом, > > обрезанном по старому размеру), и делать так - не надо. А если вы > > так делаете - то надо быть готовым как минимум к мусору в ответах, > > а как максимум - и к более другим проблемам. > > > > "В точно такой же конфигурации" - это вряд ли. Два года назад в > > nginx'е не было поддержи "aio threads", а на цикл вы наступили > > именно из-за неё - в обычной ситуации на Linux'е соединение просто > > повиснет до таймаута. > > > > Что до мусора, то тут всё зависит от везения и конкретного формата > > данных. Если специально не пытаться ловить повреждения данных - > > можно долго ничего не замечать, списывая проблемы на подземный > > стук. > > По поводу iao threads согласен, запамятовал что включил его после > обновления > > Про ошибки > [alert] ... read() read only ... of ... from "..." > помню, встречал. В моем случае решается несложно - обновляемый файл (а мне > нужно его обновлять, тут никуда не деться) всегда дополняется пробелами до > заранее заданного размера, и nginx остается доволен Ну то есть вы тщательно проигнорировали всё то доброе и вечное, что nginx писал вам про некорректность вашей работы с файлами, и вместо того, чтобы исправить проблему, заткнули сообщение, дополнив файл пробелами? И, судя по тому, что сейчас у вас всё зацикливается - ещё и убрали из кода это дополнение пробелами? Почему-то вспоминается старый анекдот про японскую бензопилу. ;) Не надо так. Обновляйте файл атомарно, i.e., пишите новый файл, а потом делайте rename() в старое имя. И будет вам счастье. > Но проблему с зацикливанием, как я понимаю, в ближайшее время вы не сможете > решить, и как самый простой вариант - отключить aio threads до лучших > времен? Самый простой вариант - починить обновление файла, сделав его атомарным. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Tue Mar 1 19:05:28 2016 From: nginx-forum на forum.nginx.org (mikhal123) Date: Tue, 01 Mar 2016 14:05:28 -0500 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLRitC10LTQsNC10YIg0LLRgdC1INC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0L7RgNC90L7QtSDQstGA0LXQvNGP?= In-Reply-To: <20160301182419.GG31796@mdounin.ru> References: <20160301182419.GG31796@mdounin.ru> Message-ID: <73f159d06899bf9eff4e5b613ce192fa.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: > Ну то есть вы тщательно проигнорировали всё то доброе и вечное, что > nginx писал вам про некорректность вашей работы с файлами, и > вместо того, чтобы исправить проблему, заткнули сообщение, > дополнив файл пробелами? И, судя по тому, что сейчас у вас всё > зацикливается - ещё и убрали из кода это дополнение пробелами? > Почему-то вспоминается старый анекдот про японскую бензопилу. ;) > > Не надо так. Обновляйте файл атомарно, i.e., пишите новый файл, а > потом делайте rename() в старое имя. И будет вам счастье. > > > Но проблему с зацикливанием, как я понимаю, в ближайшее время вы не > сможете решить, и как самый простой вариант - отключить aio threads до лучших > > времен? > > Самый простой вариант - починить обновление файла, сделав его > атомарным. это было году так в 2006-2007 в совершенно другом проекте, и тогда это показалось мне замечательным решением :) а в этом проекте таких строчек в логах не помню, видно из-за того что sendfile был включен с самого начала и какие-то там дурацкие алармы не мозолили глаза :) ок, последую вашей рекомендации с rename() p.s. но вы бы все-таки как-то отразили суть данной беседы в документации. не один я меняю файлы через обычный fopen('w+'), и некоторые из таких тоже могут попасть на данный баг с aio threads. у меня то выделенный сервер с ксеоном и большим запасом по мощности, а вот обычные vds-ки могут не обрадоваться таким циклам Posted at Nginx Forum: https://forum.nginx.org/read.php?21,264701,264986#msg-264986 From bgx на protva.ru Wed Mar 2 07:23:17 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 2 Mar 2016 10:23:17 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLRitC10LTQsNC10YIg0LLRgdC1INC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0L7RgNC90L7QtSDQstGA0LXQvNGP?= In-Reply-To: <73f159d06899bf9eff4e5b613ce192fa.NginxMailingListRussian@forum.nginx.org> References: <20160301182419.GG31796@mdounin.ru> <73f159d06899bf9eff4e5b613ce192fa.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160302072316.GA15153@protva.ru> On Tue, Mar 01, 2016 at 02:05:28PM -0500, mikhal123 wrote: > p.s. но вы бы все-таки как-то отразили суть данной беседы в документации. > не один я меняю файлы через обычный fopen('w+'), Звучит как предложение написать в инструкции по эксплуатации автомобиля, что не следует одновременно сливать масло из картера и заливать новое при работающем двигателе. :) Подумайте, отчего такие банальные вещи в инструкциях не пишут. > и некоторые из таких тоже > могут попасть на данный баг с aio threads. Проблему с зацикливанием, конечно, лучше устранить, если это не сильно портит код. Однако не следует особо упираться в попытках разложить соломку под некорректные данные или ненормальные условия работы. -- Eugene Berdnikov From nginx-forum на forum.nginx.org Wed Mar 2 13:41:08 2016 From: nginx-forum на forum.nginx.org (mikhal123) Date: Wed, 02 Mar 2016 08:41:08 -0500 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLRitC10LTQsNC10YIg0LLRgdC1INC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0L7RgNC90L7QtSDQstGA0LXQvNGP?= In-Reply-To: <20160302072316.GA15153@protva.ru> References: <20160302072316.GA15153@protva.ru> Message-ID: <4b25f43b4fad8f59647ca9ca8e1ac767.NginxMailingListRussian@forum.nginx.org> Evgeniy Berdnikov Wrote: > Звучит как предложение написать в инструкции по эксплуатации автомобиля, что не следует одновременно сливать масло из картера и заливать новое при работающем двигателе. :) Подумайте, отчего такие банальные вещи в инструкциях не пишут. Хм... Могу с уверенность предположить, что своего автомобиля у вас нет (либо вы не любитель читать эти скучные инструкции). Попросите инструкцию по эксплуатации автомобиля у какого-нибудь знакомого или скачайте любую в интернете, откройте на разделе проверки уровня масла и убедитесь, что первым же пунктом идет требование заглушить двигатель и подождать несколько минут перед открытием масляной горловины. Как убедитесь, подумайте, почему такие банальные вещи в инструкциях все же пишут. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,264701,265008#msg-265008 From bgx на protva.ru Wed Mar 2 16:06:31 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 2 Mar 2016 19:06:31 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLRitC10LTQsNC10YIg0LLRgdC1INC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0L7RgNC90L7QtSDQstGA0LXQvNGP?= In-Reply-To: <4b25f43b4fad8f59647ca9ca8e1ac767.NginxMailingListRussian@forum.nginx.org> References: <20160302072316.GA15153@protva.ru> <4b25f43b4fad8f59647ca9ca8e1ac767.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160302160631.GF23377@sie.protva.ru> On Wed, Mar 02, 2016 at 08:41:08AM -0500, mikhal123 wrote: > Evgeniy Berdnikov Wrote: > > Звучит как предложение написать в инструкции по эксплуатации автомобиля, > что не следует одновременно сливать масло из картера и заливать новое при > работающем двигателе. :) Подумайте, отчего такие банальные вещи в > инструкциях не пишут. > > Хм... Могу с уверенность предположить, что своего автомобиля у вас нет (либо > вы не любитель читать эти скучные инструкции). Есть, и даже люблю почитать инструкцию прежде чем что-либо делать. Вытащил для интереса, в разделе "Техническое обслуживание и текущий ремонт" ничего не говорится про слив. Написано лишь почему не следует заливать масло выше метки "MAX", причина весьма серьёзная и неочевидная. :) Про смену масла и фильтра ничего нет, и как менять масло в коробке и дифференциалах -- тоже. Всё это для рядового пользователя не очень-то нужно, скорее нужно для механика в автосервисе. А уж тот-то должен знать, что менять масло и фильтр на работающем двигателе не следует. Весь вопрос в цене риска. Обслуживать самолётный двигатель без диплома и пачки сертификатов никто не позволит. Потому что там маленькая глупость может стоить сотни жизней. А веб-сайты фигачат все кому не лень, потому что в этом деле цена риска и уровень ответственности начинаются с нуля. -- Eugene Berdnikov From nginx-forum на forum.nginx.org Wed Mar 2 16:55:51 2016 From: nginx-forum на forum.nginx.org (mikhal123) Date: Wed, 02 Mar 2016 11:55:51 -0500 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLRitC10LTQsNC10YIg0LLRgdC1INC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0L7RgNC90L7QtSDQstGA0LXQvNGP?= In-Reply-To: <20160302160631.GF23377@sie.protva.ru> References: <20160302160631.GF23377@sie.protva.ru> Message-ID: Evgeniy Berdnikov Wrote: ------------------------------------------------------- > Есть, и даже люблю почитать инструкцию прежде чем что-либо делать. > Вытащил для интереса, в разделе "Техническое обслуживание и текущий > ремонт" > ничего не говорится про слив. Написано лишь почему не следует > заливать > масло выше метки "MAX", причина весьма серьёзная и неочевидная. :) > Про смену масла и фильтра ничего нет, и как менять масло в коробке и > дифференциалах -- тоже. Всё это для рядового пользователя не очень-то > нужно, скорее нужно для механика в автосервисе. А уж тот-то должен > знать, > что менять масло и фильтр на работающем двигателе не следует. я же написал где смотреть? еще раз: "откройте на разделе проверки уровня масла и убедитесь, что первым же пунктом идет требование заглушить двигатель и подождать несколько минут перед открытием масляной горловины." рядовой пользователь обязан регулярно проверять уровень масла, поэтому эта инструкция наличествует в любой инструкции по эксплуатации автомобиля и расписана там максимально подробно. во избежания ожога кипящем маслом, который неминуем при открытии горловины на работающем двигателе или сразу же после его выключения. так что в документации nginx было бы нелишне упомянуть, что при работе aio через threads в ряде случаев возможны вот такие вот локальные DOS'ы сервера. мне то собственно уже все равно, но кого-то может спасти от "ожога" Posted at Nginx Forum: https://forum.nginx.org/read.php?21,264701,265014#msg-265014 From maxim на nginx.com Wed Mar 2 17:09:13 2016 From: maxim на nginx.com (Maxim Konovalov) Date: Wed, 2 Mar 2016 20:09:13 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLRitC10LTQsNC10YIg0LLRgdC1INC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0L7RgNC90L7QtSDQstGA0LXQvNGP?= In-Reply-To: References: <20160302160631.GF23377@sie.protva.ru> Message-ID: <56D71E39.6070605@nginx.com> On 3/2/16 7:55 PM, mikhal123 wrote: [...] > так что в документации nginx было бы нелишне упомянуть, что при работе aio > через threads в ряде случаев возможны вот такие вот локальные DOS'ы сервера. > мне то собственно уже все равно, но кого-то может спасти от "ожога" Мужчины, мы же уже выяснили -- это баг, его надо фиксить. Что и сделаем в будущем. Для документирования бага откройте тикет в trac.nginx.org. Вопрос с тем, что в nginx может отдать странное, когда файл неатомарно обновляется, к nginx напрямую отношения не имеет, документировать тут нам нечего. -- Maxim Konovalov From vadim.lazovskiy на gmail.com Thu Mar 3 15:53:43 2016 From: vadim.lazovskiy на gmail.com (Vadim Lazovskiy) Date: Thu, 3 Mar 2016 18:53:43 +0300 Subject: client timed out & readv() failed Message-ID: Здравствуйте. Возможно немного не по теме, но возможно кто-то сталкивался. Есть upstream на nginx раздающий файлы. Есть frontend на nginx проксирующий и кэширующий их. Периодически в логах появляются ошибки: upstream (nginx 1.2.9): 2016/03/03 18:28:57 [info] 16552#0: *190295515 client timed out (110: Connection timed out) while sending response to client, client: IP, server: SERVER, request: "GET /URI HTTP/1.0", host: "SERVER", referrer: "REFER" frontend (nginx 1.9.11): 2016/03/03 18:27:56 [error] 22785#22785: *168191 readv() failed (104: Connection reset by peer) while reading upstream, client: IP, server: SERVER, request: "GET /URI HTTP/1.1", subrequest: "/URI", upstream: "UPSTREAM", host: "SERVER", referrer: "REFER" Причем фронтенд рапортует, что ничего не сделать на минуту раньше, нежели бакенд. frontend подключен по 10G, примерно 4G исходящего и 2.5G входящего трафика. backend - port channel из 4 1G линков, недостатка в полосе не имеет. Кто-нибудь сталкивался с подобными ошибками? С чем может быть связано и что подкрутить? Спасибо. -- WBR, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey на kopeyko.ru Thu Mar 3 16:03:35 2016 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Thu, 3 Mar 2016 19:03:35 +0300 (MSK) Subject: client timed out & readv() failed In-Reply-To: References: Message-ID: On Thu, 3 Mar 2016, Vadim Lazovskiy wrote: > Здравствуйте. Добрый вечер! > Возможно немного не по теме, но возможно кто-то сталкивался. > > Есть upstream на nginx раздающий файлы. > Есть frontend на nginx проксирующий и кэширующий их. > > Периодически в логах появляются ошибки: > > upstream (nginx 1.2.9): > 2016/03/03 18:28:57 [info] 16552#0: *190295515 client timed out (110: > Connection timed out) while sending response to client, client: IP, server: > SERVER, request: "GET /URI HTTP/1.0", host: "SERVER", referrer: "REFER" > > frontend (nginx 1.9.11): > 2016/03/03 18:27:56 [error] 22785#22785: *168191 readv() failed (104: > Connection reset by peer) while reading upstream, client: IP, server: > SERVER, request: "GET /URI HTTP/1.1", subrequest: "/URI", upstream: > "UPSTREAM", host: "SERVER", referrer: "REFER" ИМХО тут нечего подкручивать - фронтенд ясно говорит, что пользователь разорвал соединение в процессе получения ответа. Такое поведение характерно для IE и FF при закрытии вкладки. Научить пользователей дожидаться получения полного ответа перед закрытием браузера - it's fantastic. > Причем фронтенд рапортует, что ничего не сделать на минуту раньше, нежели > бакенд. > > frontend подключен по 10G, примерно 4G исходящего и 2.5G входящего трафика. > backend - port channel из 4 1G линков, недостатка в полосе не имеет. > > Кто-нибудь сталкивался с подобными ошибками? С чем может быть связано и что > подкрутить? > > Спасибо. > > -- Best regards, Andrey Kopeyko From vadim.lazovskiy на gmail.com Thu Mar 3 16:22:46 2016 From: vadim.lazovskiy на gmail.com (Vadim Lazovskiy) Date: Thu, 3 Mar 2016 19:22:46 +0300 Subject: client timed out & readv() failed In-Reply-To: References: Message-ID: 3 марта 2016 г., 19:03 пользователь Andrey Kopeyko написал: > > ИМХО тут нечего подкручивать - фронтенд ясно говорит, что пользователь > разорвал соединение в процессе получения ответа. Такое поведение характерно > для IE и FF при закрытии вкладки. Научить пользователей дожидаться > получения полного ответа перед закрытием браузера - it's fantastic. > > То, о чем вы говорите логгируется на уровне info как "client prematurely closed connection". Здесь же речь идет соединении с бакендом: frontend говорит - не могу прочитать ничего с upstream, а upstream - frontend ничего не читает, закрываю соединение. И все это происходит в толстенном канале. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bazilek на gmail.com Thu Mar 3 16:39:37 2016 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Thu, 3 Mar 2016 19:39:37 +0300 Subject: nginx to return compressed file while proxying Message-ID: Всем привет, помогите понять почему nginx(host: o) отдает несжатый файл в случае проксирования другому nginx(host: l) однако отдает сжатый для curl при запросе курлом все получаю Content-Encoding: gzip curl -I http://o/big.txt -H 'Accept-Encoding: gzip' 2016/03/03 16:35:24 [debug] 49741#49741: *1 http header: "Host: o" 2016/03/03 16:35:24 [debug] 49741#49741: *1 http header: "Accept: */*" 2016/03/03 16:35:24 [debug] 49741#49741: *1 http header: "Accept-Encoding: gzip" 2016/03/03 16:35:24 [debug] 49741#49741: *1 http header done 2016/03/03 16:35:24 [debug] 49741#49741: *1 event timer del: 17: 1457023524813 2016/03/03 16:35:24 [debug] 49741#49741: *1 generic phase: 0 2016/03/03 16:35:24 [debug] 49741#49741: *1 rewrite phase: 1 2016/03/03 16:35:24 [debug] 49741#49741: *1 using configuration "" 2016/03/03 16:35:24 [debug] 49741#49741: *1 http cl:-1 max:1048576 2016/03/03 16:35:24 [debug] 49741#49741: *1 rewrite phase: 3 2016/03/03 16:35:24 [debug] 49741#49741: *1 post rewrite phase: 4 2016/03/03 16:35:24 [debug] 49741#49741: *1 generic phase: 5 2016/03/03 16:35:24 [debug] 49741#49741: *1 generic phase: 6 2016/03/03 16:35:24 [debug] 49741#49741: *1 generic phase: 7 2016/03/03 16:35:24 [debug] 49741#49741: *1 generic phase: 8 2016/03/03 16:35:24 [debug] 49741#49741: *1 access phase: 9 2016/03/03 16:35:24 [debug] 49741#49741: *1 access phase: 10 2016/03/03 16:35:24 [debug] 49741#49741: *1 access phase: 11 2016/03/03 16:35:24 [debug] 49741#49741: *1 post access phase: 12 2016/03/03 16:35:24 [debug] 49741#49741: *1 content phase: 13 2016/03/03 16:35:24 [debug] 49741#49741: *1 content phase: 14 2016/03/03 16:35:24 [debug] 49741#49741: *1 content phase: 15 2016/03/03 16:35:24 [debug] 49741#49741: *1 content phase: 16 2016/03/03 16:35:24 [debug] 49741#49741: *1 content phase: 17 2016/03/03 16:35:24 [debug] 49741#49741: *1 content phase: 18 2016/03/03 16:35:24 [debug] 49741#49741: *1 content phase: 19 2016/03/03 16:35:24 [debug] 49741#49741: *1 http filename: "/var/www/o/big.txt" 2016/03/03 16:35:24 [debug] 49741#49741: *1 add cleanup: 00000000029E0CD0 2016/03/03 16:35:24 [debug] 49741#49741: *1 malloc: 00000000029D0C30:144 2016/03/03 16:35:24 [debug] 49741#49741: *1 malloc: 0000000002A116B0:19 2016/03/03 16:35:24 [debug] 49741#49741: *1 cached open file: /var/www/o/big.txt, fd:18, c:1, e:0, u:1 2016/03/03 16:35:24 [debug] 49741#49741: *1 http static fd: 18 2016/03/03 16:35:24 [debug] 49741#49741: *1 http set discard body 2016/03/03 16:35:24 [debug] 49741#49741: *1 HTTP/1.1 200 OK Server: nginx Date: Thu, 03 Mar 2016 16:35:24 GMT Content-Type: text/plain Last-Modified: Thu, 03 Mar 2016 15:06:50 GMT Connection: keep-alive Vary: Accept-Encoding ETag: W/"56d8530a-43c" Expires: Thu, 03 Mar 2016 16:37:24 GMT Cache-Control: max-age=120 Content-Encoding: gzip если запрос от другого на o идет от друго nginx (l) получаю несжатый контент 2016/03/03 16:39:33 [debug] 49741#49741: *4 http header: "Host: o" 2016/03/03 16:39:33 [debug] 49741#49741: *4 http header: "Connection: close" 2016/03/03 16:39:33 [debug] 49741#49741: *4 http header: "User-Agent: curl/7.29.0" 2016/03/03 16:39:33 [debug] 49741#49741: *4 http header: "Accept: */*" 2016/03/03 16:39:33 [debug] 49741#49741: *4 http header: "Accept-Encoding: gzip" 2016/03/03 16:39:33 [debug] 49741#49741: *4 http header done 2016/03/03 16:39:33 [debug] 49741#49741: *4 event timer del: 18: 1457023773456 2016/03/03 16:39:33 [debug] 49741#49741: *4 generic phase: 0 2016/03/03 16:39:33 [debug] 49741#49741: *4 rewrite phase: 1 2016/03/03 16:39:33 [debug] 49741#49741: *4 using configuration "" 2016/03/03 16:39:33 [debug] 49741#49741: *4 http cl:-1 max:1048576 2016/03/03 16:39:33 [debug] 49741#49741: *4 rewrite phase: 3 2016/03/03 16:39:33 [debug] 49741#49741: *4 post rewrite phase: 4 2016/03/03 16:39:33 [debug] 49741#49741: *4 generic phase: 5 2016/03/03 16:39:33 [debug] 49741#49741: *4 generic phase: 6 2016/03/03 16:39:33 [debug] 49741#49741: *4 generic phase: 7 2016/03/03 16:39:33 [debug] 49741#49741: *4 generic phase: 8 2016/03/03 16:39:33 [debug] 49741#49741: *4 access phase: 9 2016/03/03 16:39:33 [debug] 49741#49741: *4 access phase: 10 2016/03/03 16:39:33 [debug] 49741#49741: *4 access phase: 11 2016/03/03 16:39:33 [debug] 49741#49741: *4 post access phase: 12 2016/03/03 16:39:33 [debug] 49741#49741: *4 content phase: 13 2016/03/03 16:39:33 [debug] 49741#49741: *4 content phase: 14 2016/03/03 16:39:33 [debug] 49741#49741: *4 content phase: 15 2016/03/03 16:39:33 [debug] 49741#49741: *4 content phase: 16 2016/03/03 16:39:33 [debug] 49741#49741: *4 content phase: 17 2016/03/03 16:39:33 [debug] 49741#49741: *4 content phase: 18 2016/03/03 16:39:33 [debug] 49741#49741: *4 content phase: 19 2016/03/03 16:39:33 [debug] 49741#49741: *4 http filename: "/var/www/o/big.txt" 2016/03/03 16:39:33 [debug] 49741#49741: *4 add cleanup: 00000000029D6C28 2016/03/03 16:39:33 [debug] 49741#49741: *4 cached open file: /var/www/o/big.txt, fd:19, c:1, e:0, u:2 2016/03/03 16:39:33 [debug] 49741#49741: *4 http static fd: 19 2016/03/03 16:39:33 [debug] 49741#49741: *4 http set discard body 2016/03/03 16:39:33 [debug] 49741#49741: *4 HTTP/1.1 200 OK Server: nginx Date: Thu, 03 Mar 2016 16:39:33 GMT Content-Type: text/plain Content-Length: 1084 Last-Modified: Thu, 03 Mar 2016 15:06:50 GMT Connection: close Vary: Accept-Encoding ETag: "56d8530a-43c" Expires: Thu, 03 Mar 2016 16:41:33 GMT Cache-Control: max-age=120 Accept-Ranges: bytes # cat o.conf l.conf server { listen 80; server_name o; expires 120s; access_log /var/log/nginx/o_access.log; #error_log /var/log/nginx/o_error.log notice; error_log /var/log/nginx/o_error.log debug; root /var/www/o; gzip on; gzip_vary on; gzip_types text/plain text/html; gzip_min_length 10; gzip_proxied any; } proxy_cache_path /var/lib/nginx/cache/l keys_zone=l:2m inactive=1h use_temp_path=off; server { listen 80; server_name l; access_log /var/log/nginx/l_access.log; #error_log /var/log/nginx/l_error.log notice; error_log /var/log/nginx/l_error.log debug; proxy_cache l; location / { proxy_pass http://o; proxy_set_header Host $proxy_host; proxy_cache_lock on; proxy_cache_lock_age 1d; proxy_cache_lock_timeout 1d; proxy_cache_revalidate on; proxy_cache_use_stale updating; proxy_cache_key "$uri"; proxy_cache_purge PURGE from 127.0.0.1; add_header Cache $upstream_cache_status; } } -- Best regards, Vasil Mikhalenya ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Thu Mar 3 16:49:40 2016 From: vbart на nginx.com (Valentin V. Bartenev) Date: Thu, 03 Mar 2016 19:49:40 +0300 Subject: nginx to return compressed file while proxying In-Reply-To: References: Message-ID: <1487734.oouJlzL4Az@vbart-workstation> On Thursday 03 March 2016 19:39:37 Vasil Mikhalenya wrote: > Всем привет, > > помогите понять почему nginx(host: o) отдает несжатый файл в случае > проксирования другому nginx(host: l) однако отдает сжатый для curl [..] Разгадка видимо в соотношении значений директив gzip_http_version и proxy_http_version? http://nginx.org/r/gzip_http_version/ru http://nginx.org/r/proxy_http_version/ru -- Валентин Бартенев From mdounin на mdounin.ru Thu Mar 3 17:36:28 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 3 Mar 2016 20:36:28 +0300 Subject: client timed out & readv() failed In-Reply-To: References: Message-ID: <20160303173627.GV31796@mdounin.ru> Hello! On Thu, Mar 03, 2016 at 06:53:43PM +0300, Vadim Lazovskiy wrote: > Здравствуйте. > > Возможно немного не по теме, но возможно кто-то сталкивался. > > Есть upstream на nginx раздающий файлы. > Есть frontend на nginx проксирующий и кэширующий их. > > Периодически в логах появляются ошибки: > > upstream (nginx 1.2.9): > 2016/03/03 18:28:57 [info] 16552#0: *190295515 client timed out (110: > Connection timed out) while sending response to client, client: IP, server: > SERVER, request: "GET /URI HTTP/1.0", host: "SERVER", referrer: "REFER" > > frontend (nginx 1.9.11): > 2016/03/03 18:27:56 [error] 22785#22785: *168191 readv() failed (104: > Connection reset by peer) while reading upstream, client: IP, server: > SERVER, request: "GET /URI HTTP/1.1", subrequest: "/URI", upstream: > "UPSTREAM", host: "SERVER", referrer: "REFER" > > Причем фронтенд рапортует, что ничего не сделать на минуту раньше, нежели > бакенд. > > frontend подключен по 10G, примерно 4G исходящего и 2.5G входящего трафика. > backend - port channel из 4 1G линков, недостатка в полосе не имеет. > > Кто-нибудь сталкивался с подобными ошибками? С чем может быть связано и что > подкрутить? Я бы для начала попробовал поискать statefull firewall между фронтендом и бекендом. Возможно, у него кончаются state'ы, и он таким нехитрым образом пытается об этом сообщить. -- Maxim Dounin http://nginx.org/ From bgx на protva.ru Thu Mar 3 18:41:09 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 3 Mar 2016 21:41:09 +0300 Subject: client timed out & readv() failed In-Reply-To: <20160303173627.GV31796@mdounin.ru> References: <20160303173627.GV31796@mdounin.ru> Message-ID: <20160303184109.GL23377@sie.protva.ru> On Thu, Mar 03, 2016 at 08:36:28PM +0300, Maxim Dounin wrote: > Hello! > > On Thu, Mar 03, 2016 at 06:53:43PM +0300, Vadim Lazovskiy wrote: > > > Здравствуйте. > > > > Возможно немного не по теме, но возможно кто-то сталкивался. > > > > Есть upstream на nginx раздающий файлы. > > Есть frontend на nginx проксирующий и кэширующий их. > > > > Периодически в логах появляются ошибки: > > > > upstream (nginx 1.2.9): > > 2016/03/03 18:28:57 [info] 16552#0: *190295515 client timed out (110: > > Connection timed out) while sending response to client, client: IP, server: > > SERVER, request: "GET /URI HTTP/1.0", host: "SERVER", referrer: "REFER" > > > > frontend (nginx 1.9.11): > > 2016/03/03 18:27:56 [error] 22785#22785: *168191 readv() failed (104: > > Connection reset by peer) while reading upstream, client: IP, server: > > SERVER, request: "GET /URI HTTP/1.1", subrequest: "/URI", upstream: > > "UPSTREAM", host: "SERVER", referrer: "REFER" > > > > Причем фронтенд рапортует, что ничего не сделать на минуту раньше, нежели > > бакенд. > > > > frontend подключен по 10G, примерно 4G исходящего и 2.5G входящего трафика. > > backend - port channel из 4 1G линков, недостатка в полосе не имеет. > > > > Кто-нибудь сталкивался с подобными ошибками? С чем может быть связано и что > > подкрутить? > > Я бы для начала попробовал поискать statefull firewall между > фронтендом и бекендом. Возможно, у него кончаются state'ы, и он > таким нехитрым образом пытается об этом сообщить. Нет, "while sending response to client" и "while reading upstream" однозначно свидетельствуют о том, что соединение установлено. Поэтому переполнение таблицы коннекций исключается. -- Eugene Berdnikov From mdounin на mdounin.ru Thu Mar 3 19:49:34 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 3 Mar 2016 22:49:34 +0300 Subject: client timed out & readv() failed In-Reply-To: <20160303184109.GL23377@sie.protva.ru> References: <20160303173627.GV31796@mdounin.ru> <20160303184109.GL23377@sie.protva.ru> Message-ID: <20160303194934.GB31796@mdounin.ru> Hello! On Thu, Mar 03, 2016 at 09:41:09PM +0300, Evgeniy Berdnikov wrote: > On Thu, Mar 03, 2016 at 08:36:28PM +0300, Maxim Dounin wrote: > > Hello! > > > > On Thu, Mar 03, 2016 at 06:53:43PM +0300, Vadim Lazovskiy wrote: > > > > > Здравствуйте. > > > > > > Возможно немного не по теме, но возможно кто-то сталкивался. > > > > > > Есть upstream на nginx раздающий файлы. > > > Есть frontend на nginx проксирующий и кэширующий их. > > > > > > Периодически в логах появляются ошибки: > > > > > > upstream (nginx 1.2.9): > > > 2016/03/03 18:28:57 [info] 16552#0: *190295515 client timed out (110: > > > Connection timed out) while sending response to client, client: IP, server: > > > SERVER, request: "GET /URI HTTP/1.0", host: "SERVER", referrer: "REFER" > > > > > > frontend (nginx 1.9.11): > > > 2016/03/03 18:27:56 [error] 22785#22785: *168191 readv() failed (104: > > > Connection reset by peer) while reading upstream, client: IP, server: > > > SERVER, request: "GET /URI HTTP/1.1", subrequest: "/URI", upstream: > > > "UPSTREAM", host: "SERVER", referrer: "REFER" > > > > > > Причем фронтенд рапортует, что ничего не сделать на минуту раньше, нежели > > > бакенд. > > > > > > frontend подключен по 10G, примерно 4G исходящего и 2.5G входящего трафика. > > > backend - port channel из 4 1G линков, недостатка в полосе не имеет. > > > > > > Кто-нибудь сталкивался с подобными ошибками? С чем может быть связано и что > > > подкрутить? > > > > Я бы для начала попробовал поискать statefull firewall между > > фронтендом и бекендом. Возможно, у него кончаются state'ы, и он > > таким нехитрым образом пытается об этом сообщить. > > Нет, "while sending response to client" и "while reading upstream" > однозначно свидетельствуют о том, что соединение установлено. > Поэтому переполнение таблицы коннекций исключается. Это очень сильно зависит от того, как именно ведёт себя firewall, когда у него заканчиваются state'ы. E.g., pf умеет уменьшать таймауты в случае большого числа state'ов, и соответственно может убить соединение в любой момент времени. Так или иначе - "Connection reset by peer" при живом бекенде как бы намекает на то, что в первую очередь надо смотреть, что происходит в сети. -- Maxim Dounin http://nginx.org/ From bgx на protva.ru Thu Mar 3 21:12:10 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 4 Mar 2016 00:12:10 +0300 Subject: client timed out & readv() failed In-Reply-To: <20160303194934.GB31796@mdounin.ru> References: <20160303173627.GV31796@mdounin.ru> <20160303184109.GL23377@sie.protva.ru> <20160303194934.GB31796@mdounin.ru> Message-ID: <20160303211210.GM23377@sie.protva.ru> On Thu, Mar 03, 2016 at 10:49:34PM +0300, Maxim Dounin wrote: > On Thu, Mar 03, 2016 at 09:41:09PM +0300, Evgeniy Berdnikov wrote: > > On Thu, Mar 03, 2016 at 08:36:28PM +0300, Maxim Dounin wrote: > > > Я бы для начала попробовал поискать statefull firewall между > > > фронтендом и бекендом. Возможно, у него кончаются state'ы, и он > > > таким нехитрым образом пытается об этом сообщить. > > > > Нет, "while sending response to client" и "while reading upstream" > > однозначно свидетельствуют о том, что соединение установлено. > > Поэтому переполнение таблицы коннекций исключается. > > Это очень сильно зависит от того, как именно ведёт себя firewall, > когда у него заканчиваются state'ы. E.g., pf умеет уменьшать > таймауты в случае большого числа state'ов, и соответственно может > убить соединение в любой момент времени. Не думаю, что у вопрошавшего на линке скоростью 10G стоит файрвол. > Так или иначе - "Connection reset by peer" при живом бекенде как > бы намекает на то, что в первую очередь надо смотреть, что > происходит в сети. Я бы скорее подозревал наличие какой-то баги в сетевой карте. Например, в неправильном подсчёте чексуммы для пакетов с опцией sack при включенном rx/tx checksumming offload'е, из-за чего все пакеты при ретрасмитах дропаются. Коннекция умирает по таймауту. Но при этом закрывается пакетом RST, который идёт без sack и потому доходит до ядра получателя, вот и "Connection reset by peer". Так как насытить линк 10G непросто, то потерь мало, но стоит хоть одному фрейму пропасть -- sack, затем ретрансмиссии с sack, таймаут, reset. Можно придумать другие сценарии, наверное. -- Eugene Berdnikov From mdounin на mdounin.ru Fri Mar 4 02:24:31 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 4 Mar 2016 05:24:31 +0300 Subject: client timed out & readv() failed In-Reply-To: <20160303211210.GM23377@sie.protva.ru> References: <20160303173627.GV31796@mdounin.ru> <20160303184109.GL23377@sie.protva.ru> <20160303194934.GB31796@mdounin.ru> <20160303211210.GM23377@sie.protva.ru> Message-ID: <20160304022431.GD31796@mdounin.ru> Hello! On Fri, Mar 04, 2016 at 12:12:10AM +0300, Evgeniy Berdnikov wrote: > On Thu, Mar 03, 2016 at 10:49:34PM +0300, Maxim Dounin wrote: > > On Thu, Mar 03, 2016 at 09:41:09PM +0300, Evgeniy Berdnikov wrote: > > > On Thu, Mar 03, 2016 at 08:36:28PM +0300, Maxim Dounin wrote: > > > > Я бы для начала попробовал поискать statefull firewall между > > > > фронтендом и бекендом. Возможно, у него кончаются state'ы, и он > > > > таким нехитрым образом пытается об этом сообщить. > > > > > > Нет, "while sending response to client" и "while reading upstream" > > > однозначно свидетельствуют о том, что соединение установлено. > > > Поэтому переполнение таблицы коннекций исключается. > > > > Это очень сильно зависит от того, как именно ведёт себя firewall, > > когда у него заканчиваются state'ы. E.g., pf умеет уменьшать > > таймауты в случае большого числа state'ов, и соответственно может > > убить соединение в любой момент времени. > > Не думаю, что у вопрошавшего на линке скоростью 10G стоит файрвол. Практика показывает, что у многих - стоит. И выливается это зачастую как раз в подземный стук при увеличении нагрузки, когда state'ы начинают заканчиваться. > > Так или иначе - "Connection reset by peer" при живом бекенде как > > бы намекает на то, что в первую очередь надо смотреть, что > > происходит в сети. > > Я бы скорее подозревал наличие какой-то баги в сетевой карте. > > Например, в неправильном подсчёте чексуммы для пакетов с опцией sack > при включенном rx/tx checksumming offload'е, из-за чего все пакеты при > ретрасмитах дропаются. Коннекция умирает по таймауту. Но при этом > закрывается пакетом RST, который идёт без sack и потому доходит до > ядра получателя, вот и "Connection reset by peer". Так как насытить > линк 10G непросто, то потерь мало, но стоит хоть одному фрейму > пропасть -- sack, затем ретрансмиссии с sack, таймаут, reset. В таком сценарии непонятно, почему бекенд не видит ошибку сразу же, а ждёт ещё минуту после RST, после чего закрывает соединение по таймауту. -- Maxim Dounin http://nginx.org/ From bgx на protva.ru Fri Mar 4 07:50:32 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 4 Mar 2016 10:50:32 +0300 Subject: client timed out & readv() failed In-Reply-To: <20160304022431.GD31796@mdounin.ru> References: <20160303173627.GV31796@mdounin.ru> <20160303184109.GL23377@sie.protva.ru> <20160303194934.GB31796@mdounin.ru> <20160303211210.GM23377@sie.protva.ru> <20160304022431.GD31796@mdounin.ru> Message-ID: <20160304075032.GN23377@sie.protva.ru> On Fri, Mar 04, 2016 at 05:24:31AM +0300, Maxim Dounin wrote: > > > Так или иначе - "Connection reset by peer" при живом бекенде как > > > бы намекает на то, что в первую очередь надо смотреть, что > > > происходит в сети. > > > > Я бы скорее подозревал наличие какой-то баги в сетевой карте. > > > > Например, в неправильном подсчёте чексуммы для пакетов с опцией sack > > при включенном rx/tx checksumming offload'е, из-за чего все пакеты при > > ретрасмитах дропаются. Коннекция умирает по таймауту. Но при этом > > закрывается пакетом RST, который идёт без sack и потому доходит до > > ядра получателя, вот и "Connection reset by peer". Так как насытить > > линк 10G непросто, то потерь мало, но стоит хоть одному фрейму > > пропасть -- sack, затем ретрансмиссии с sack, таймаут, reset. > > В таком сценарии непонятно, почему бекенд не видит ошибку сразу же, а > ждёт ещё минуту после RST, после чего закрывает соединение по > таймауту. Да, верно. Для начала я бы предложил проверить, включены ли tcp timestamps с обеих сторон. Ну и поиграться с отключением разных offload'ов, попробовать отключить sack, уменьшить window scale до 3-4. -- Eugene Berdnikov From oleg.cherniy на gmail.com Fri Mar 4 08:36:44 2016 From: oleg.cherniy на gmail.com (=?UTF-8?B?0J7Qu9C10LMg0KfQtdGA0L3RltC5?=) Date: Fri, 4 Mar 2016 10:36:44 +0200 Subject: nginx-1.9.12 In-Reply-To: <20160224151106.GL31796@mdounin.ru> References: <20160224151106.GL31796@mdounin.ru> Message-ID: В 1.9.11 і 1.9.12 отвалился ngx_ctpp модуль http://ngx-ctpp.vbart.ru/. Floating point exception (core dumped) С 1.9.10 - все Ok Проверял на Fedora 20-23: А жаль, у нас еще используется. 2016-02-24 17:11 GMT+02:00 Maxim Dounin : > Изменения в nginx 1.9.12 > 24.02.2016 > > *) Добавление: кодирование Хаффмана заголовков ответов в HTTP/2. > Спасибо Владу Краснову. > > *) Добавление: директива worker_cpu_affinity теперь поддерживает более > 64 процессоров. > > *) Исправление: совместимость со сторонними модулями на C++; ошибка > появилась в 1.9.11. > Спасибо Piotr Sikora. > > *) Исправление: nginx не собирался статически с OpenSSL на Linux; > ошибка > появилась в 1.9.11. > > *) Исправление: директива "add_header ... always" с пустым значением не > удаляла из заголовков ошибочных ответов строки Last-Modified и ETag. > > *) Изменение: при использовании OpenSSL 1.0.2f в логах могли появляться > сообщения "called a function you should not call" и "shutdown while > in init". > > *) Исправление: ошибочные заголовки могли логгироваться некорректно. > > *) Исправление: утечки сокетов при использовании HTTP/2. > > *) Исправление: в модуле ngx_http_v2_module. > > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- --- С уважением, Олег Черний, руководитель отдела разработки AUTO.RIA.com RIA.com тел./факс.: 0 432 555-200 (многоканальний) моб: 0 (67) 295-27-52 E-mail: *oleg.cherniy на ria.ua * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mva на mva.name Fri Mar 4 13:12:55 2016 From: mva на mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 4 Mar 2016 19:12:55 +0600 Subject: nginx-1.9.12 In-Reply-To: References: <20160224151106.GL31796@mdounin.ru> Message-ID: <56D989D7.3080505@mva.name> 1) не замечал (хот не особо использую, но собираю с ним) 2) как ни странно, но его автор писал в этом же треде как раз последним перед вами :) Вот только, на сколько я помню, он не горит желанием его допиливать :) 04.03.2016 14:36, Олег Черній пишет: > В 1.9.11 і 1.9.12 отвалился ngx_ctpp модуль http://ngx-ctpp.vbart.ru/. > > Floating point exception (core dumped) > > С 1.9.10 - все Ok > > Проверял на Fedora 20-23: > > А жаль, у нас еще используется. > > > 2016-02-24 17:11 GMT+02:00 Maxim Dounin : > >> Изменения в nginx 1.9.12 >> 24.02.2016 >> >> *) Добавление: кодирование Хаффмана заголовков ответов в HTTP/2. >> Спасибо Владу Краснову. >> >> *) Добавление: директива worker_cpu_affinity теперь поддерживает более >> 64 процессоров. >> >> *) Исправление: совместимость со сторонними модулями на C++; ошибка >> появилась в 1.9.11. >> Спасибо Piotr Sikora. >> >> *) Исправление: nginx не собирался статически с OpenSSL на Linux; >> ошибка >> появилась в 1.9.11. >> >> *) Исправление: директива "add_header ... always" с пустым значением не >> удаляла из заголовков ошибочных ответов строки Last-Modified и ETag. >> >> *) Изменение: при использовании OpenSSL 1.0.2f в логах могли появляться >> сообщения "called a function you should not call" и "shutdown while >> in init". >> >> *) Исправление: ошибочные заголовки могли логгироваться некорректно. >> >> *) Исправление: утечки сокетов при использовании HTTP/2. >> >> *) Исправление: в модуле ngx_http_v2_module. >> >> >> -- >> Maxim Dounin >> http://nginx.org/ >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From bazilek на gmail.com Fri Mar 4 15:49:00 2016 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Fri, 4 Mar 2016 18:49:00 +0300 Subject: nginx to return compressed file while proxying In-Reply-To: <1487734.oouJlzL4Az@vbart-workstation> References: <1487734.oouJlzL4Az@vbart-workstation> Message-ID: спасибо, да очевидно это оно, можно ли это понять из приведенного лога и что означает HTTP/1.1 200 OK в обоих случаях 2016-03-03 19:49 GMT+03:00 Valentin V. Bartenev : > On Thursday 03 March 2016 19:39:37 Vasil Mikhalenya wrote: > > Всем привет, > > > > помогите понять почему nginx(host: o) отдает несжатый файл в случае > > проксирования другому nginx(host: l) однако отдает сжатый для curl > [..] > > Разгадка видимо в соотношении значений директив > gzip_http_version и proxy_http_version? > > http://nginx.org/r/gzip_http_version/ru > http://nginx.org/r/proxy_http_version/ru > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Vasil Mikhalenya ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Mar 4 15:57:45 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 4 Mar 2016 18:57:45 +0300 Subject: =?UTF-8?Q?Re=3A_zero_size_buf_in_output_=D0=BF=D1=80=D0=B8_proxy_cache?= In-Reply-To: <20160225172523.GC31796@mdounin.ru> References: <20160216200457.GV34421@mdounin.ru> <1665194.4NCDIQP41P@cybernote> <20160225172523.GC31796@mdounin.ru> Message-ID: <20160304155745.GH31796@mdounin.ru> Hello! On Thu, Feb 25, 2016 at 08:25:23PM +0300, Maxim Dounin wrote: > On Thu, Feb 25, 2016 at 06:19:04PM +0300, Иван wrote: > > > Можем ли мы еще что-то сделать для решения этой проблемы? [...] > В почте у меня соответствующее письмо отмечено, но вряд ли я > доберусь до "посмотреть это подробнее" в ближайшее время. JFYI, запостил в тикет[1] патч для этой проблемы, благо она тут случайно воспроизвелась. [1] https://trac.nginx.org/nginx/ticket/918 # HG changeset patch # User Maxim Dounin # Date 1457105784 -10800 # Fri Mar 04 18:36:24 2016 +0300 # Node ID 36a4f55e09d6910f79507635b6e5a773e487fa08 # Parent c5f81dcf97a79576138917501c9a6cc6f53ee930 Upstream: fixed "zero size buf" alerts with cache (ticket #918). If caching was used, "zero size buf in output" alerts might appear in logs if a client prematurely closed connection. Alerts appeared in the following situation: - writing to client returned an error, so event pipe drained all busy buffers leaving body output filters in an invalid state; - when upstream response was fully received, ngx_http_upstream_finalize_request() tried to flush all pending data. Fix is to avoid flushing body if c->error is set. diff --git a/src/http/ngx_http_upstream.c b/src/http/ngx_http_upstream.c --- a/src/http/ngx_http_upstream.c +++ b/src/http/ngx_http_upstream.c @@ -4068,7 +4068,8 @@ ngx_http_upstream_finalize_request(ngx_h if (!u->header_sent || rc == NGX_HTTP_REQUEST_TIME_OUT - || rc == NGX_HTTP_CLIENT_CLOSED_REQUEST) + || rc == NGX_HTTP_CLIENT_CLOSED_REQUEST + || r->connection->error) { ngx_http_finalize_request(r, rc); return; -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Fri Mar 4 16:03:45 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 4 Mar 2016 19:03:45 +0300 Subject: nginx to return compressed file while proxying In-Reply-To: References: <1487734.oouJlzL4Az@vbart-workstation> Message-ID: <20160304160230.GI31796@mdounin.ru> Hello! On Fri, Mar 04, 2016 at 06:49:00PM +0300, Vasil Mikhalenya wrote: > можно ли это понять из приведенного лога и что означает HTTP/1.1 200 OK в > обоих случаях Версия, написанная в HTTP-ответе - это максимальная версия, которую поддерживает сервер. При этом само сообщение формируется в соответствии с той версией, которую передал клиент. Подробнее тут: http://tools.ietf.org/html/rfc7230#section-2.6 -- Maxim Dounin http://nginx.org/ From vbart на nginx.com Fri Mar 4 16:04:34 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 04 Mar 2016 19:04:34 +0300 Subject: nginx to return compressed file while proxying In-Reply-To: References: <1487734.oouJlzL4Az@vbart-workstation> Message-ID: <44157864.vCACXdXnxG@vbart-workstation> On Friday 04 March 2016 18:49:00 Vasil Mikhalenya wrote: > спасибо, > да очевидно это оно, > можно ли это понять из приведенного лога и что означает HTTP/1.1 200 OK в > обоих случаях > [..] Из переведенного лога - едва ли, из приведенного конфига - да. К тому же это самая частая причина почему не работает gzip, когда люди настраивают проксирование c nginx на nginx. HTTP/1.1 200 OK означает, что сервер поддерживает работу по протоколу HTTP/1 вплоть до версии 1.1. https://tools.ietf.org/html/rfc7230#section-2.6 | A server SHOULD send a response version equal to the highest version | to which the server is conformant that has a major version less than | or equal to the one received in the request. -- Валентин Бартенев From nginx-forum на forum.nginx.org Tue Mar 8 09:57:50 2016 From: nginx-forum на forum.nginx.org (Romano) Date: Tue, 08 Mar 2016 04:57:50 -0500 Subject: =?UTF-8?B?0JrQtdGI0LjRgNC+0LLQsNC90LjQtSDQtNC70Y8g0L7RgtC00LXQu9GM0L3QvtCz?= =?UTF-8?B?0L4gY29va2ll?= Message-ID: <631542930981ac851c7b1b96acf63c6a.NginxMailingListRussian@forum.nginx.org> Здравствуйте! Как известно Nginx не кеширует ответ от сервера, если в заголовках присутствует Set-Cookie. Чтобы разрешить кеширование с cookies можно воспользоваться директивой proxy_ignore_headers. Возможно ли проигнорировать cookies по их названию? Скажем, когда в заголовке Set-Cookie присутствует только один cookie с уникальным именем, который может быть проигнорирован. Или существует какой-либо способ принудительного кеширования по уникальному заголовку, который по статусу был бы выше proxy_ignore_headers? Спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265155,265155#msg-265155 From mdounin на mdounin.ru Tue Mar 8 23:28:27 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 9 Mar 2016 02:28:27 +0300 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0LTQu9GPINC+0YLQtNC10LvRjNC9?= =?UTF-8?B?0L7Qs9C+IGNvb2tpZQ==?= In-Reply-To: <631542930981ac851c7b1b96acf63c6a.NginxMailingListRussian@forum.nginx.org> References: <631542930981ac851c7b1b96acf63c6a.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160308232827.GV31796@mdounin.ru> Hello! On Tue, Mar 08, 2016 at 04:57:50AM -0500, Romano wrote: > Здравствуйте! Как известно Nginx не кеширует ответ от сервера, если в > заголовках присутствует Set-Cookie. Чтобы разрешить кеширование с cookies > можно воспользоваться директивой proxy_ignore_headers. > > Возможно ли проигнорировать cookies по их названию? Скажем, когда в > заголовке Set-Cookie присутствует только один cookie с уникальным именем, > который может быть проигнорирован. Или существует какой-либо способ > принудительного кеширования по уникальному заголовку, который по статусу был > бы выше proxy_ignore_headers? Если очень хочется - можно включить "proxy_ignore_headers Set-Cookie", и повыпиливать лобзиком с помощью proxy_no_cache (http://nginx.org/r/proxy_no_cache/ru) и map'ов. Но я бы не рекомендовал - конфиг получится нетривиальный и слабопригодный для дальнейшей поддержки, особенно с учётом того, что закешированные куки неплохо бы ещё и убрать из ответов. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Wed Mar 9 11:20:04 2016 From: nginx-forum на forum.nginx.org (Romano) Date: Wed, 09 Mar 2016 06:20:04 -0500 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0LTQu9GPINC+0YLQtNC10LvRjNC9?= =?UTF-8?B?0L7Qs9C+IGNvb2tpZQ==?= In-Reply-To: <20160308232827.GV31796@mdounin.ru> References: <20160308232827.GV31796@mdounin.ru> Message-ID: <161d7dd7c473b74d08b41006fe6d7535.NginxMailingListRussian@forum.nginx.org> Т.е. переменные $cookie_* устанавливаются и при ответе со стороны веб-сервера (response)? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265155,265180#msg-265180 From nginx-forum на forum.nginx.org Wed Mar 9 13:50:18 2016 From: nginx-forum на forum.nginx.org (izlom) Date: Wed, 09 Mar 2016 08:50:18 -0500 Subject: =?UTF-8?B?c3NsIGNlcnRpZmljYXRlIHNzbCBjZXJ0aWZpY2F0ZSBrZXkg0Lgg0L/QtdGA0LU=?= =?UTF-8?B?0LzQtdC90L3Ri9C1?= Message-ID: <70bf8a1358ae6cce982ca02fc7c977b0.NginxMailingListRussian@forum.nginx.org> Здравствуйте! Имеем мапы вида map $http_host $ssl_certificate { hostnames; default "/etc/nginx/ssl/shared.pem"; .domain.com /etc/nginx/ssl/domain.com.cert; } map $http_host $ssl_key { hostnames; default "/etc/nginx/ssl/shared.key"; .domain.com /etc/nginx/ssl/domain.com.key; } И конфиг ssl_certificate $ssl_certificate; ssl_certificate_key $ssl_key; Но при попытке их использовать параметры оприделают их не как переменные, а как имя файлов. Что можно предпринять? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265186,265186#msg-265186 From vl на nginx.com Wed Mar 9 13:58:17 2016 From: vl на nginx.com (Vladimir Homutov) Date: Wed, 9 Mar 2016 16:58:17 +0300 Subject: =?UTF-8?B?UmU6IHNzbCBjZXJ0aWZpY2F0ZSBzc2wgY2VydGlmaWNhdGUga2V5INC4INC/0LU=?= =?UTF-8?B?0YDQtdC80LXQvdC90YvQtXk=?= In-Reply-To: <70bf8a1358ae6cce982ca02fc7c977b0.NginxMailingListRussian@forum.nginx.org> References: <70bf8a1358ae6cce982ca02fc7c977b0.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160309135816.GA991@vlpc.nginx.com> On Wed, Mar 09, 2016 at 08:50:18AM -0500, izlom wrote: > Здравствуйте! > > Имеем мапы вида > > map $http_host $ssl_certificate { > hostnames; > default "/etc/nginx/ssl/shared.pem"; > .domain.com /etc/nginx/ssl/domain.com.cert; > } > > map $http_host $ssl_key { > hostnames; > default "/etc/nginx/ssl/shared.key"; > .domain.com /etc/nginx/ssl/domain.com.key; > } > > И конфиг > ssl_certificate $ssl_certificate; > ssl_certificate_key $ssl_key; > > Но при попытке их использовать параметры оприделают их не как переменные, а > как имя файлов. потому что данные директивы не поддерживают переменных. сертификаты загружаются в openssl при старте nginx. более того, переменная http_host станет известна только когда nginx прочитает запрос, т.е. уже после установления ssl соединения, для чего и нужен сертификат. From mdounin на mdounin.ru Wed Mar 9 15:18:24 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 9 Mar 2016 18:18:24 +0300 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0LTQu9GPINC+0YLQtNC10LvRjNC9?= =?UTF-8?B?0L7Qs9C+IGNvb2tpZQ==?= In-Reply-To: <161d7dd7c473b74d08b41006fe6d7535.NginxMailingListRussian@forum.nginx.org> References: <20160308232827.GV31796@mdounin.ru> <161d7dd7c473b74d08b41006fe6d7535.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160309151824.GC31796@mdounin.ru> Hello! On Wed, Mar 09, 2016 at 06:20:04AM -0500, Romano wrote: > Т.е. переменные $cookie_* устанавливаются и при ответе со стороны > веб-сервера (response)? Нет, с чего бы? При отдаче ответа доступны переменные $upstream_*, в частности - $upstream_http_* и $upstream_cookie_*: http://nginx.org/r/$upstream_http_/ru http://nginx.org/r/$upstream_cookie_/ru -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Wed Mar 9 20:02:26 2016 From: nginx-forum на forum.nginx.org (Romano) Date: Wed, 09 Mar 2016 15:02:26 -0500 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0LTQu9GPINC+0YLQtNC10LvRjNC9?= =?UTF-8?B?0L7Qs9C+IGNvb2tpZQ==?= In-Reply-To: <20160309151824.GC31796@mdounin.ru> References: <20160309151824.GC31796@mdounin.ru> Message-ID: <24ed4d6869facff33990feed72ac20b5.NginxMailingListRussian@forum.nginx.org> Спасибо за подсказку, сделал так: http { ... map $upstream_http_x_custom_header $custom_header { default ''; 1 'custom_header=1'; } ... } location @proxy { ... add_header Set-Cookie $custom_header; proxy_hide_header X-Custom-Header; ... } Не отдаёт из кеша кешированный адрес на первый запрос, следующие запросы возвращают кешированную страницу, но с куки custom_header (видимо заголовок X-Custom-Header также кешируется). Получается, add_header связан с процессом кеширования, хотя казалось, что заголовок добавляется уже после выборки из кеша. proxy_ignore_headers не принимает X-Custom-Header А задача не сложная, необходимо сообщить js-скриптам, что они работают с кешированной страницей (без каких-либо дополнительных запросов к серверу). Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265155,265198#msg-265198 From bazilek на gmail.com Wed Mar 9 20:19:59 2016 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Wed, 9 Mar 2016 23:19:59 +0300 Subject: nginx to return compressed file while proxying In-Reply-To: <44157864.vCACXdXnxG@vbart-workstation> References: <1487734.oouJlzL4Az@vbart-workstation> <44157864.vCACXdXnxG@vbart-workstation> Message-ID: спасибо большое, я же клоню к тому, возможно, имеет смысл подчеркнуть это в документации или расширить вывод в debug output версией HTTP которую запросил клиент 2016-03-04 19:04 GMT+03:00 Валентин Бартенев : > On Friday 04 March 2016 18:49:00 Vasil Mikhalenya wrote: > > спасибо, > > да очевидно это оно, > > можно ли это понять из приведенного лога и что означает HTTP/1.1 200 OK в > > обоих случаях > > > [..] > > Из переведенного лога - едва ли, из приведенного конфига - да. К тому же > это самая частая причина почему не работает gzip, когда люди настраивают > проксирование c nginx на nginx. > > > HTTP/1.1 200 OK означает, что сервер поддерживает работу по протоколу > HTTP/1 > вплоть до версии 1.1. > > https://tools.ietf.org/html/rfc7230#section-2.6 > > | A server SHOULD send a response version equal to the highest version > | to which the server is conformant that has a major version less than > | or equal to the one received in the request. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Vasil Mikhalenya ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Thu Mar 10 12:27:00 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 10 Mar 2016 15:27 +0300 Subject: nginx to return compressed file while proxying In-Reply-To: References: <44157864.vCACXdXnxG@vbart-workstation> Message-ID: <4645410.4Zo4ootlml@vbart-workstation> On Wednesday 09 March 2016 23:19:59 Vasil Mikhalenya wrote: > спасибо большое, > я же клоню к тому, возможно, имеет смысл подчеркнуть это в документации или > расширить вывод в debug output версией HTTP которую запросил клиент > [..] Строка запроса есть в дебаг-логе, просто вы привели неполный лог. -- Валентин Бартенев From bazilek на gmail.com Thu Mar 10 13:12:14 2016 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Thu, 10 Mar 2016 16:12:14 +0300 Subject: can not connect to nginx under highload Message-ID: При определенном трафике более нет возможности установить соединение на порт 80. Коллеги, помогите идеей, в чем может быть дело. Думал проблема в backlog, однако нет. [root на up ~]# ss -s Total: 66355 (kernel 66512) TCP: 84985 (estab 77459, closed 5381, orphaned 1962, synrecv 0, timewait 5110/0), ports 0 Transport Total IP IPv6 * 66512 - - RAW 0 0 0 UDP 10 9 1 TCP 79604 79604 0 INET 79614 79613 1 FRAG 0 0 0 [root на up ~]# netstat -an | grep -c SYN_RECV 5534 [root на up ~]# cat /proc/net/sockstat sockets: used 66920 TCP: inuse 80038 orphan 1922 tw 4744 alloc 80400 mem 3659114 UDP: inuse 9 mem 2 UDPLITE: inuse 0 RAW: inuse 0 FRAG: inuse 0 memory 0 [root на up ~]# uname -a Linux up 3.10.0-327.4.5.el7.x86_64 #1 SMP Mon Jan 25 22:07:14 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [root на up ~]# nginx -V nginx version: nginx/1.9.10 built by gcc 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) built with OpenSSL 1.0.2f 28 Jan 2016 TLS SNI support enabled на порт ssh на этом же интерфейсе соединение успешно устанавливается спасибо -- Best regards, Vasil Mikhalenya ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bazilek на gmail.com Thu Mar 10 13:27:55 2016 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Thu, 10 Mar 2016 16:27:55 +0300 Subject: nginx to return compressed file while proxying In-Reply-To: <4645410.4Zo4ootlml@vbart-workstation> References: <44157864.vCACXdXnxG@vbart-workstation> <4645410.4Zo4ootlml@vbart-workstation> Message-ID: Согласен, не понимаю, как не заметил. Спасибо еще раз. 2016-03-10 15:27 GMT+03:00 Валентин Бартенев : > On Wednesday 09 March 2016 23:19:59 Vasil Mikhalenya wrote: > > спасибо большое, > > я же клоню к тому, возможно, имеет смысл подчеркнуть это в документации > или > > расширить вывод в debug output версией HTTP которую запросил клиент > > > [..] > > Строка запроса есть в дебаг-логе, просто вы привели неполный лог. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Vasil Mikhalenya ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Thu Mar 10 13:37:25 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 10 Mar 2016 16:37:25 +0300 Subject: can not connect to nginx under highload In-Reply-To: References: Message-ID: <20160310133725.GB28432@cio.protva.ru> On Thu, Mar 10, 2016 at 04:12:14PM +0300, Vasil Mikhalenya wrote: > При определенном трафике более нет возможности установить соединение на > порт 80. > > Коллеги, помогите идеей, в чем может быть дело. Думал проблема в backlog, > однако нет. Как сделан такой вывод? > [root на up ~]# netstat -an | grep -c SYN_RECV > 5534 Строго говоря, нужно отделять коннекции на 80й порт от остальных. Однако, разве этого мало? Посмотрите, сколько запросов за единицу времени обрабатывает сервер и посчитайте, сколько нужно времени на ожидание ответа в очереди такой длины. -- Eugene Berdnikov From mdounin на mdounin.ru Thu Mar 10 15:16:22 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 10 Mar 2016 18:16:22 +0300 Subject: can not connect to nginx under highload In-Reply-To: References: Message-ID: <20160310151622.GB12808@mdounin.ru> Hello! On Thu, Mar 10, 2016 at 04:12:14PM +0300, Vasil Mikhalenya wrote: > При определенном трафике более нет возможности установить соединение на > порт 80. > > Коллеги, помогите идеей, в чем может быть дело. Думал проблема в backlog, > однако нет. > > [root на up ~]# ss -s > Total: 66355 (kernel 66512) > TCP: 84985 (estab 77459, closed 5381, orphaned 1962, synrecv 0, timewait > 5110/0), ports 0 [...] Посмотрите "ss -nlt", он вам покажет очереди по конкретным listen-сокетам. -- Maxim Dounin http://nginx.org/ From bazilek на gmail.com Thu Mar 10 15:30:48 2016 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Thu, 10 Mar 2016 18:30:48 +0300 Subject: can not connect to nginx under highload In-Reply-To: <20160310133725.GB28432@cio.protva.ru> References: <20160310133725.GB28432@cio.protva.ru> Message-ID: 2016-03-10 16:37 GMT+03:00 Evgeniy Berdnikov : > On Thu, Mar 10, 2016 at 04:12:14PM +0300, Vasil Mikhalenya wrote: > > При определенном трафике более нет возможности установить соединение на > > порт 80. > > > > Коллеги, помогите идеей, в чем может быть дело. Думал проблема в backlog, > > однако нет. > > Как сделан такой вывод? > > по умолчанию в nginx на linux размер бэклога равен 511, соответственно netstat -an | grep -c SYN_RECV возвращает число очень близкое к 511 > [root на up ~]# netstat -an | grep -c SYN_RECV > > 5534 > > Строго говоря, нужно отделять коннекции на 80й порт от остальных. > другими соединениями можно принебречь > > Однако, разве этого мало? Посмотрите, сколько запросов за единицу > времени обрабатывает сервер и посчитайте, сколько нужно времени > на ожидание ответа в очереди такой длины. > вот тут не понял > -- > Eugene Berdnikov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru спасибо за помощь -- Best regards, Vasil Mikhalenya ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bazilek на gmail.com Thu Mar 10 15:32:44 2016 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Thu, 10 Mar 2016 18:32:44 +0300 Subject: can not connect to nginx under highload In-Reply-To: <20160310151622.GB12808@mdounin.ru> References: <20160310151622.GB12808@mdounin.ru> Message-ID: возможно я неверно интерпретирую вывод, однако проблемы не вижу [root на up~]# ss -nlt State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 4360 12000 *:80 *:* LISTEN 0 128 *:2200 *:* LISTEN 0 100 127.0.0.1:25 *:* LISTEN 0 511 *:443 *:* LISTEN 0 511 127.0.0.1:8098 *:* LISTEN 0 128 *:10050 *:* LISTEN 0 128 127.0.0.1:199 *:* спасибо 2016-03-10 18:16 GMT+03:00 Maxim Dounin : > Hello! > > On Thu, Mar 10, 2016 at 04:12:14PM +0300, Vasil Mikhalenya wrote: > > > При определенном трафике более нет возможности установить соединение на > > порт 80. > > > > Коллеги, помогите идеей, в чем может быть дело. Думал проблема в backlog, > > однако нет. > > > > [root на up ~]# ss -s > > Total: 66355 (kernel 66512) > > TCP: 84985 (estab 77459, closed 5381, orphaned 1962, synrecv 0, > timewait > > 5110/0), ports 0 > > [...] > > Посмотрите "ss -nlt", он вам покажет очереди по конкретным > listen-сокетам. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Vasil Mikhalenya ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu Mar 10 21:28:38 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Thu, 10 Mar 2016 16:28:38 -0500 Subject: Headers-Not-Case-Sensitive Message-ID: <7ef6f69ae408da0a259ecaad56340f0e.NginxMailingListRussian@forum.nginx.org> В HTTP спецификации, имена заголовков должны быть регистро независимы. Нам на бекенде удобней отдавать все в нижнем регистре, проблем с Nginx или другими прокси не будет? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265230,265230#msg-265230 From bgx на protva.ru Thu Mar 10 22:18:41 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 11 Mar 2016 01:18:41 +0300 Subject: can not connect to nginx under highload In-Reply-To: References: <20160310133725.GB28432@cio.protva.ru> Message-ID: <20160310221841.GK11145@sie.protva.ru> On Thu, Mar 10, 2016 at 06:30:48PM +0300, Vasil Mikhalenya wrote: > 2016-03-10 16:37 GMT+03:00 Evgeniy Berdnikov : > > > On Thu, Mar 10, 2016 at 04:12:14PM +0300, Vasil Mikhalenya wrote: > > > При определенном трафике более нет возможности установить соединение на > > > порт 80. > > > > > > Коллеги, помогите идеей, в чем может быть дело. Думал проблема в backlog, > > > однако нет. > > > > Как сделан такой вывод? > > > по умолчанию в nginx на linux размер бэклога равен 511, > соответственно netstat -an | grep -c SYN_RECV возвращает число очень > близкое к 511 Ну и? Как интерпретировать факт совпадения этих чисел? Если совпадает, то проблема в backlog или нет? Почему? > > [root на up ~]# netstat -an | grep -c SYN_RECV > > > 5534 Здесь не 511, что это значит? Ваше мнение, сколько должно быть? > > Однако, разве этого мало? Посмотрите, сколько запросов за единицу > > времени обрабатывает сервер и посчитайте, сколько нужно времени > > на ожидание ответа в очереди такой длины. > > > вот тут не понял Сервер, похоже, не справляется с нагрузкой. Просто не успевает обрабатывать запросы. При этом какой бы величины ни был backlog, он всегда будет переполнен, либо соединения в хвосте очереди будут умирать по таймауту. -- Eugene Berdnikov From bazilek на gmail.com Fri Mar 11 08:46:09 2016 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Fri, 11 Mar 2016 11:46:09 +0300 Subject: can not connect to nginx under highload In-Reply-To: <20160310221841.GK11145@sie.protva.ru> References: <20160310133725.GB28432@cio.protva.ru> <20160310221841.GK11145@sie.protva.ru> Message-ID: 2016-03-11 1:18 GMT+03:00 Evgeniy Berdnikov : > On Thu, Mar 10, 2016 at 06:30:48PM +0300, Vasil Mikhalenya wrote: > > 2016-03-10 16:37 GMT+03:00 Evgeniy Berdnikov : > > > > > On Thu, Mar 10, 2016 at 04:12:14PM +0300, Vasil Mikhalenya wrote: > > > > При определенном трафике более нет возможности установить соединение > на > > > > порт 80. > > > > > > > > Коллеги, помогите идеей, в чем может быть дело. Думал проблема в > backlog, > > > > однако нет. > > > > > > Как сделан такой вывод? > > > > > по умолчанию в nginx на linux размер бэклога равен 511, > > соответственно netstat -an | grep -c SYN_RECV возвращает число очень > > близкое к 511 > > Ну и? Как интерпретировать факт совпадения этих чисел? Если совпадает, > то проблема в backlog или нет? Почему? > если бэклог ограничен 511 и SYN_RECV близко к этому число - значит потенциально новые соединения не могут попасть в бэклог т.к. он почти всегда заполнен > > > > [root на up ~]# netstat -an | grep -c SYN_RECV > > > > 5534 > > Здесь не 511, что это значит? Ваше мнение, сколько должно быть? > здесь число меньшее текущего значения бэклога 12000 - соответсвенно в размер бэклога не упираемся > > > > Однако, разве этого мало? Посмотрите, сколько запросов за единицу > > > времени обрабатывает сервер и посчитайте, сколько нужно времени > > > на ожидание ответа в очереди такой длины. > > > > > вот тут не понял > > Сервер, похоже, не справляется с нагрузкой. Просто не успевает > обрабатывать запросы. При этом какой бы величины ни был backlog, > он всегда будет переполнен, либо соединения в хвосте очереди > будут умирать по таймауту. > возможно ли как-то подтвердить это предположение ничего в dmesg или syslog нету -- > Eugene Berdnikov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > спасибо -- Best regards, Vasil Mikhalenya ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Fri Mar 11 09:34:29 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 11 Mar 2016 12:34:29 +0300 Subject: can not connect to nginx under highload In-Reply-To: References: <20160310133725.GB28432@cio.protva.ru> <20160310221841.GK11145@sie.protva.ru> Message-ID: <20160311093429.GO5474@protva.ru> On Fri, Mar 11, 2016 at 11:46:09AM +0300, Vasil Mikhalenya wrote: > 2016-03-11 1:18 GMT+03:00 Evgeniy Berdnikov : > > On Thu, Mar 10, 2016 at 06:30:48PM +0300, Vasil Mikhalenya wrote: > > > 2016-03-10 16:37 GMT+03:00 Evgeniy Berdnikov : > > > > > > > Однако, разве этого мало? Посмотрите, сколько запросов за единицу > > > > времени обрабатывает сервер и посчитайте, сколько нужно времени > > > > на ожидание ответа в очереди такой длины. > > > > > > > вот тут не понял > > > > Сервер, похоже, не справляется с нагрузкой. Просто не успевает > > обрабатывать запросы. При этом какой бы величины ни был backlog, > > он всегда будет переполнен, либо соединения в хвосте очереди > > будут умирать по таймауту. > > > возможно ли как-то подтвердить это предположение Так посчитайте для начала. > ничего в dmesg или syslog нету И не должно быть. Но если хотите, можно логгировать входящие пакеты, например, так: iptables -t raw -I PREROUTING -p tcp --dport 80 --syn -j TRACE iptables -I INPUT -p tcp --dport 80 -j LOG --log-tcp-sequence Выделяя seq & src_ip можно следить за ретрансмиссиями syn'ов. -- Eugene Berdnikov From bazilek на gmail.com Fri Mar 11 12:19:37 2016 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Fri, 11 Mar 2016 15:19:37 +0300 Subject: can not connect to nginx under highload In-Reply-To: <20160311093429.GO5474@protva.ru> References: <20160310133725.GB28432@cio.protva.ru> <20160310221841.GK11145@sie.protva.ru> <20160311093429.GO5474@protva.ru> Message-ID: Евгений, я все еще не могу понять, что вы предлагаете, можете изложить еще раз подробнее. Спасибо 2016-03-11 12:34 GMT+03:00 Evgeniy Berdnikov : > On Fri, Mar 11, 2016 at 11:46:09AM +0300, Vasil Mikhalenya wrote: > > 2016-03-11 1:18 GMT+03:00 Evgeniy Berdnikov : > > > On Thu, Mar 10, 2016 at 06:30:48PM +0300, Vasil Mikhalenya wrote: > > > > 2016-03-10 16:37 GMT+03:00 Evgeniy Berdnikov : > > > > > > > > > Однако, разве этого мало? Посмотрите, сколько запросов за единицу > > > > > времени обрабатывает сервер и посчитайте, сколько нужно времени > > > > > на ожидание ответа в очереди такой длины. > > > > > > > > > вот тут не понял > > > > > > Сервер, похоже, не справляется с нагрузкой. Просто не успевает > > > обрабатывать запросы. При этом какой бы величины ни был backlog, > > > он всегда будет переполнен, либо соединения в хвосте очереди > > > будут умирать по таймауту. > > > > > возможно ли как-то подтвердить это предположение > > Так посчитайте для начала. > > > ничего в dmesg или syslog нету > > И не должно быть. Но если хотите, можно логгировать входящие пакеты, > например, так: > > iptables -t raw -I PREROUTING -p tcp --dport 80 --syn -j TRACE > iptables -I INPUT -p tcp --dport 80 -j LOG --log-tcp-sequence > > Выделяя seq & src_ip можно следить за ретрансмиссиями syn'ов. > -- > Eugene Berdnikov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Vasil Mikhalenya ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Mar 11 13:04:50 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 11 Mar 2016 16:04:50 +0300 Subject: Headers-Not-Case-Sensitive In-Reply-To: <7ef6f69ae408da0a259ecaad56340f0e.NginxMailingListRussian@forum.nginx.org> References: <7ef6f69ae408da0a259ecaad56340f0e.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160311130450.GF12808@mdounin.ru> Hello! On Thu, Mar 10, 2016 at 04:28:38PM -0500, S.A.N wrote: > В HTTP спецификации, имена заголовков должны быть регистро независимы. > Нам на бекенде удобней отдавать все в нижнем регистре, проблем с Nginx или > другими прокси не будет? С nginx'ом - нет. -- Maxim Dounin http://nginx.org/ From universite на ukr.net Fri Mar 11 13:47:30 2016 From: universite на ukr.net (Vladislav Prodan) Date: Fri, 11 Mar 2016 15:47:30 +0200 Subject: =?UTF-8?Q?Max_open_files____________1024__=D1=83_nginx=3A_master_process?= Message-ID: <1457703895.279397581.prczoxaz@frv35.fwdcdn.com> Здравствуйте. Проблема с лимитом открытых файлов в 1024 # ps -auxwww | grep nginx root      2139  0.0  0.0  31860  2512 ?        Ss   05:42   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf www-data  2140  0.0  0.0  36420  8212 ?        S    05:42   0:00 nginx: worker process www-data  2141  0.0  0.0  36116  7132 ?        S    05:42   0:00 nginx: worker process www-data  2142  0.0  0.0  36116  7132 ?        S    05:42   0:00 nginx: worker process www-data  2143  0.0  0.0  36116  7132 ?        S    05:42   0:00 nginx: worker process www-data  2144  0.0  0.0  36116  7132 ?        S    05:42   0:00 nginx: worker process www-data  2145  0.0  0.0  36116  7132 ?        S    05:42   0:00 nginx: worker process www-data  2146  0.0  0.0  36116  7132 ?        S    05:42   0:00 nginx: worker process www-data  2147  0.0  0.0  36116  7132 ?        S    05:42   0:00 nginx: worker process root      2196  0.0  0.0  13972  2212 pts/1    S+   05:45   0:00 grep nginx # cat /proc/2139/limits Limit                     Soft Limit           Hard Limit           Units Max cpu time              unlimited            unlimited            seconds Max file size             unlimited            unlimited            bytes Max data size             unlimited            unlimited            bytes Max stack size            8388608              unlimited            bytes Max core file size        0                    unlimited            bytes Max resident set          unlimited            unlimited            bytes Max processes             128495               128495               processes Max open files            1024                 4096                 files Max locked memory         65536                65536                bytes Max address space         unlimited            unlimited            bytes Max file locks            unlimited            unlimited            locks Max pending signals       128495               128495               signals Max msgqueue size         819200               819200               bytes Max nice priority         0                    0 Max realtime priority     0                    0 Max realtime timeout      unlimited            unlimited            us # cat /proc/sys/fs/file-max 3289412 #cat /etc/security/limits.conf * soft nofile 16384 * hard nofile 16384 nginx   soft    nofile      10000 nginx   hard    nofile      30000 mysql   soft    nofile  102400 mysql   hard    nofile  102400 mysql   soft    nproc   16384 mysql   hard    nproc   16384 Debian 8.3 x64 # nginx -V nginx version: nginx/1.8.1 built by gcc 4.9.2 (Debian 4.9.2-10) built with OpenSSL 1.0.1k 8 Jan 2015 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,--as-needed' --with-ipv6 -- Vladislav V. Prodan System & Network Administrator support.od.ua ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From basil на vpm.net.ua Fri Mar 11 14:26:47 2016 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Fri, 11 Mar 2016 16:26:47 +0200 Subject: =?UTF-8?Q?Re=3A_Max_open_files_1024_=D1=83_nginx=3A_master_process?= In-Reply-To: <1457703895.279397581.prczoxaz@frv35.fwdcdn.com> References: <1457703895.279397581.prczoxaz@frv35.fwdcdn.com> Message-ID: это ? # set open fd limit to 30000 worker_rlimit_nofile 30000; 2016-03-11 15:47 GMT+02:00 Vladislav Prodan : > Здравствуйте. > > Проблема с лимитом открытых файлов в 1024 > > # ps -auxwww | grep nginx > root 2139 0.0 0.0 31860 2512 ? Ss 05:42 0:00 nginx: > master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > www-data 2140 0.0 0.0 36420 8212 ? S 05:42 0:00 nginx: > worker process > www-data 2141 0.0 0.0 36116 7132 ? S 05:42 0:00 nginx: > worker process > www-data 2142 0.0 0.0 36116 7132 ? S 05:42 0:00 nginx: > worker process > www-data 2143 0.0 0.0 36116& nbsp; 7132 ? S 05:42 0:00 > nginx: worker process > www-data 2144 0.0 0.0 36116 7132 ? S 05:42 0:00 nginx: > worker process > www-data 2145 0.0 0.0 36116 7132 ? S 05:42 0:00 nginx: > worker process > www-data 2146 0.0 0.0 36116 7132 ? S 05:42 0:00 nginx: > worker process > www-data 2147 0.0 0.0 36116 7132 ? S 05:42 0:00 nginx: > worker process > root 2196 0.0 0.0 13972 2212 pts/1 S+ 05:45 0:00 grep nginx > > # ca t /proc/2139/limits > Limit Soft Limit Hard Limit Units > Max cpu time unlimited unlimited seconds > Max file size unlimited unlimited bytes > Max data size unlimited unlimited &nb sp; > bytes > Max stack size 8388608 unlimited bytes > Max core file size 0 unlimited bytes > Max resident set unlimited unlimited bytes > Max processes 128495 128495 &nb sp; > processes > Max open files 1024 4096 files > Max locked memory 65536 65536 bytes > Max address space unlimited unlimited bytes > Max file locks unlimited &nbs p; unlimited > locks > Max pending signals 128495 128495 signals > Max msgqueue size 819200 819200 bytes > Max nice priority 0 0 > Max realtime priority 0 0 > Max real time timeout unlimited unlimited us > > > # cat /proc/sys/fs/file-max > 3289412 > > #cat /etc/security/limits.conf > * soft nofile 16384 > * hard nofile 16384 > > nginx soft nofile 10000 > nginx hard nofile 30000 > > mysql soft nofile 102400 > mysql hard nofile 102400 > mysql soft nproc 16384 > mysql hard nproc 16384 > > > Debian 8.3 x64 > > # nginx -V > nginx version: nginx/1.8.1 > built by gcc 4.9.2 (Debian 4.9.2-10) > built with OpenSSL 1.0.1k 8 Jan 2015 > TLS SNI support enabled > configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx > --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log > --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid > --lock-path=/var/run/nginx.lock > --http-client-body-temp-path=/var/cache/nginx/client_temp > --http-proxy-temp-path=/var/cache/nginx/proxy_temp > --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp > --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp > --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx > --with-http_ssl_module --with-http_realip_module > --with-http_addition_module --with-http_sub_module --with-http_dav_module > --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module > --with-http_gzip_static_module --with-http_random_index_module > --with-http_secure_link_module --with-http_stub_status_module > --with-http_auth_request_module --with-mail --with-mail_ssl_module > --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 > -fstack-protector -strong -Wformat -Werror=format-security > -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,--as-needed' > --with-ipv6 > > > > -- > Vladislav V. Prodan > System & Network Administrator > support.od.ua > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Mar 11 14:41:26 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Fri, 11 Mar 2016 09:41:26 -0500 Subject: Headers-Not-Case-Sensitive In-Reply-To: <20160311130450.GF12808@mdounin.ru> References: <20160311130450.GF12808@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > С nginx'ом - нет. Ok, спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265230,265251#msg-265251 From mdounin на mdounin.ru Fri Mar 11 15:47:34 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 11 Mar 2016 18:47:34 +0300 Subject: =?UTF-8?Q?Re=3A_Max_open_files____________1024__=D1=83_nginx=3A_master_pro?= =?UTF-8?Q?cess?= In-Reply-To: <1457703895.279397581.prczoxaz@frv35.fwdcdn.com> References: <1457703895.279397581.prczoxaz@frv35.fwdcdn.com> Message-ID: <20160311154734.GI12808@mdounin.ru> Hello! On Fri, Mar 11, 2016 at 03:47:30PM +0200, Vladislav Prodan wrote: > Проблема с лимитом открытых файлов в 1024 > > # ps -auxwww | grep nginx > root      2139  0.0  0.0  31860  2512 ?        Ss   05:42   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > www-data  2140  0.0  0.0  36420  8212 ?        S    05:42   0:00 nginx: worker process [...] > # cat /proc/2139/limits [...] > Max open files            1024                 4096                 files [...] > #cat /etc/security/limits.conf > * soft nofile 16384 > * hard nofile 16384 > > nginx   soft    nofile      10000 > nginx   hard    nofile      30000 Ограничения из limits.conf подбираются только для интерактивных сессий. Для демонов - надо их выставлять в init-скрипте, либо с помощью соответствующей ручки init-системы (e.g., systemd имеет ручку LimitNOFILE), либо непосредственно в приложении. В nginx есть ручка worker_rlimit_nofile для управления ограничением на количество открытых файлов в рабочих процессах, подробнее тут: http://nginx.org/r/worker_rlimit_nofile/ru Если нужно именно в мастере - см. варианты выше. (nginx имеет ручку worker_rlimit_nofile для рабочих процессов, если нужно именно в мастере - см. варианты выше). -- Maxim Dounin http://nginx.org/ From universite на ukr.net Fri Mar 11 17:16:18 2016 From: universite на ukr.net (Vladislav Prodan) Date: Fri, 11 Mar 2016 19:16:18 +0200 Subject: =?UTF-8?Q?Re=5B2=5D=3A_Max_open_files____________1024__=D1=83_nginx=3A_mas?= =?UTF-8?Q?ter_process?= In-Reply-To: <20160311154734.GI12808@mdounin.ru> References: <1457703895.279397581.prczoxaz@frv35.fwdcdn.com> <20160311154734.GI12808@mdounin.ru> Message-ID: <1457716453.680025848.pkg0zcf8@frv35.fwdcdn.com>   --- Original message --- From: "Maxim Dounin" Date: 11 March 2016, 17:47:40 Hello! On Fri, Mar 11, 2016 at 03:47:30PM +0200, Vladislav Prodan wrote: > Проблема с лимитом открытых файлов в 1024 > > # ps -auxwww | grep nginx > root      2139  0.0  0.0  31860  2512 ?        Ss   05:42   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > www-data  2140  0.0  0.0  36420  8212 ?        S    05:42   0:00 nginx: worker process [...] > # cat /proc/2139/limits [...] > Max open files            1024                 4096                 files [...] > #cat /etc/security/limits.conf > * soft nofile 16384 > * hard nofile 16384 > > nginx   soft    nofile      10000 > nginx   hard    nofile      30000 Ограничения из limits.conf подбираются только для интерактивных сессий. Для демонов - надо их выставлять в init-скрипте, либо с помощью соответствующей ручки init-системы (e.g., systemd имеет ручку LimitNOFILE), либо непосредственно в приложении. В nginx есть ручка worker_rlimit_nofile для управления ограничением на количество открытых файлов в рабочих процессах, подробнее тут: http://nginx.org/r/worker_rlimit_nofile/ru Если нужно именно в мастере - см. варианты выше. (nginx имеет ручку worker_rlimit_nofile для рабочих процессов, если нужно именно в мастере - см. варианты выше). -- Maxim Dounin http://nginx.org/ Спасибо за развернутый ответ. Приподнял лимит в systemd для nginx сервиса и сразу ушли ошибки! -- Vladislav V. Prodan System & Network Administrator support.od.ua ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alexandr.porunov на gmail.com Sat Mar 12 08:49:00 2016 From: alexandr.porunov на gmail.com (Alexandr Porunov) Date: Sat, 12 Mar 2016 10:49:00 +0200 Subject: =?UTF-8?B?0JLQvtC30LzQvtC20L3QviDQu9C4INC/0YDQvtCy0LXRgNGP0YLRjCDQv9GA0LA=?= =?UTF-8?B?0LLQsCDQv9C+0LvRjNC30L7QstCw0YLQtdC70Y8g0L/QtdGA0LXQtCDQvtGC?= =?UTF-8?B?0LTQsNGH0LXQuSDRhNC+0YLQvtCz0YDQsNGE0LjQuSDRh9C10YDQtdC3IE5H?= =?UTF-8?B?SU5YPw==?= Message-ID: Здравствуйте, У меня есть хранилище фотографий на подобие S3. Мне нужно перед отдачей фотографии проверять пользовательские права (можно ли ему смотреть фото). Возможно ли настроить NGINX как прокси для проверки прав или можно ли сказать NGINXу чтобы он перед отдачей фотографии спрашивал разрешения у сервера проверки прав? Что-то вроде этого: [image: Inline image 1] С Уважением, Александр ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: ----------- следущая часть ----------- Вложение не в текстовом формате было извлечено… Имя: NGINX_photo_downloading.png Тип: image/png Размер: 66631 байтов Описание: отсутствует URL: From mva на mva.name Sat Mar 12 09:02:32 2016 From: mva на mva.name (Vadim A. Misbakh-Soloviov) Date: Sat, 12 Mar 2016 15:02:32 +0600 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDQv9GA0L7QstC10YDRj9GC0Ywg0L8=?= =?UTF-8?B?0YDQsNCy0LAg0L/QvtC70YzQt9C+0LLQsNGC0LXQu9GPINC/0LXRgNC10LQg?= =?UTF-8?B?0L7RgtC00LDRh9C10Lkg0YTQvtGC0L7Qs9GA0LDRhNC40Lkg0YfQtdGA0LU=?= =?UTF-8?B?0LcgTkdJTlg/?= In-Reply-To: References: Message-ID: <56E3DB28.3040509@mva.name> Не смотря на то, что я считаю "Java Server" лишним звеном и думаю, что это способен решать простейший скрипт, с доступом в базу, тем не менее, то, что вы хотите, в зависимости от интерфейса того JavaServer'а можно решить как "стандартными" средствами, так и "ионными пушками" типа встроенного Perl'а, Lua-модуля и, возможно, даже NJS. 12.03.2016 14:49, Alexandr Porunov пишет: > Здравствуйте, > > У меня есть хранилище фотографий на подобие S3. Мне нужно перед отдачей > фотографии проверять пользовательские права (можно ли ему смотреть фото). > Возможно ли настроить NGINX как прокси для проверки прав или можно ли > сказать NGINXу чтобы он перед отдачей фотографии спрашивал разрешения у > сервера проверки прав? > > Что-то вроде этого: > [image: Inline image 1] > > С Уважением, Александр > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From onokonem на gmail.com Sat Mar 12 09:08:36 2016 From: onokonem на gmail.com (Daniel Podolsky) Date: Sat, 12 Mar 2016 12:08:36 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDQv9GA0L7QstC10YDRj9GC0Ywg0L8=?= =?UTF-8?B?0YDQsNCy0LAg0L/QvtC70YzQt9C+0LLQsNGC0LXQu9GPINC/0LXRgNC10LQg?= =?UTF-8?B?0L7RgtC00LDRh9C10Lkg0YTQvtGC0L7Qs9GA0LDRhNC40Lkg0YfQtdGA0LU=?= =?UTF-8?B?0LcgTkdJTlg/?= In-Reply-To: References: Message-ID: http://kovyrin.net/2006/11/01/nginx-x-accel-redirect-php-rails/lang/ru/ здесь про статику, а не про проксирование на S3-like, правда. а можно совсем просто - java server отдает специальный http status (204, к примеру), если разрешает скачивание, и обработчиком на этот 204 ставится проксирование на ваше S3-like. 2016-03-12 11:49 GMT+03:00 Alexandr Porunov : > Здравствуйте, > > У меня есть хранилище фотографий на подобие S3. Мне нужно перед отдачей > фотографии проверять пользовательские права (можно ли ему смотреть фото). > Возможно ли настроить NGINX как прокси для проверки прав или можно ли > сказать NGINXу чтобы он перед отдачей фотографии спрашивал разрешения у > сервера проверки прав? > > Что-то вроде этого: > > > С Уважением, Александр > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From alexandr.porunov на gmail.com Sat Mar 12 09:08:36 2016 From: alexandr.porunov на gmail.com (Alexandr Porunov) Date: Sat, 12 Mar 2016 11:08:36 +0200 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDQv9GA0L7QstC10YDRj9GC0Ywg0L8=?= =?UTF-8?B?0YDQsNCy0LAg0L/QvtC70YzQt9C+0LLQsNGC0LXQu9GPINC/0LXRgNC10LQg?= =?UTF-8?B?0L7RgtC00LDRh9C10Lkg0YTQvtGC0L7Qs9GA0LDRhNC40Lkg0YfQtdGA0LU=?= =?UTF-8?B?0LcgTkdJTlg/?= In-Reply-To: <56E3DB28.3040509@mva.name> References: <56E3DB28.3040509@mva.name> Message-ID: Здравствуйте Владимир, Я не говорю что я хочу сделать проверку именно таким образом, я просто привел один из примеров. Я новичек и не знаю как правильно сделать проверку прав. Подскажите пожалуйста как лучше это сделать? С Уважением, Александр 2016-03-12 11:02 GMT+02:00 Vadim A. Misbakh-Soloviov : > Не смотря на то, что я считаю "Java Server" лишним звеном и думаю, что > это способен решать простейший скрипт, с доступом в базу, тем не менее, > то, что вы хотите, в зависимости от интерфейса того JavaServer'а можно > решить как "стандартными" средствами, так и "ионными пушками" типа > встроенного Perl'а, Lua-модуля и, возможно, даже NJS. > > 12.03.2016 14:49, Alexandr Porunov пишет: > > Здравствуйте, > > > > У меня есть хранилище фотографий на подобие S3. Мне нужно перед отдачей > > фотографии проверять пользовательские права (можно ли ему смотреть фото). > > Возможно ли настроить NGINX как прокси для проверки прав или можно ли > > сказать NGINXу чтобы он перед отдачей фотографии спрашивал разрешения у > > сервера проверки прав? > > > > Что-то вроде этого: > > [image: Inline image 1] > > > > С Уважением, Александр > > > > > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From wangsamp на gmail.com Sat Mar 12 09:13:06 2016 From: wangsamp на gmail.com (Oleksandr V. Typlyns'kyi) Date: Sat, 12 Mar 2016 11:13:06 +0200 (EET) Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDQv9GA0L7QstC10YDRj9GC0Ywg0L8=?= =?UTF-8?B?0YDQsNCy0LAg0L/QvtC70YzQt9C+0LLQsNGC0LXQu9GPINC/0LXRgNC10LQg?= =?UTF-8?B?0L7RgtC00LDRh9C10Lkg0YTQvtGC0L7Qs9GA0LDRhNC40Lkg0YfQtdGA0LU=?= =?UTF-8?B?0LcgTkdJTlg/?= In-Reply-To: References: <56E3DB28.3040509@mva.name> Message-ID: Today Mar 12, 2016 at 11:08 Alexandr Porunov wrote: > Здравствуйте Владимир, > > Я не говорю что я хочу сделать проверку именно таким образом, я просто > привел один из примеров. Я новичек и не знаю как правильно сделать проверку > прав. Подскажите пожалуйста как лучше это сделать? Выдавать пользователям специальные ссылки: http://nginx.org/r/secure_link/ru Проверять на бекенде каждый запрос: http://nginx.org/r/auth_request/ru -- WNGS-RIPE From alexandr.porunov на gmail.com Sat Mar 12 09:22:41 2016 From: alexandr.porunov на gmail.com (Alexandr Porunov) Date: Sat, 12 Mar 2016 11:22:41 +0200 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDQv9GA0L7QstC10YDRj9GC0Ywg0L8=?= =?UTF-8?B?0YDQsNCy0LAg0L/QvtC70YzQt9C+0LLQsNGC0LXQu9GPINC/0LXRgNC10LQg?= =?UTF-8?B?0L7RgtC00LDRh9C10Lkg0YTQvtGC0L7Qs9GA0LDRhNC40Lkg0YfQtdGA0LU=?= =?UTF-8?B?0LcgTkdJTlg/?= In-Reply-To: References: <56E3DB28.3040509@mva.name> Message-ID: Вау! Вот это классные модули! Огромное Вам спасибо! С Уважением, Александр 2016-03-12 11:13 GMT+02:00 Oleksandr V. Typlyns'kyi : > Today Mar 12, 2016 at 11:08 Alexandr Porunov wrote: > > > Здравствуйте Владимир, > > > > Я не говорю что я хочу сделать проверку именно таким образом, я просто > > привел один из примеров. Я новичек и не знаю как правильно сделать > проверку > > прав. Подскажите пожалуйста как лучше это сделать? > > Выдавать пользователям специальные ссылки: > http://nginx.org/r/secure_link/ru > Проверять на бекенде каждый запрос: http://nginx.org/r/auth_request/ru > -- > WNGS-RIPE > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sat Mar 12 19:25:00 2016 From: nginx-forum на forum.nginx.org (latro) Date: Sat, 12 Mar 2016 14:25:00 -0500 Subject: =?UTF-8?B?bmdpbnggcHJveHkg0L3QtSDRgdGC0LDQvdC00LDRgNGC0L3QsNGPINC30LDQtNCw?= =?UTF-8?B?0YfQsA==?= Message-ID: Приветствую, постараюсь изложить задачу поподробнее Есть ротатор ссылок на стороннем сайте. Это php скрипт, при его выполнении он каждый раз выдает текст: адрес в виде http://url1.com При следующем выполнении url2.com и т.д. На моем сайте необходимо проксировать запросы по адресу который выдает этот скрипт. То есть, должно получаться так: посетитель1 моего сайта получает содержимое url1.com, посетитель2 соответственно url2.com и т.д. Алгоритм в вкратце такой: Посетитель заходит на сайт -> в этот момент мой сервер обращается к скрипту на стороннем сервере -> получает адрес и проксирует содержимое с этого сайта посетителю. Причем мой сайт на https, а url1, url2 без. Можно ли как то это реализовать с помощью nginx? Спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265276,265276#msg-265276 From nginx-forum на forum.nginx.org Sun Mar 13 01:02:53 2016 From: nginx-forum на forum.nginx.org (svd) Date: Sat, 12 Mar 2016 20:02:53 -0500 Subject: =?UTF-8?B?0L/QvtGB0LvQtSDQsNC/0LTQtdC50YLQsCDRgSAxLjEuMTkg0L3QsCAxLjguMSAg?= =?UTF-8?B?0YPQstC10LvQuNGH0LXQu9GB0Y8g0YLRgNCw0YTQuNC6INC+0YLQtNCw0Yc=?= =?UTF-8?B?0Lg=?= Message-ID: <1a3b8f87ce2f5f76eb1036fa47dd99ed.NginxMailingListRussian@forum.nginx.org> Добрый день. Вот решили обновиться и заметили такую историю. В конфигах настроено для php-fpm + сжатие. До этого трафик был 10 мегабит поровну и in и out. Теперь out 16-18. что могло повлиять на это. может быть какие то директивы конфигов устаревшие? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265278,265278#msg-265278 From nginx-forum на forum.nginx.org Sun Mar 13 05:24:14 2016 From: nginx-forum на forum.nginx.org (Vasiliy P. Melnik) Date: Sun, 13 Mar 2016 00:24:14 -0500 Subject: =?UTF-8?Q?Re=3A_Re=5B2=5D=3A_Max_open_files____________1024__=D1=83_nginx?= =?UTF-8?Q?=3A_master_process?= In-Reply-To: <1457716453.680025848.pkg0zcf8@frv35.fwdcdn.com> References: <1457716453.680025848.pkg0zcf8@frv35.fwdcdn.com> Message-ID: <093eb1a72529cd9b728a67995a76e972.NginxMailingListRussian@forum.nginx.org> > Спасибо за развернутый ответ. > Приподнял лимит в systemd для nginx сервиса и сразу ушли ошибки! не всегда получается - например потстгрес создает воркеров на каждый коннекшин, даже если поднимешь лимит на мастер процесс - все воркеры будут все равно с лимитом дефолтным. Пока не поменяешь в конфиге постгреса - толку не будет. Поэтому если есть возможность задать в конфиге демона - лучше задать в конфиге демона, чем ковырять в системе Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265249,265280#msg-265280 From universite на ukr.net Sun Mar 13 12:33:42 2016 From: universite на ukr.net (Vladislav Prodan) Date: Sun, 13 Mar 2016 14:33:42 +0200 Subject: =?UTF-8?Q?Re=5B2=5D=3A_Re=5B2=5D=3A_Max_open_files____________1024__=D1=83?= =?UTF-8?Q?_nginx=3A_master_process?= In-Reply-To: <093eb1a72529cd9b728a67995a76e972.NginxMailingListRussian@forum.nginx.org> References: <1457716453.680025848.pkg0zcf8@frv35.fwdcdn.com> <093eb1a72529cd9b728a67995a76e972.NginxMailingListRussian@forum.nginx.org> Message-ID: <1457872254.790624226.tl3y5xkg@frv35.fwdcdn.com>   --- Original message --- From: "Vasiliy P. Melnik" Date: 13 March 2016, 07:24:20 > Спасибо за развернутый ответ. > Приподнял лимит в systemd для nginx сервиса и сразу ушли ошибки! не всегда получается - например потстгрес создает воркеров на каждый коннекшин, даже если поднимешь лимит на мастер процесс - все воркеры будут все равно с лимитом дефолтным. Пока не поменяешь в конфиге постгреса - толку не будет. Я уже ковырял настройки nginx.conf. И не понял логики, почему при 4-х воркерах все работает, а при 8-ми - нет. А заниматься научными исследованиями при плачущем клиенте, что у него сайты не работают - нет возможности.  Поэтому если есть возможность задать в конфиге демона - лучше задать в конфиге демона, чем ковырять в системе -- Vladislav V. Prodan System & Network Administrator support.od.ua ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sun Mar 13 12:40:38 2016 From: nginx-forum на forum.nginx.org (dim1) Date: Sun, 13 Mar 2016 08:40:38 -0400 Subject: =?UTF-8?B?bmdpbngg0LLRgdC1INCy0L7RgNC60LXRgNGLINC90LAgMSDRj9C00YDQvj8=?= Message-ID: <63a9ba4584ce217e7b93a63023c0aa00.NginxMailingListRussian@forum.nginx.org> Debian GNU/Linux 7 Linux version 2.6.32-5-amd64 (Debian 2.6.32-48squeeze6) посмотрел atop CPU | sys 6% | user 10% | irq 19% | idle 763% | wait 1% | avgf 1.61GHz | avgscal 47% | cpu | sys 5% | user 8% | irq 20% | idle 67% | cpu000 w 1% | avgf 1.61GHz | avgscal 47% | cpu | sys 1% | user 1% | irq 0% | idle 98% | cpu004 w 0% | avgf 1.60GHz | avgscal 47% | cpu | sys 0% | user 0% | irq 0% | idle 100% | cpu006 w 0% | avgf 1.62GHz | avgscal 47% | cpu | sys 0% | user 0% | irq 0% | idle 100% | cpu003 w 0% | avgf 1.60GHz | avgscal 47% | .... 27891 www www 1 13.70s 12.56s 0K 4K 0K 50736K -- - S 0 4% nginx 27889 www www 1 13.70s 12.56s 0K 0K 0K 51268K -- - S 0 4% nginx 27890 www www 1 13.61s 12.18s 0K 16K 28K 50152K -- - S 0 4% nginx 27888 www www 1 13.20s 12.54s 0K 12K 0K 49892K -- - S 0 4% nginx Везде стоит CPUNR=0 Т.е., если не ошибаюсь, судя по этим данным - все 4 воркера nginx работает на 1 ядре процессора из 4x2?! Поставил 8 воркеров и в nginx добавил worker_cpu_afffinity: CPU | sys 4% | user 6% | irq 9% | idle 779% | wait 2% | avgf 1.61GHz | avgscal 47% | cpu | sys 1% | user 2% | irq 9% | idle 87% | cpu000 w 2% | avgf 1.62GHz | avgscal 47% | cpu | sys 1% | user 2% | irq 0% | idle 97% | cpu004 w 0% | avgf 1.60GHz | avgscal 47% | cpu | sys 0% | user 1% | irq 0% | idle 99% | cpu006 w 0% | avgf 1.61GHz | avgscal 47% | cpu | sys 1% | user 1% | irq 0% | idle 99% | cpu005 w 0% | avgf 1.61GHz | avgscal 47% | ... 9066 www www 1 7.68s 9.40s 0K 4K 1068K 31460K -- - R 4 3% nginx 9062 www www 1 4.70s 4.59s 0K 0K 420K 16760K -- - S 0 2% nginx 9063 www www 1 2.20s 2.31s 0K 0K 244K 7356K -- - S 1 1% nginx 9069 www www 1 1.86s 1.63s 0K 8K 96K 5620K -- - S 6 1% nginx 9065 www www 1 1.68s 1.68s 0K 8K 192K 5216K -- - S 3 1% nginx 9064 www www 1 1.17s 1.36s 0K 16K 148K 4016K -- - S 2 0% nginx 9067 www www 1 1.15s 1.16s 0K 0K 212K 3756K -- - S 5 0% nginx 9070 www www 1 0.98s 1.04s 0K 0K 24K 3272K -- - S 7 0% nginx Картинка лучше, но явно не равномерно. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265285,265285#msg-265285 From nginx-forum на forum.nginx.org Sun Mar 13 12:58:37 2016 From: nginx-forum на forum.nginx.org (dim1) Date: Sun, 13 Mar 2016 08:58:37 -0400 Subject: =?UTF-8?B?bmdpbngg0LfQsNCy0LjRgdCw0LXRgiDQv9GA0Lgg0LfQsNC/0LjRgdC4INC70L4=?= =?UTF-8?B?0LPQvtCyPw==?= Message-ID: <26a382eafb9021cc1b4d3c567d5ca8ab.NginxMailingListRussian@forum.nginx.org> nginx 1.8.0 Debian GNU/Linux 7 Linux version 2.6.32-5-amd64 (Debian 2.6.32-48squeeze6) При нагрузке подвисает nginx. Протестировал: при более менее активных дисковых операциях, начинает подвисать nginx. Мне кажется, что ворекр (процесс nginx) блокируется при записи лога. Верно? Операций ЧТЕНИЯ - практически НЕТ, контент закешировала ОС в памяти. Логи достигают до 10-15 Гбайт в сутки (отключить не могу, но могу уменьшить на 30%). Вот так выглядит лог проверки доступности сайта (числа - миллисекунды), если запустить на сервере копирование 10ГБ файла: [time] All time: Dns Connect Send Wait Receive [2016-03-13 03:09:18] 179: 0 0 44 45 89 [2016-03-13 03:09:20] 189: 0 0 47 44 96 [2016-03-13 03:09:34] 7252: 0 0 43 7007 200 <--- [2016-03-13 03:09:37] 1970: 0 0 46 1831 91 0 <--- [2016-03-13 03:09:41] 179: 0 0 44 44 89 [2016-03-13 03:09:51] 7770: 0 0 44 7007 718 0 <--- [2016-03-13 03:09:54] 180: 0 0 45 44 89 [2016-03-13 03:09:56] 165: 0 0 41 41 81 (таймаут ожидания 7 сек) Тоже копирование, но с ionice -c3 [2016-03-13 03:38:03] 178: 0 0 44 44 88 [2016-03-13 03:38:05] 178: 0 0 44 44 89 [2016-03-13 03:38:15] 4199: 0 0 44 4065 89 0 <--- [2016-03-13 03:38:17] 178: 0 0 44 44 88 [2016-03-13 03:38:20] 177: 0 0 44 44 88 [2016-03-13 03:38:25] 1437: 0 0 40 1315 81 [2016-03-13 03:38:28] 162: 0 0 40 40 81 Я так понимаю, задержки когда каждый процесс nginx пытается записать лог. Реально так? Могут ли быть зависания, из-за того все воркеры пытаются писать лог на диск? Как побороть (не меняя железо)? Логи пишутся по 64Кб: access_log ... buffer=64k; error_log без указания buffer Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265286,265286#msg-265286 From basil на vpm.net.ua Sun Mar 13 13:06:53 2016 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Sun, 13 Mar 2016 15:06:53 +0200 Subject: =?UTF-8?Q?Re=3A_Re=5B2=5D=3A_Re=5B2=5D=3A_Max_open_files_1024_=D1=83_nginx?= =?UTF-8?Q?=3A_master_process?= In-Reply-To: <1457872254.790624226.tl3y5xkg@frv35.fwdcdn.com> References: <1457716453.680025848.pkg0zcf8@frv35.fwdcdn.com> <093eb1a72529cd9b728a67995a76e972.NginxMailingListRussian@forum.nginx.org> <1457872254.790624226.tl3y5xkg@frv35.fwdcdn.com> Message-ID: > > Я уже ковырял настройки nginx.conf. > И не понял логики, почему при 4-х воркерах все работает, а при 8-ми - нет. > Просто больше очередь - видать сервер нагружен, поэтому и полезло. > А заниматься научными исследованиями при плачущем клиенте, что у него > сайты не работают - нет возможности. > Это понятно - исследования надо заниматься на тестовой машине. Я ж пишу - с постгресом упирался, но ситуация в том, что постгрес пересоздает процессы и в процессе их создания тупо забивает на улимит в системе для юзера постгрес. Пока не поправил конфиг - толку никакого не было. З.Ы. пока разбирался - тоже скриптом менял улимит, тупо проходил все процессы постгреса раз в минуту и менял значение. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sun Mar 13 18:29:45 2016 From: nginx-forum на forum.nginx.org (dim1) Date: Sun, 13 Mar 2016 14:29:45 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIg0L/RgNC4INC30LDQv9C40YHQuCA=?= =?UTF-8?B?0LvQvtCz0L7Qsj8=?= In-Reply-To: <26a382eafb9021cc1b4d3c567d5ca8ab.NginxMailingListRussian@forum.nginx.org> References: <26a382eafb9021cc1b4d3c567d5ca8ab.NginxMailingListRussian@forum.nginx.org> Message-ID: Блокирование диска идет из-за программного рейда (процесс flush-9:2) Какой ionice при копировании не ставь, все равно синхронизация тормозит :( Как решить? Что будет, если попробовать поставить высокий ionice -c1 (real time) для процессов nginx? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265286,265290#msg-265290 From nginx-forum на forum.nginx.org Sun Mar 13 20:52:10 2016 From: nginx-forum на forum.nginx.org (Vasiliy P. Melnik) Date: Sun, 13 Mar 2016 16:52:10 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIg0L/RgNC4INC30LDQv9C40YHQuCA=?= =?UTF-8?B?0LvQvtCz0L7Qsj8=?= In-Reply-To: References: <26a382eafb9021cc1b4d3c567d5ca8ab.NginxMailingListRussian@forum.nginx.org> Message-ID: <73123357e2257454c0ff6c1327a7f226.NginxMailingListRussian@forum.nginx.org> ну значит надо переходить на ссд, или логи отправить в сислог по сетке на другую машину, или логи перекинуть на ссд диск, а если не справляется - складывать в оперативку. З.Ы. что-то я не замечал, чтобы flush уж так сильно много брал. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265286,265291#msg-265291 From simplebox66 на gmail.com Mon Mar 14 06:34:35 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 14 Mar 2016 09:34:35 +0300 Subject: =?UTF-8?Q?nginx_=D0=B8_lua?= Message-ID: Всем привет. Появилось желание заменить некоторые свои конструкции конфига, на что-то сделанное на lua, но с удивлением обнаружил что nginx не поддерживает lua из коробки, так и есть? или я ошибаюсь? Видимо придется ждать поддержку динамических модулей в stable версии, потому что собирать и поддерживать кастомный nginx не хотелось бы ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sytar.alex на gmail.com Mon Mar 14 06:38:40 2016 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Mon, 14 Mar 2016 09:38:40 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIg0L/RgNC4INC30LDQv9C40YHQuCA=?= =?UTF-8?B?0LvQvtCz0L7Qsj8=?= In-Reply-To: References: <26a382eafb9021cc1b4d3c567d5ca8ab.NginxMailingListRussian@forum.nginx.org> Message-ID: 13 марта 2016 г., 21:29 пользователь dim1 написал: > Блокирование диска идет из-за программного рейда (процесс flush-9:2) > Какой ionice при копировании не ставь, все равно синхронизация тормозит :( > Если тупит flush - значит у вас медленный накопитель. Попробуйте его заменить на более быстрый. Еще как вариант у вас перекручены параметры /proc/sys/vm/dirty_* > > Как решить? > Что будет, если попробовать поставить высокий ionice -c1 (real time) для > процессов nginx? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,265286,265290#msg-265290 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From me на kemko.ru Mon Mar 14 08:26:51 2016 From: me на kemko.ru (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JDQvdC00YDQtdC10LI=?=) Date: Mon, 14 Mar 2016 08:26:51 +0000 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIg0L/RgNC4INC30LDQv9C40YHQuCA=?= =?UTF-8?B?0LvQvtCz0L7Qsj8=?= In-Reply-To: <26a382eafb9021cc1b4d3c567d5ca8ab.NginxMailingListRussian@forum.nginx.org> References: <26a382eafb9021cc1b4d3c567d5ca8ab.NginxMailingListRussian@forum.nginx.org> Message-ID: вс, 13 мар. 2016 г. в 15:58, dim1 : > Логи пишутся по 64Кб: access_log ... buffer=64k; > Включение gzip-сжатия ситуацию не выправляет? http://nginx.org/ru/docs/http/ngx_http_log_module.html ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From basil на vpm.net.ua Mon Mar 14 09:58:18 2016 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Mon, 14 Mar 2016 11:58:18 +0200 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIg0L/RgNC4INC30LDQv9C40YHQuCA=?= =?UTF-8?B?0LvQvtCz0L7Qsj8=?= In-Reply-To: References: <26a382eafb9021cc1b4d3c567d5ca8ab.NginxMailingListRussian@forum.nginx.org> Message-ID: та там копейки - 15 гигов в день это 10 мегабайт в минуту 14 марта 2016 г., 10:26 пользователь Дмитрий Андреев написал: > вс, 13 мар. 2016 г. в 15:58, dim1 : > >> Логи пишутся по 64Кб: access_log ... buffer=64k; >> > Включение gzip-сжатия ситуацию не выправляет? > http://nginx.org/ru/docs/http/ngx_http_log_module.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon Mar 14 11:04:27 2016 From: nginx-forum на forum.nginx.org (dim1) Date: Mon, 14 Mar 2016 07:04:27 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIg0L/RgNC4INC30LDQv9C40YHQuCA=?= =?UTF-8?B?0LvQvtCz0L7Qsj8=?= In-Reply-To: References: Message-ID: $ sysctl -a | grep dirty vm.dirty_background_ratio = 10 vm.dirty_background_bytes = 0 vm.dirty_ratio = 20 vm.dirty_bytes = 0 vm.dirty_writeback_centisecs = 500 vm.dirty_expire_centisecs = 3000 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265286,265303#msg-265303 From vbart на nginx.com Mon Mar 14 12:58:45 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 14 Mar 2016 15:58:45 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIg0L/RgNC4INC30LDQv9C40YHQuCA=?= =?UTF-8?B?0LvQvtCz0L7Qsj8=?= In-Reply-To: References: <26a382eafb9021cc1b4d3c567d5ca8ab.NginxMailingListRussian@forum.nginx.org> Message-ID: <2285351.p61oGoGLS4@vbart-workstation> On Sunday 13 March 2016 14:29:45 dim1 wrote: > Блокирование диска идет из-за программного рейда (процесс flush-9:2) > Какой ionice при копировании не ставь, все равно синхронизация тормозит :( > > Как решить? > Что будет, если попробовать поставить высокий ionice -c1 (real time) для > процессов nginx? [..] Знаменитый bug #12309: https://bugzilla.kernel.org/show_bug.cgi?id=12309 Вероятно стоит попробовать использовать что-то более свежее, чем антиквариат 2.6.32, и если не поможет, то попытается избежать "копирования 10ГБ файла" во время работы сервера, либо смириться с возрастающими от этого задержками. Да и с чего вы решили, что задержки возникают из-за блокировки на записи логов? Если я правильно понял, то это только предположение. Проверить его можно было бы довольно просто - отключив логи. -- Валентин Бартенев From stalker на altlinux.ru Mon Mar 14 13:01:10 2016 From: stalker на altlinux.ru (Anton Gorlov) Date: Mon, 14 Mar 2016 16:01:10 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIg0L/RgNC4INC30LDQv9C40YHQuCA=?= =?UTF-8?B?0LvQvtCz0L7Qsj8=?= In-Reply-To: <2285351.p61oGoGLS4@vbart-workstation> References: <26a382eafb9021cc1b4d3c567d5ca8ab.NginxMailingListRussian@forum.nginx.org> <2285351.p61oGoGLS4@vbart-workstation> Message-ID: <56E6B616.9080802@altlinux.ru> Он кстати и на новых ядрах живой. У себя его ловлю в том числе на десктопе с 4.1.19-un-def-alt0.M70P.1 #1 SMP PREEMPT Wed Mar 9 11:02:42 UTC 2016 x86_64 GNU/Linux 14.03.2016 15:58, Валентин Бартенев пишет: > Знаменитый bug #12309: https://bugzilla.kernel.org/show_bug.cgi?id=12309 From vbart на nginx.com Mon Mar 14 13:15:27 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 14 Mar 2016 16:15:27 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIg0L/RgNC4INC30LDQv9C40YHQuCA=?= =?UTF-8?B?0LvQvtCz0L7Qsj8=?= In-Reply-To: <56E6B616.9080802@altlinux.ru> References: <26a382eafb9021cc1b4d3c567d5ca8ab.NginxMailingListRussian@forum.nginx.org> <2285351.p61oGoGLS4@vbart-workstation> <56E6B616.9080802@altlinux.ru> Message-ID: <3340018.ubzMuKY01x@vbart-workstation> On Monday 14 March 2016 16:01:10 Anton Gorlov wrote: > Он кстати и на новых ядрах живой. > У себя его ловлю в том числе на десктопе с > 4.1.19-un-def-alt0.M70P.1 #1 SMP PREEMPT Wed Mar 9 11:02:42 UTC 2016 > x86_64 GNU/Linux [..] Согласен, система как вставала вся колом при интенсивном обращении к диску, так и встает, в том числе на последних 4.x ядрах. -- Валентин Бартенев From mdounin на mdounin.ru Mon Mar 14 13:22:24 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 14 Mar 2016 16:22:24 +0300 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_lua?= In-Reply-To: References: Message-ID: <20160314132224.GM12808@mdounin.ru> Hello! On Mon, Mar 14, 2016 at 09:34:35AM +0300, Иван Мишин wrote: > Всем привет. > Появилось желание заменить некоторые свои конструкции конфига, на что-то > сделанное на lua, но с удивлением обнаружил что nginx не поддерживает lua > из коробки, так и есть? или я ошибаюсь? Lua - сторонний модуль. И я бы не рекомендовал использовать его без нужды, качество кода там - сомнительное. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Mon Mar 14 15:31:57 2016 From: nginx-forum на forum.nginx.org (dim1) Date: Mon, 14 Mar 2016 11:31:57 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIg0L/RgNC4INC30LDQv9C40YHQuCA=?= =?UTF-8?B?0LvQvtCz0L7Qsj8=?= In-Reply-To: <2285351.p61oGoGLS4@vbart-workstation> References: <2285351.p61oGoGLS4@vbart-workstation> Message-ID: <4e79adf8df0fa3e1867388b673aaae2e.NginxMailingListRussian@forum.nginx.org> Вы правы, отключил логи - тоже зависания nginx. Хотя все в кэше ОС, судя по iotop nginx что-то читает: 451 be/4 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [md2_raid1] 473 be/3 root 0.00 B/s 0.00 B/s 0.00 % 90.73 % [jbd2/md2-8] 23894 be/4 root 0.00 B/s 90.79 M/s 0.00 % 87.72 % dd if=/dev/zero of=/5gbfile bs=1M count=14000 23545 be/1 www 121.65 K/s 0.00 B/s 0.00 % 30.34 % nginx: worker process Можно как-то побороть без смены железа и ОС? Или весь контент скопировать в Tmpfs? Или другое? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265286,265314#msg-265314 From basil на vpm.net.ua Mon Mar 14 15:43:17 2016 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Mon, 14 Mar 2016 17:43:17 +0200 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIg0L/RgNC4INC30LDQv9C40YHQuCA=?= =?UTF-8?B?0LvQvtCz0L7Qsj8=?= In-Reply-To: <4e79adf8df0fa3e1867388b673aaae2e.NginxMailingListRussian@forum.nginx.org> References: <2285351.p61oGoGLS4@vbart-workstation> <4e79adf8df0fa3e1867388b673aaae2e.NginxMailingListRussian@forum.nginx.org> Message-ID: Вчера тестировал - для меня было откровение, оказывается raid1 читает только с одного первого диска, а если поставить на raid10 из тех же двух дисков, то будет все совсем иначе. mdadm --detail /dev/md2 /dev/md2: Version : 1.2 Creation Time : Sat Aug 29 01:38:00 2015 Raid Level : raid1 Array Size : 244066304 (232.76 GiB 249.92 GB) Used Dev Size : 244066304 (232.76 GiB 249.92 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Sun Mar 13 21:35:37 2016 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Name : domik11:2 UUID : 14c7dc6c:6af0d5a8:99dba98c:ea37eabe Events : 574 Number Major Minor RaidDevice State 0 8 49 0 active sync /dev/sdd1 1 8 33 1 active sync /dev/sdc1 dd if=/dev/zero of=/var/lib/postgresql/dump bs=30G count=1 oflag=direct 0+1 записей получено 0+1 записей отправлено скопировано 2147479552 байта (2,1 GB), 5,59151 c, 384 MB/c echo 1 > /proc/sys/vm/drop_caches echo 2 > /proc/sys/vm/drop_caches echo 3 > /proc/sys/vm/drop_caches dd if=/var/lib/postgresql/dump of=/dev/null 4194296+0 записей получено 4194296+0 записей отправлено скопировано 2147479552 байта (2,1 GB), 5,45732 c, 394 MB/c mdadm --create /dev/md2 -n2 -l10 -pf2 /dev/sdc1 /dev/sdd1 mdadm --detail /dev/md2 /dev/md2: Version : 1.2 Creation Time : Sun Mar 13 22:16:10 2016 Raid Level : raid10 Array Size : 244066304 (232.76 GiB 249.92 GB) Used Dev Size : 244066304 (232.76 GiB 249.92 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Sun Mar 13 22:38:09 2016 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Layout : far=2 Chunk Size : 512K Name : domik11:2 (local to host domik11) UUID : aeda6a24:3a98f74b:71d89706:59dfb50e Events : 236 Number Major Minor RaidDevice State 0 8 33 0 active sync /dev/sdc1 1 8 49 1 active sync /dev/sdd1 dd if=/dev/zero of=/var/lib/postgresql/dump bs=30G count=1 oflag=direct 0+1 записей получено 0+1 записей отправлено скопировано 2147479552 байта (2,1 GB), 5,52203 c, 389 MB/c echo 1 > /proc/sys/vm/drop_caches echo 2 > /proc/sys/vm/drop_caches echo 3 > /proc/sys/vm/drop_caches dd if=/var/lib/postgresql/dump of=/dev/null 4194296+0 записей получено 4194296+0 записей отправлено скопировано 2147479552 байта (2,1 GB), 2,10984 c, 1,0 GB/c 14 марта 2016 г., 17:31 пользователь dim1 написал: > Вы правы, отключил логи - тоже зависания nginx. > > Хотя все в кэше ОС, > судя по iotop nginx что-то читает: > 451 be/4 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [md2_raid1] > 473 be/3 root 0.00 B/s 0.00 B/s 0.00 % 90.73 % [jbd2/md2-8] > 23894 be/4 root 0.00 B/s 90.79 M/s 0.00 % 87.72 % dd if=/dev/zero > of=/5gbfile bs=1M count=14000 > 23545 be/1 www 121.65 K/s 0.00 B/s 0.00 % 30.34 % nginx: worker > process > > > Можно как-то побороть без смены железа и ОС? > Или весь контент скопировать в Tmpfs? > Или другое? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,265286,265314#msg-265314 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon Mar 14 15:50:40 2016 From: nginx-forum на forum.nginx.org (dim1) Date: Mon, 14 Mar 2016 11:50:40 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIg0L/RgNC4INC30LDQv9C40YHQuCA=?= =?UTF-8?B?0LvQvtCz0L7Qsj8gYXRvcCAtINC90LDQs9GA0YPQt9C60LAg0L3QsCDQtNC4?= =?UTF-8?B?0YHQutC4?= In-Reply-To: <4e79adf8df0fa3e1867388b673aaae2e.NginxMailingListRussian@forum.nginx.org> References: <2285351.p61oGoGLS4@vbart-workstation> <4e79adf8df0fa3e1867388b673aaae2e.NginxMailingListRussian@forum.nginx.org> Message-ID: <657286108971f9611db2acb951953bc9.NginxMailingListRussian@forum.nginx.org> Вот так выглядит atop в период максимальной нагрузки: PID RDDSK WRDSK WCANCL DSK CMD 1473 12K 78184K 0K 18% flush-9:2 28907 80K 66728K 0K 16% nginx 28908 44K 66572K 0K 16% nginx 28905 140K 65696K 0K 16% nginx 28906 236K 65560K 0K 16% nginx 473 0K 51396K 0K 12% jbd2/md2-8 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265286,265316#msg-265316 From gmm на csdoc.com Mon Mar 14 16:46:31 2016 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 14 Mar 2016 18:46:31 +0200 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIg0L/RgNC4INC30LDQv9C40YHQuCA=?= =?UTF-8?B?0LvQvtCz0L7Qsj8gYXRvcCAtINC90LDQs9GA0YPQt9C60LAg0L3QsCDQtNC4?= =?UTF-8?B?0YHQutC4?= In-Reply-To: <657286108971f9611db2acb951953bc9.NginxMailingListRussian@forum.nginx.org> References: <2285351.p61oGoGLS4@vbart-workstation> <4e79adf8df0fa3e1867388b673aaae2e.NginxMailingListRussian@forum.nginx.org> <657286108971f9611db2acb951953bc9.NginxMailingListRussian@forum.nginx.org> Message-ID: <56E6EAE7.8060309@csdoc.com> On 14.03.2016 17:50, dim1 wrote: > Вот так выглядит atop в период максимальной нагрузки: > > PID RDDSK WRDSK > WCANCL DSK CMD > 1473 12K 78184K > 0K 18% flush-9:2 > 28907 80K 66728K > 0K 16% nginx > 28908 44K 66572K > 0K 16% nginx > 28905 140K 65696K > 0K 16% nginx > 28906 236K 65560K > 0K 16% nginx > 473 0K 51396K > 0K 12% jbd2/md2-8 > # If you want nginx to don't touch disk, use proxy_max_temp_file_size 0; # This will still allow in-memory buffering and wouldn't touch disk. или fastcgi_max_temp_file_size 0; если эти 10-гигабайтные файлы приходят по протоколу fastcgi. если это все на одной машине, тогда лучше использовать X-Accel-Redirect https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/ -- Best regards, Gena From karamba66 на ukr.net Mon Mar 14 19:12:31 2016 From: karamba66 на ukr.net (ZZZ) Date: Mon, 14 Mar 2016 20:12:31 +0100 Subject: =?UTF-8?B?cHJveHlfKl90aW1lb3V0INC80LXQvdGM0YjQtSDRgdC10LrRg9C90LTRiw==?= Message-ID: <56E70D1F.1090501@ukr.net> Привет всем. Возможно ли установить proxy_read_timeout, proxy_send_timeout, proxy_connect_timeout меньше секунды ? From ek на nginx.com Mon Mar 14 19:23:45 2016 From: ek на nginx.com (Ekaterina Kukushkina) Date: Mon, 14 Mar 2016 22:23:45 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5XypfdGltZW91dCDQvNC10L3RjNGI0LUg0YHQtdC60YPQvdC00Ys=?= In-Reply-To: <56E70D1F.1090501@ukr.net> References: <56E70D1F.1090501@ukr.net> Message-ID: Привет. Да, конечно. http://nginx.org/ru/docs/syntax.html > On 14 Mar 2016, at 22:12, ZZZ wrote: > > Привет всем. > > Возможно ли установить proxy_read_timeout, proxy_send_timeout, proxy_connect_timeout меньше секунды ? -- Ekaterina Kukushkina Support Engineer | NGINX, Inc. From mva на mva.name Mon Mar 14 19:37:01 2016 From: mva на mva.name (Vadim A. Misbakh-Soloviov) Date: Tue, 15 Mar 2016 01:37:01 +0600 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_lua?= In-Reply-To: <20160314132224.GM12808@mdounin.ru> References: <20160314132224.GM12808@mdounin.ru> Message-ID: <56E712DD.3050704@mva.name> > Lua - сторонний модуль. И я бы не рекомендовал использовать его > без нужды, качество кода там - сомнительное. Ну, какой есть. Если бы был Lua-модуль от команды NgX — я бы был в первых рядах, что называется, "писающих кипятком от счастья". Но, увы, от команды NgX есть только NJS (и тот не в стандартной коробке, и, к тому же, не смотрел как он там с поддержкой сборки в качестве стороннего модуля). А Lua есть только от Yichun'а Zhang'а, увы ☹… // с другой стороны, я, конечно, не перелопачивал *весь* код ngx-lua, но в тех местах, где я контрибьютил — код вполне нормальный, на мой админский (не программерский) взгляд ☺ From nginx-forum на forum.nginx.org Tue Mar 15 05:32:04 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 15 Mar 2016 01:32:04 -0400 Subject: Acept systemd.socket Message-ID: <98012a8d098732accacf8292330ed590.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Есть в планах на ближайшие будущие, реализация принятия сокета от unit systemd.socket? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265330,265330#msg-265330 From nginx-ru на sadok.spb.ru Tue Mar 15 07:12:29 2016 From: nginx-ru на sadok.spb.ru (Dmitry Ivanov) Date: Tue, 15 Mar 2016 10:12:29 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5XypfdGltZW91dCDQvNC10L3RjNGI0LUg0YHQtdC60YPQvdC00Ys=?= In-Reply-To: References: <56E70D1F.1090501@ukr.net> Message-ID: <61881541.20160315101229@sadok.spb.ru> Здравствуйте, Ekaterina. Вы писали 14 марта 2016 г., 22:23:45: > Да, конечно. > http://nginx.org/ru/docs/syntax.html Некоторые интервалы времени можно задать лишь с точностью до секунд. -- С уважением, Dmitry nginx-ru на sadok.spb.ru From nginx-forum на forum.nginx.org Tue Mar 15 09:11:19 2016 From: nginx-forum на forum.nginx.org (woart) Date: Tue, 15 Mar 2016 05:11:19 -0400 Subject: =?UTF-8?B?bmdpbnggZnJvbnRlbmQgcHJveHkgcGFzcyDQuCBpcC3QsNC00YDQtdGBINCx0Y0=?= =?UTF-8?B?0LrQtdC90LTQsA==?= Message-ID: в гугле ответа не нашел, поэтому задаю вопрос здесь. есть nginx backend + php-fpm и есть nginx frontend где стоит proxy_cache для кеширования статики и выходных html сгенерированных php-fpm frontend соответственно по запросу ходит через proxy_pass http://backend за контентом, если контента нет в proxy_cache dir вопрос в следующем: как-нибудь со стороны можно ли "увидеть" ip-адрес этого самого бэкенда? всякие wget -d -v example.com показывают что нигде ip-адрес бэкенда не светится, но тем не менее есть подозрение, что где-то проскакивает айпишник бэкенда при запросах на фроненд. сам бэкенд отвечает на http-запросы на нестандартном порту и при обращении по ip выдает всегда 404 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265335,265335#msg-265335 From denis на webmaster.spb.ru Tue Mar 15 13:28:46 2016 From: denis на webmaster.spb.ru (denis) Date: Tue, 15 Mar 2016 16:28:46 +0300 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_lua?= In-Reply-To: <56E712DD.3050704@mva.name> References: <20160314132224.GM12808@mdounin.ru> <56E712DD.3050704@mva.name> Message-ID: <56E80E0E.7080402@webmaster.spb.ru> 14.03.2016 22:37, Vadim A. Misbakh-Soloviov пишет: >> Lua - сторонний модуль. И я бы не рекомендовал использовать его >> без нужды, качество кода там - сомнительное. > Ну, какой есть. Если бы был Lua-модуль от команды NgX — я бы был в > первых рядах, что называется, "писающих кипятком от счастья". Но, увы, > от команды NgX есть только NJS (и тот не в стандартной коробке, и, к > тому же, не смотрел как он там с поддержкой сборки в качестве стороннего > модуля). А Lua есть только от Yichun'а Zhang'а, увы ☹… > > // с другой стороны, я, конечно, не перелопачивал *весь* код ngx-lua, но > в тех местах, где я контрибьютил — код вполне нормальный, на мой > админский (не программерский) взгляд ☺ "жрите кактус, то есть перл" :) Вероятно, тут как и с модульностью, лет через 5-10 таки запилят свою реализацию, и где не надо будет 3 страницы кода для обработки одной POST-переменной, как сейчас с перлом... За всё это время могли бы уже привести "сомнительный" код к нормальному виду и перестать мучать народ перлом :) From thresh на nginx.com Tue Mar 15 13:33:15 2016 From: thresh на nginx.com (Konstantin Pavlov) Date: Tue, 15 Mar 2016 16:33:15 +0300 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_lua?= In-Reply-To: <56E712DD.3050704@mva.name> References: <20160314132224.GM12808@mdounin.ru> <56E712DD.3050704@mva.name> Message-ID: <56E80F1B.7030104@nginx.com> On 14/03/2016 22:37, Vadim A. Misbakh-Soloviov wrote: > Ну, какой есть. Если бы был Lua-модуль от команды NgX — я бы был в > первых рядах, что называется, "писающих кипятком от счастья". Но, увы, > от команды NgX есть только NJS (и тот не в стандартной коробке, и, к > тому же, не смотрел как он там с поддержкой сборки в качестве стороннего > модуля). С релизом 1.9.13 в репозитории пакетов для mainline njs будет в виде динамического модуля для всех поддерживаемых платформ (http://nginx.org/en/linux_packages.html). -- Konstantin Pavlov From mdounin на mdounin.ru Tue Mar 15 13:57:35 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 15 Mar 2016 16:57:35 +0300 Subject: Acept systemd.socket In-Reply-To: <98012a8d098732accacf8292330ed590.NginxMailingListRussian@forum.nginx.org> References: <98012a8d098732accacf8292330ed590.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160315135735.GX12808@mdounin.ru> Hello! On Tue, Mar 15, 2016 at 01:32:04AM -0400, S.A.N wrote: > Есть в планах на ближайшие будущие, реализация принятия сокета от unit > systemd.socket? Скорее нет, чем да. Но для страждущих есть специальное место, где перепись: https://trac.nginx.org/nginx/ticket/237 Там же описано, как это можно попробовать сделать уже сейчас. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Tue Mar 15 14:33:10 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 15 Mar 2016 10:33:10 -0400 Subject: Acept systemd.socket In-Reply-To: <20160315135735.GX12808@mdounin.ru> References: <20160315135735.GX12808@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > On Tue, Mar 15, 2016 at 01:32:04AM -0400, S.A.N wrote: > > > Есть в планах на ближайшие будущие, реализация принятия сокета от > unit > > systemd.socket? > > Скорее нет, чем да. > Но для страждущих есть специальное место, где перепись: > > https://trac.nginx.org/nginx/ticket/237 > > Там же описано, как это можно попробовать сделать уже сейчас. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Спасибо, почитал, оказывается люди ещё 3 года назад хотели этого, я их понимаю. Наш use case простой, нужно чтобы на ранней стадии загрузки OS, нужные порты могли принимать конекты, systemd.socket идеальный вариант, мы его используем для наших бекендов. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265330,265350#msg-265350 From sirotar на mail.ru Tue Mar 15 14:41:09 2016 From: sirotar на mail.ru (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Tue, 15 Mar 2016 17:41:09 +0300 Subject: http_geoip_module Message-ID: <56E81F05.3090601@mail.ru> Добрый день, подскажите что я делаю не так обновил nginx с 1.8.1 до nginx version: nginx/1.9.12 и появились ругательства на geoip_country /usr/local/etc/rc.d/nginx configtest Performing sanity check on nginx configuration: nginx: [emerg] unknown directive "geoip_country" in /usr/local/etc/nginx/nginx.conf:33 nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed nginx -V nginx version: nginx/1.9.12 built with OpenSSL 1.0.2g 1 Mar 2016 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --modules-path=/usr/local/etc/nginx/modules --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-ipv6 --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log *--with-http_geoip_module*=dynamic --with-http_gzip_static_module --with-http_gunzip_module --with-http_perl_module=dynamic --with-http_realip_module --with-http_stub_status_module --with-pcre --with-http_v2_module --with-http_ssl_module Хотя модуль присутсвует. Куда копать? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Tue Mar 15 14:53:57 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 15 Mar 2016 17:53:57 +0300 Subject: http_geoip_module In-Reply-To: <56E81F05.3090601@mail.ru> References: <56E81F05.3090601@mail.ru> Message-ID: <20160315145357.GA12808@mdounin.ru> Hello! On Tue, Mar 15, 2016 at 05:41:09PM +0300, Роман wrote: > Добрый день, > подскажите что я делаю не так > обновил nginx с 1.8.1 до nginx version: nginx/1.9.12 > и появились ругательства на geoip_country > > /usr/local/etc/rc.d/nginx configtest > Performing sanity check on nginx configuration: > nginx: [emerg] unknown directive "geoip_country" in > /usr/local/etc/nginx/nginx.conf:33 > nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed > > nginx -V > nginx version: nginx/1.9.12 > built with OpenSSL 1.0.2g 1 Mar 2016 > TLS SNI support enabled > configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I > /usr/local/include' --with-ld-opt='-L /usr/local/lib' > --conf-path=/usr/local/etc/nginx/nginx.conf > --modules-path=/usr/local/etc/nginx/modules > --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid > --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-ipv6 > --http-client-body-temp-path=/var/tmp/nginx/client_body_temp > --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp > --http-proxy-temp-path=/var/tmp/nginx/proxy_temp > --http-scgi-temp-path=/var/tmp/nginx/scgi_temp > --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp > --http-log-path=/var/log/nginx-access.log *--with-http_geoip_module*=dynamic > --with-http_gzip_static_module --with-http_gunzip_module > --with-http_perl_module=dynamic --with-http_realip_module > --with-http_stub_status_module --with-pcre --with-http_v2_module > --with-http_ssl_module > > Хотя модуль присутсвует. > Куда копать? Судя по строке configure - модуль собран динамически ("=dynamic"), соответственно его надо загрузить с помощью директивы load_module (http://nginx.org/r/load_module/ru). Что-нибудь вроде load_modules modules/ngx_http_geoip_module.so; ближе к началу конфига должно помочь. -- Maxim Dounin http://nginx.org/ From bgx на protva.ru Tue Mar 15 15:18:52 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Tue, 15 Mar 2016 18:18:52 +0300 Subject: Acept systemd.socket In-Reply-To: References: <20160315135735.GX12808@mdounin.ru> Message-ID: <20160315151852.GS11145@sie.protva.ru> On Tue, Mar 15, 2016 at 10:33:10AM -0400, S.A.N wrote: > Наш use case простой, нужно чтобы на ранней стадии загрузки OS, нужные порты > могли принимать конекты, systemd.socket идеальный вариант, мы его используем > для наших бекендов. Зачем принимать коннекты, если их некому обрабатывать? Такой use case практически эквивалентен простым дропам syn'ов -- отличие будет лишь в более долгом разгоне после старта сервера, зато нагрузка на сервер будет подниматься плавнее. Т.е. я бы просто поставил где-нибудь на первых этапах загрузки iptables -P INPUT DROP и всё, никаких плясок вокруг сокетной инициализации не нужно. -- Eugene Berdnikov From sirotar на mail.ru Tue Mar 15 15:18:54 2016 From: sirotar на mail.ru (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Tue, 15 Mar 2016 18:18:54 +0300 Subject: http_geoip_module In-Reply-To: <20160315145357.GA12808@mdounin.ru> References: <56E81F05.3090601@mail.ru> <20160315145357.GA12808@mdounin.ru> Message-ID: <56E827DE.2070507@mail.ru> 15.03.2016 17:53, Maxim Dounin пишет: > Hello! > > On Tue, Mar 15, 2016 at 05:41:09PM +0300, Роман wrote: > >> Добрый день, >> подскажите что я делаю не так >> обновил nginx с 1.8.1 до nginx version: nginx/1.9.12 >> и появились ругательства на geoip_country >> >> /usr/local/etc/rc.d/nginx configtest >> Performing sanity check on nginx configuration: >> nginx: [emerg] unknown directive "geoip_country" in >> /usr/local/etc/nginx/nginx.conf:33 >> nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed >> >> nginx -V >> nginx version: nginx/1.9.12 >> built with OpenSSL 1.0.2g 1 Mar 2016 >> TLS SNI support enabled >> configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I >> /usr/local/include' --with-ld-opt='-L /usr/local/lib' >> --conf-path=/usr/local/etc/nginx/nginx.conf >> --modules-path=/usr/local/etc/nginx/modules >> --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid >> --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-ipv6 >> --http-client-body-temp-path=/var/tmp/nginx/client_body_temp >> --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp >> --http-proxy-temp-path=/var/tmp/nginx/proxy_temp >> --http-scgi-temp-path=/var/tmp/nginx/scgi_temp >> --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp >> --http-log-path=/var/log/nginx-access.log *--with-http_geoip_module*=dynamic >> --with-http_gzip_static_module --with-http_gunzip_module >> --with-http_perl_module=dynamic --with-http_realip_module >> --with-http_stub_status_module --with-pcre --with-http_v2_module >> --with-http_ssl_module >> >> Хотя модуль присутсвует. >> Куда копать? > Судя по строке configure - модуль собран динамически ("=dynamic"), > соответственно его надо загрузить с помощью директивы load_module > (http://nginx.org/r/load_module/ru). > > Что-нибудь вроде > > load_modules modules/ngx_http_geoip_module.so; > > ближе к началу конфига должно помочь. Да, большое спасибо. Это помогло. > From alex.hha на gmail.com Tue Mar 15 15:22:52 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Tue, 15 Mar 2016 17:22:52 +0200 Subject: =?UTF-8?B?0JzQvtC00YPQu9GMIHN0cmVhbSDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC90Lg=?= =?UTF-8?B?0LUgbWFw?= Message-ID: Привет, правильно ли я понимаю, что в модуле stream я не могу использовать переменную, которую я объявил через map в http секции? Суть вопроса. данный конфиг нормально работает с http/server http { map $remote_addr $backend { default staging1; 192.168.1.127 staging2; } } upstream staging1 { server 127.0.0.1:8001; } upstream staging2 { server 127.0.0.1:8002; } server { listen 8000; location / { proxy_pass http://$backend; } } но не работает со stream stream { upstream staging1 { server 127.0.0.1:8001; } upstream staging2 { server 127.0.0.1:8002; } server { listen 8003; proxy_pass http://$backend; } } при проверке получаю # nginx -t nginx: [emerg] invalid host in upstream "http://$backend" in /etc/nginx/nginx.conf:24 nginx: configuration file /etc/nginx/nginx.conf test failed 24 строка это директива proxy_pass. Можно ли как то в stream получить поведение, аналогичное первому варианту? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Mar 15 15:39:12 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 15 Mar 2016 11:39:12 -0400 Subject: Acept systemd.socket In-Reply-To: <20160315151852.GS11145@sie.protva.ru> References: <20160315151852.GS11145@sie.protva.ru> Message-ID: <93b88b5dcf214e80bea892058390c70e.NginxMailingListRussian@forum.nginx.org> Evgeniy Berdnikov Wrote: ------------------------------------------------------- > On Tue, Mar 15, 2016 at 10:33:10AM -0400, S.A.N wrote: > > Наш use case простой, нужно чтобы на ранней стадии загрузки OS, > нужные порты > > могли принимать конекты, systemd.socket идеальный вариант, мы его > используем > > для наших бекендов. > > Зачем принимать коннекты, если их некому обрабатывать? Такой use case > практически эквивалентен простым дропам syn'ов -- отличие будет лишь > в более долгом разгоне после старта сервера, зато нагрузка на сервер > будет подниматься плавнее. Т.е. я бы просто поставил где-нибудь на > первых этапах загрузки iptables -P INPUT DROP и всё, никаких плясок > вокруг сокетной инициализации не нужно. > -- > Eugene Berdnikov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Nginx загружается намного позже ядра, наша задача - пока Nginx не загрузился, не терять, не дропать пакеты, а сделать очередь, которую обработает Nginx когда запустится. Для бекендов systemd.socket, отличный аналог upstream queue, который в Nginx Plus. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265330,265360#msg-265360 From maxim на nginx.com Tue Mar 15 15:52:09 2016 From: maxim на nginx.com (Maxim Konovalov) Date: Tue, 15 Mar 2016 18:52:09 +0300 Subject: Acept systemd.socket In-Reply-To: <93b88b5dcf214e80bea892058390c70e.NginxMailingListRussian@forum.nginx.org> References: <20160315151852.GS11145@sie.protva.ru> <93b88b5dcf214e80bea892058390c70e.NginxMailingListRussian@forum.nginx.org> Message-ID: <56E82FA9.1000702@nginx.com> [...] > Nginx загружается намного позже ядра, наша задача - пока Nginx не > загрузился, не терять, не дропать пакеты, а сделать очередь, которую > обработает Nginx когда запустится. > А почему nginx загружается намного позже ядра? Насколько намного, если сравнить со временем загрузки самого ядра? -- Maxim Konovalov From bgx на protva.ru Tue Mar 15 16:03:58 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Tue, 15 Mar 2016 19:03:58 +0300 Subject: Acept systemd.socket In-Reply-To: <93b88b5dcf214e80bea892058390c70e.NginxMailingListRussian@forum.nginx.org> References: <20160315151852.GS11145@sie.protva.ru> <93b88b5dcf214e80bea892058390c70e.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160315160358.GT11145@sie.protva.ru> On Tue, Mar 15, 2016 at 11:39:12AM -0400, S.A.N wrote: > Evgeniy Berdnikov Wrote: > ------------------------------------------------------- > > On Tue, Mar 15, 2016 at 10:33:10AM -0400, S.A.N wrote: > > > Наш use case простой, нужно чтобы на ранней стадии загрузки OS, > > нужные порты > > > могли принимать конекты, systemd.socket идеальный вариант, мы его > > используем > > > для наших бекендов. > > > > Зачем принимать коннекты, если их некому обрабатывать? Такой use case > > практически эквивалентен простым дропам syn'ов -- отличие будет лишь > > в более долгом разгоне после старта сервера, зато нагрузка на сервер > > будет подниматься плавнее. Т.е. я бы просто поставил где-нибудь на > > первых этапах загрузки iptables -P INPUT DROP и всё, никаких плясок > > вокруг сокетной инициализации не нужно. > > -- ... > Nginx загружается намного позже ядра, наша задача - пока Nginx не > загрузился, не терять, не дропать пакеты, а сделать очередь, которую > обработает Nginx когда запустится. Вы, вероятно, не поняли. Коннекции не теряются (вообще, не терять коннекции и не дропать пакеты -- это разные задачи, вторая для tcp не имеет большого смысла). Есть смысл не режектить коннекции пока сервер не запустится, чтобы клиенты не получали отлуп. Ваше решение в этом плане плохо тем, что есть интервал времени между подъёмом сетевых интерфейсов и стартом сервера, когда коннекции режектятся и клиенты получают отказ. Использование systemd для сокетной инициализации от этого не спасает. Если же сервис закрыть пакетным фильтром (на DROP) до подъёма интерфейса, где-нибудь в pre-up, и открыть после старта сервера, то никаких режектов не будет. -- Eugene Berdnikov From nginx на kinetiksoft.com Tue Mar 15 22:10:04 2016 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Wed, 16 Mar 2016 01:10:04 +0300 Subject: =?UTF-8?B?0JHRg9GE0LXRgNC40LfQsNGG0LjRjyBmYXN0Y2dpINCyINGE0LDQudC7LiDQn9C+?= =?UTF-8?B?0YfQtdC80YM/?= Message-ID: <8336504.zmP27NegNL@cybernote> Здравствуйте! Много про это написано, но, к сожалению, не могу понять следующий момент: В локейшене, которые обрабатывает php есть директива fastcgi_buffers 32 4k; Итого ответ до 128к на диск писаться не должен. Тогда как в эррор-логе регулярно проскакивает запись 2016/03/16 00:07:32 [warn] 6902#6902: *16095817 an upstream response is buffered to a temporary file /var/lib/nginx/fastcgi/8/32/0002018328 while reading upstream, client: 195.211.ХХ.ХХ, server: ХХХ, request: "GET /admin/statistics/users/list/users HTTP/1.1", upstream: "fastcgi://unix:/run/php-fpm.socket:", host: "ХХХ", referrer: "https://ХХХ/admin/statistics/users/detail" Максимальный размер ответа nginx по запросу /admin/statistics/users/list/users за сегодня был 46968 , судя по access_log. Как такое может быть? Что я не учитываю? Все остальные директивы про буферы по умолчанию. Размер страницы, насколько я понимаю - 4к. nginx 1.8.1. С уважением, Иван. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Mar 15 23:11:21 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 16 Mar 2016 02:11:21 +0300 Subject: =?UTF-8?B?UmU6INCR0YPRhNC10YDQuNC30LDRhtC40Y8gZmFzdGNnaSDQsiDRhNCw0LnQuy4g?= =?UTF-8?B?0J/QvtGH0LXQvNGDPw==?= In-Reply-To: <8336504.zmP27NegNL@cybernote> References: <8336504.zmP27NegNL@cybernote> Message-ID: <20160315231121.GB12808@mdounin.ru> Hello! On Wed, Mar 16, 2016 at 01:10:04AM +0300, Иван wrote: > Здравствуйте! > > Много про это написано, но, к сожалению, не могу понять следующий момент: > В локейшене, которые обрабатывает php есть директива > fastcgi_buffers 32 4k; > > Итого ответ до 128к на диск писаться не должен. Тогда как в эррор-логе регулярно > проскакивает запись > > 2016/03/16 00:07:32 [warn] 6902#6902: *16095817 an upstream response is buffered to a > temporary file /var/lib/nginx/fastcgi/8/32/0002018328 while reading upstream, client: > 195.211.ХХ.ХХ, server: ХХХ, request: "GET /admin/statistics/users/list/users HTTP/1.1", > upstream: "fastcgi://unix:/run/php-fpm.socket:", host: "ХХХ", referrer: > "https://ХХХ/admin/statistics/users/detail" > > Максимальный размер ответа nginx по запросу /admin/statistics/users/list/users за сегодня > был 46968 , судя по access_log. Как такое может быть? Что я не учитываю? Размер ответа в access_log - уже после gzip-сжатия, если оно включено. Соответственно реальный размер ответа, возвращённого бекендом, может сильно отличаться в большую сторону. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Tue Mar 15 23:34:54 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 15 Mar 2016 19:34:54 -0400 Subject: Acept systemd.socket In-Reply-To: <20160315160358.GT11145@sie.protva.ru> References: <20160315160358.GT11145@sie.protva.ru> Message-ID: Evgeniy Berdnikov Wrote: ------------------------------------------------------- > On Tue, Mar 15, 2016 at 11:39:12AM -0400, S.A.N wrote: > > Evgeniy Berdnikov Wrote: > > ------------------------------------------------------- > > > On Tue, Mar 15, 2016 at 10:33:10AM -0400, S.A.N wrote: > > > > Наш use case простой, нужно чтобы на ранней стадии загрузки OS, > > > нужные порты > > > > могли принимать конекты, systemd.socket идеальный вариант, мы > его > > > используем > > > > для наших бекендов. > > > > > > Зачем принимать коннекты, если их некому обрабатывать? Такой use > case > > > практически эквивалентен простым дропам syn'ов -- отличие будет > лишь > > > в более долгом разгоне после старта сервера, зато нагрузка на > сервер > > > будет подниматься плавнее. Т.е. я бы просто поставил где-нибудь > на > > > первых этапах загрузки iptables -P INPUT DROP и всё, никаких > плясок > > > вокруг сокетной инициализации не нужно. > > > -- > ... > > Nginx загружается намного позже ядра, наша задача - пока Nginx не > > загрузился, не терять, не дропать пакеты, а сделать очередь, которую > > обработает Nginx когда запустится. > > Вы, вероятно, не поняли. Коннекции не теряются (вообще, не терять > коннекции и не дропать пакеты -- это разные задачи, вторая для tcp > не имеет большого смысла). > > Есть смысл не режектить коннекции пока сервер не запустится, чтобы > клиенты не получали отлуп. Ваше решение в этом плане плохо тем, что > есть интервал времени между подъёмом сетевых интерфейсов и стартом > сервера, когда коннекции режектятся и клиенты получают отказ. > Использование systemd для сокетной инициализации от этого не спасает. > Если же сервис закрыть пакетным фильтром (на DROP) до подъёма > интерфейса, > где-нибудь в pre-up, и открыть после старта сервера, то никаких > режектов не будет. > -- > Eugene Berdnikov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Возможно вы правы, но мне как разработчику бекенда, приятней и понятней настраивать директивы systemd.socket. Наши бекенд демоны запускает systemd.socket, он же и следит за ними на протяжении их жизни. Nginx по сути такой же демон, но стартуют при загрузки OS, я замерял время когда доступный systemd.socket и когда Nginx, в результате Nginx готов к принятию конектов на ~700 ms позже, по сравнению с systemd.socket. Это не критично и OS перегружается редко, но зачем терять эти ~700 ms, что-то настраивать в iptables можно, но зачем когда есть systemd. Nginx, станет только лучше если реализует прием сокета от systemd.socket. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265330,265369#msg-265369 From chipitsine на gmail.com Wed Mar 16 04:30:04 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 16 Mar 2016 09:30:04 +0500 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_lua?= In-Reply-To: <20160314132224.GM12808@mdounin.ru> References: <20160314132224.GM12808@mdounin.ru> Message-ID: а можете привести примеры сомнительности кода? 14 марта 2016 г., 18:22 пользователь Maxim Dounin написал: > Hello! > > On Mon, Mar 14, 2016 at 09:34:35AM +0300, Иван Мишин wrote: > > > Всем привет. > > Появилось желание заменить некоторые свои конструкции конфига, на что-то > > сделанное на lua, но с удивлением обнаружил что nginx не поддерживает lua > > из коробки, так и есть? или я ошибаюсь? > > Lua - сторонний модуль. И я бы не рекомендовал использовать его > без нужды, качество кода там - сомнительное. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Wed Mar 16 04:32:17 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 16 Mar 2016 09:32:17 +0500 Subject: =?UTF-8?B?UmU6INC/0L7RgdC70LUg0LDQv9C00LXQudGC0LAg0YEgMS4xLjE5INC90LAgMS44?= =?UTF-8?B?LjEg0YPQstC10LvQuNGH0LXQu9GB0Y8g0YLRgNCw0YTQuNC6INC+0YLQtNCw?= =?UTF-8?B?0YfQuA==?= In-Reply-To: <1a3b8f87ce2f5f76eb1036fa47dd99ed.NginxMailingListRussian@forum.nginx.org> References: <1a3b8f87ce2f5f76eb1036fa47dd99ed.NginxMailingListRussian@forum.nginx.org> Message-ID: да, конечно, устаревшие директивы можно убрать из конфигов 13 марта 2016 г., 6:02 пользователь svd написал: > Добрый день. Вот решили обновиться и заметили такую историю. > В конфигах настроено для php-fpm + сжатие. > > До этого трафик был 10 мегабит поровну и in и out. Теперь out 16-18. > > что могло повлиять на это. может быть какие то директивы конфигов > устаревшие? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,265278,265278#msg-265278 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From v.tolstov на selfip.ru Wed Mar 16 05:36:50 2016 From: v.tolstov на selfip.ru (Vasiliy Tolstov) Date: Wed, 16 Mar 2016 08:36:50 +0300 Subject: Acept systemd.socket In-Reply-To: References: <20160315160358.GT11145@sie.protva.ru> Message-ID: 16 марта 2016 г. 2:35 пользователь "S.A.N" написал: > > Evgeniy Berdnikov Wrote: > ------------------------------------------------------- > > On Tue, Mar 15, 2016 at 11:39:12AM -0400, S.A.N wrote: > > > Evgeniy Berdnikov Wrote: > > > ------------------------------------------------------- > > > > On Tue, Mar 15, 2016 at 10:33:10AM -0400, S.A.N wrote: > > > > > Наш use case простой, нужно чтобы на ранней стадии загрузки OS, > > > > нужные порты > > > > > могли принимать конекты, systemd.socket идеальный вариант, мы > > его > > > > используем > > > > > для наших бекендов. > > > > > > > > Зачем принимать коннекты, если их некому обрабатывать? Такой use > > case > > > > практически эквивалентен простым дропам syn'ов -- отличие будет > > лишь > > > > в более долгом разгоне после старта сервера, зато нагрузка на > > сервер > > > > будет подниматься плавнее. Т.е. я бы просто поставил где-нибудь > > на > > > > первых этапах загрузки iptables -P INPUT DROP и всё, никаких > > плясок > > > > вокруг сокетной инициализации не нужно. > > > > -- > > ... > > > Nginx загружается намного позже ядра, наша задача - пока Nginx не > > > загрузился, не терять, не дропать пакеты, а сделать очередь, которую > > > обработает Nginx когда запустится. > > > > Вы, вероятно, не поняли. Коннекции не теряются (вообще, не терять > > коннекции и не дропать пакеты -- это разные задачи, вторая для tcp > > не имеет большого смысла). > > > > Есть смысл не режектить коннекции пока сервер не запустится, чтобы > > клиенты не получали отлуп. Ваше решение в этом плане плохо тем, что > > есть интервал времени между подъёмом сетевых интерфейсов и стартом > > сервера, когда коннекции режектятся и клиенты получают отказ. > > Использование systemd для сокетной инициализации от этого не спасает. > > Если же сервис закрыть пакетным фильтром (на DROP) до подъёма > > интерфейса, > > где-нибудь в pre-up, и открыть после старта сервера, то никаких > > режектов не будет. > > -- > > Eugene Berdnikov > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Возможно вы правы, но мне как разработчику бекенда, приятней и понятней > настраивать директивы systemd.socket. > > Наши бекенд демоны запускает systemd.socket, он же и следит за ними на > протяжении их жизни. > Nginx по сути такой же демон, но стартуют при загрузки OS, я замерял время > когда доступный systemd.socket и когда Nginx, в результате Nginx готов к > принятию конектов на ~700 ms позже, по сравнению с systemd.socket. > Это не критично и OS перегружается редко, но зачем терять эти ~700 ms, > что-то настраивать в iptables можно, но зачем когда есть systemd. > > Nginx, станет только лучше если реализует прием сокета от systemd.socket. Так а чем плох вариант, дропать при старте системы все,и сделать сервис,который после старта nginx откроет порты? Мне кажется это более универсальным вариантом. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265330,265369#msg-265369 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgx на protva.ru Wed Mar 16 07:25:00 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 16 Mar 2016 10:25:00 +0300 Subject: Acept systemd.socket In-Reply-To: References: <20160315160358.GT11145@sie.protva.ru> Message-ID: <20160316072500.GA15191@protva.ru> On Wed, Mar 16, 2016 at 08:36:50AM +0300, Vasiliy Tolstov wrote: > 16 марта 2016 г. 2:35 пользователь "S.A.N" > написал: > > Возможно вы правы, но мне как разработчику бекенда, приятней и понятней > > настраивать директивы systemd.socket. > > > > Наши бекенд демоны запускает systemd.socket, он же и следит за ними на > > протяжении их жизни. > > Nginx по сути такой же демон, но стартуют при загрузки OS, я замерял время > > когда доступный systemd.socket и когда Nginx, в результате Nginx готов к > > принятию конектов на ~700 ms позже, по сравнению с systemd.socket. > > Это не критично и OS перегружается редко, но зачем терять эти ~700 ms, > > что-то настраивать в iptables можно, но зачем когда есть systemd. > > > > Nginx, станет только лучше если реализует прием сокета от systemd.socket. > > Так а чем плох вариант, дропать при старте системы все,и сделать > сервис,который после старта nginx откроет порты? Мне кажется это более > универсальным вариантом. И более правильным, потому что независимо от чей-то любви к systemd.socket в данном случае он поставленную задачу НЕ решает. Всяко лучше устранить проблему полностью, чем уменьшить её вероятность на несколько процентов. -- Eugene Berdnikov From nginx на kinetiksoft.com Wed Mar 16 08:33:22 2016 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Wed, 16 Mar 2016 11:33:22 +0300 Subject: =?UTF-8?B?UmU6INCR0YPRhNC10YDQuNC30LDRhtC40Y8gZmFzdGNnaSDQsiDRhNCw0LnQuy4g?= =?UTF-8?B?0J/QvtGH0LXQvNGDPw==?= In-Reply-To: <20160315231121.GB12808@mdounin.ru> References: <8336504.zmP27NegNL@cybernote> <20160315231121.GB12808@mdounin.ru> Message-ID: <2549327.glRqNZHtBd@cybernote> В письме от 16 марта 2016 02:11:21 пользователь Maxim Dounin написал: > Hello! > > On Wed, Mar 16, 2016 at 01:10:04AM +0300, Иван wrote: > > Здравствуйте! > > > > Много про это написано, но, к сожалению, не могу понять следующий момент: > > В локейшене, которые обрабатывает php есть директива > > > > fastcgi_buffers 32 4k; > > > > Итого ответ до 128к на диск писаться не должен. Тогда как в эррор-логе > > регулярно проскакивает запись > > > > 2016/03/16 00:07:32 [warn] 6902#6902: *16095817 an upstream response is > > buffered to a temporary file /var/lib/nginx/fastcgi/8/32/0002018328 while > > reading upstream, client: 195.211.ХХ.ХХ, server: ХХХ, request: "GET > > /admin/statistics/users/list/users HTTP/1.1", upstream: > > "fastcgi://unix:/run/php-fpm.socket:", host: "ХХХ", referrer: > > "https://ХХХ/admin/statistics/users/detail" > > > > Максимальный размер ответа nginx по запросу > > /admin/statistics/users/list/users за сегодня был 46968 , судя по > > access_log. Как такое может быть? Что я не учитываю? > Размер ответа в access_log - уже после gzip-сжатия, если оно > включено. Соответственно реальный размер ответа, возвращённого > бекендом, может сильно отличаться в большую сторону. Спасибо. А есть возможность понять сколько реальный размер ответа? Мне немного претит тыкать размеры буфферов наобум. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alex.hha на gmail.com Wed Mar 16 09:58:57 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Wed, 16 Mar 2016 11:58:57 +0200 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvRjCBzdHJlYW0g0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LA=?= =?UTF-8?B?0L3QuNC1IG1hcA==?= In-Reply-To: References: Message-ID: Неужели никто не сталкивался? 2016-03-15 17:22 GMT+02:00 Alex Domoradov : > Привет, > > правильно ли я понимаю, что в модуле stream я не могу использовать > переменную, которую я объявил через map в http секции? > > Суть вопроса. данный конфиг нормально работает с http/server > > http { > map $remote_addr $backend { > default staging1; > 192.168.1.127 staging2; > } > } > > upstream staging1 { > server 127.0.0.1:8001; > } > > upstream staging2 { > server 127.0.0.1:8002; > } > > server { > listen 8000; > > location / { > proxy_pass http://$backend; > } > } > > но не работает со stream > > stream { > > upstream staging1 { > server 127.0.0.1:8001; > } > > upstream staging2 { > server 127.0.0.1:8002; > } > > server { > listen 8003; > proxy_pass http://$backend; > } > } > > при проверке получаю > > # nginx -t > nginx: [emerg] invalid host in upstream "http://$backend" in > /etc/nginx/nginx.conf:24 > nginx: configuration file /etc/nginx/nginx.conf test failed > > 24 строка это директива proxy_pass. Можно ли как то в stream получить > поведение, аналогичное первому варианту? > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From arut на nginx.com Wed Mar 16 10:36:09 2016 From: arut на nginx.com (Roman Arutyunyan) Date: Wed, 16 Mar 2016 13:36:09 +0300 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvRjCBzdHJlYW0g0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LA=?= =?UTF-8?B?0L3QuNC1IG1hcA==?= In-Reply-To: References: Message-ID: <20160316103609.GK85206@Romans-MacBook-Air.local> Добрый день, On Tue, Mar 15, 2016 at 05:22:52PM +0200, Alex Domoradov wrote: > Привет, > > правильно ли я понимаю, что в модуле stream я не могу использовать > переменную, которую я объявил через map в http секции? В модуле stream на текущий момент переменные вообще не поддерживаются. [..] -- Roman Arutyunyan From alex.hha на gmail.com Wed Mar 16 10:39:52 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Wed, 16 Mar 2016 12:39:52 +0200 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvRjCBzdHJlYW0g0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LA=?= =?UTF-8?B?0L3QuNC1IG1hcA==?= In-Reply-To: <20160316103609.GK85206@Romans-MacBook-Air.local> References: <20160316103609.GK85206@Romans-MacBook-Air.local> Message-ID: Понял, спасибо. А может есть какой то workaround так сказать? P.S. в документации, кстати, вроде нет упоминаний этого момента. Думаю, стоит добавить. 2016-03-16 12:36 GMT+02:00 Roman Arutyunyan : > Добрый день, > > On Tue, Mar 15, 2016 at 05:22:52PM +0200, Alex Domoradov wrote: > > Привет, > > > > правильно ли я понимаю, что в модуле stream я не могу использовать > > переменную, которую я объявил через map в http секции? > > В модуле stream на текущий момент переменные вообще не поддерживаются. > > [..] > > -- > Roman Arutyunyan > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From maxim на nginx.com Wed Mar 16 10:59:01 2016 From: maxim на nginx.com (Maxim Konovalov) Date: Wed, 16 Mar 2016 13:59:01 +0300 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvRjCBzdHJlYW0g0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LA=?= =?UTF-8?B?0L3QuNC1IG1hcA==?= In-Reply-To: References: <20160316103609.GK85206@Romans-MacBook-Air.local> Message-ID: <56E93C75.1090309@nginx.com> On 3/16/16 1:39 PM, Alex Domoradov wrote: > Понял, спасибо. А может есть какой то workaround так сказать? > Workaround тут нет, к сожалению, кроме того, что реализовать эту логику пока средствами http {}. Судя по вашей конфигурации, это возможно. В среднесрочной перспективе есть планы поддержки переменных/map в стриме. -- Maxim Konovalov From nginx-forum на forum.nginx.org Wed Mar 16 12:32:26 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Wed, 16 Mar 2016 08:32:26 -0400 Subject: Acept systemd.socket In-Reply-To: <20160316072500.GA15191@protva.ru> References: <20160316072500.GA15191@protva.ru> Message-ID: > И более правильным, потому что независимо от чей-то любви к > systemd.socket > в данном случае он поставленную задачу НЕ решает. Всяко лучше > устранить > проблему полностью, чем уменьшить её вероятность на несколько > процентов. systemd.socket задачу решает, тесты показали что он заметно раньше готов принимать конекты, потом Nginx их принимает, проверил через прокси /usr/lib/systemd/systemd-socket-proxyd 0.0.0.0:80 Я не большой специалист в сетевых интерфейсах, если не сложно объясните мне простыми словами, почему systemd.socket не решает мои задачи? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265330,265394#msg-265394 From mdounin на mdounin.ru Wed Mar 16 13:29:03 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 16 Mar 2016 16:29:03 +0300 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_lua?= In-Reply-To: References: <20160314132224.GM12808@mdounin.ru> Message-ID: <20160316132902.GD12808@mdounin.ru> Hello! On Wed, Mar 16, 2016 at 09:30:04AM +0500, Илья Шипицин wrote: > а можете привести примеры сомнительности кода? Можно. Пример: https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_subrequest.c#L1437 Реимплиментирована с небольними изменениями функция ngx_http_subrequest(). Соответственно при любых сколько-нибудь затрагивающих работу подзапросов внутренних изменениях в nginx - будут проблемы. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Wed Mar 16 13:58:04 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 16 Mar 2016 16:58:04 +0300 Subject: =?UTF-8?B?UmU6INCR0YPRhNC10YDQuNC30LDRhtC40Y8gZmFzdGNnaSDQsiDRhNCw0LnQuy4g?= =?UTF-8?B?0J/QvtGH0LXQvNGDPw==?= In-Reply-To: <2549327.glRqNZHtBd@cybernote> References: <8336504.zmP27NegNL@cybernote> <20160315231121.GB12808@mdounin.ru> <2549327.glRqNZHtBd@cybernote> Message-ID: <20160316135804.GF12808@mdounin.ru> Hello! On Wed, Mar 16, 2016 at 11:33:22AM +0300, Иван wrote: > В письме от 16 марта 2016 02:11:21 пользователь Maxim Dounin написал: > > Hello! > > > > On Wed, Mar 16, 2016 at 01:10:04AM +0300, Иван wrote: > > > Здравствуйте! > > > > > > Много про это написано, но, к сожалению, не могу понять следующий момент: > > > В локейшене, которые обрабатывает php есть директива > > > > > > fastcgi_buffers 32 4k; > > > > > > Итого ответ до 128к на диск писаться не должен. Тогда как в эррор-логе > > > регулярно проскакивает запись > > > > > > 2016/03/16 00:07:32 [warn] 6902#6902: *16095817 an upstream response is > > > buffered to a temporary file /var/lib/nginx/fastcgi/8/32/0002018328 while > > > reading upstream, client: 195.211.ХХ.ХХ, server: ХХХ, request: "GET > > > /admin/statistics/users/list/users HTTP/1.1", upstream: > > > "fastcgi://unix:/run/php-fpm.socket:", host: "ХХХ", referrer: > > > "https://ХХХ/admin/statistics/users/detail" > > > > > > Максимальный размер ответа nginx по запросу > > > /admin/statistics/users/list/users за сегодня был 46968 , судя по > > > access_log. Как такое может быть? Что я не учитываю? > > Размер ответа в access_log - уже после gzip-сжатия, если оно > > включено. Соответственно реальный размер ответа, возвращённого > > бекендом, может сильно отличаться в большую сторону. > > Спасибо. > > А есть возможность понять сколько реальный размер ответа? Мне немного претит > тыкать размеры буфферов наобум. http://nginx.org/r/$upstream_response_length/ru -- Maxim Dounin http://nginx.org/ From alex.hha на gmail.com Wed Mar 16 14:44:35 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Wed, 16 Mar 2016 16:44:35 +0200 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvRjCBzdHJlYW0g0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LA=?= =?UTF-8?B?0L3QuNC1IG1hcA==?= In-Reply-To: <56E93C75.1090309@nginx.com> References: <20160316103609.GK85206@Romans-MacBook-Air.local> <56E93C75.1090309@nginx.com> Message-ID: А как примерно будет выглядеть мой конфиг для stream переписанный через http? 2016-03-16 12:59 GMT+02:00 Maxim Konovalov : > On 3/16/16 1:39 PM, Alex Domoradov wrote: > > Понял, спасибо. А может есть какой то workaround так сказать? > > > Workaround тут нет, к сожалению, кроме того, что реализовать эту > логику пока средствами http {}. Судя по вашей конфигурации, это > возможно. > > В среднесрочной перспективе есть планы поддержки переменных/map в > стриме. > > -- > Maxim Konovalov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Wed Mar 16 14:54:46 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 16 Mar 2016 17:54:46 +0300 Subject: Acept systemd.socket In-Reply-To: References: <20160316072500.GA15191@protva.ru> Message-ID: <20160316145446.GE20702@cio.protva.ru> On Wed, Mar 16, 2016 at 08:32:26AM -0400, S.A.N wrote: > > И более правильным, потому что независимо от чей-то любви к > > systemd.socket > > в данном случае он поставленную задачу НЕ решает. Всяко лучше > > устранить > > проблему полностью, чем уменьшить её вероятность на несколько > > процентов. > > systemd.socket задачу решает, тесты показали что он заметно раньше готов > принимать конекты, потом Nginx их принимает, проверил через прокси > /usr/lib/systemd/systemd-socket-proxyd 0.0.0.0:80 > > Я не большой специалист в сетевых интерфейсах, если не сложно объясните мне > простыми словами, почему systemd.socket не решает мои задачи? Не решает потому, что интерфейсы активируются до того, как systemd создаёт и привязывает сокеты. Поэтому есть интервал времени, когда коннекции режектятся. Перечитайте внимательно предыдущие письма. -- Eugene Berdnikov From alex.hha на gmail.com Wed Mar 16 15:03:53 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Wed, 16 Mar 2016 17:03:53 +0200 Subject: Acept systemd.socket In-Reply-To: <20160316145446.GE20702@cio.protva.ru> References: <20160316072500.GA15191@protva.ru> <20160316145446.GE20702@cio.protva.ru> Message-ID: Просто для общего развития. А что, для кого то 700 ms (я так понял именно такая задержка) реально играют роль? 2016-03-16 16:54 GMT+02:00 Evgeniy Berdnikov : > On Wed, Mar 16, 2016 at 08:32:26AM -0400, S.A.N wrote: > > > И более правильным, потому что независимо от чей-то любви к > > > systemd.socket > > > в данном случае он поставленную задачу НЕ решает. Всяко лучше > > > устранить > > > проблему полностью, чем уменьшить её вероятность на несколько > > > процентов. > > > > systemd.socket задачу решает, тесты показали что он заметно раньше готов > > принимать конекты, потом Nginx их принимает, проверил через прокси > > /usr/lib/systemd/systemd-socket-proxyd 0.0.0.0:80 > > > > Я не большой специалист в сетевых интерфейсах, если не сложно объясните > мне > > простыми словами, почему systemd.socket не решает мои задачи? > > Не решает потому, что интерфейсы активируются до того, как systemd > создаёт и привязывает сокеты. Поэтому есть интервал времени, когда > коннекции режектятся. Перечитайте внимательно предыдущие письма. > -- > Eugene Berdnikov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From simplebox66 на gmail.com Wed Mar 16 15:04:06 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 16 Mar 2016 18:04:06 +0300 Subject: =?UTF-8?B?d2ViZGF2INC30LDQv9C40YHRjCDRhNCw0LnQu9CwINC/0L4g0LTRgNGD0LPQvtC8?= =?UTF-8?B?0YMgcm9vdCDQsiDRgdC70YPRh9Cw0LUg0LXRgdC70Lgg0LfQsNC60L7QvdGH?= =?UTF-8?B?0LjQu9C+0YHRjCDQvNC10YHRgtC+?= Message-ID: Добрый день! Вопрос следующий: Есть nginx 1.8.1, на нем настроен вебдав. Конфиг простой > server { > listen 80; > server_name testdav; > > access_log /var/log/nginx/testdav_access.log main; > error_log /var/log/nginx/testdav_error.log error; > location / { > root /tmp/ram/testdav; > open_file_cache off; > client_max_body_size 1000m; > dav_methods PUT; > dav_access user:rw group:r all:r; > create_full_put_path on; > } В случае когда nginx записывает файл в /tmp/ram/testdav и там кончается место, хочется сделать так чтобы nginx этот файл записал в другое место /tmp2/ram/testdav. Есть идеи как это реализовать? В случае нехватки места nginx отдает 500 ошибку. пробовал конфиг > server { > listen 80; > server_name testdav; > > access_log /var/log/nginx/testdav_access.log main; > error_log /var/log/nginx/testdav_error.log error; > > location / { > error_page 500 = @e500; > > root /tmp/ram/testdav; > open_file_cache off; > client_max_body_size 1000m; > > dav_methods PUT; > dav_access user:rw group:r all:r; > create_full_put_path on; > } > > location @e500 { > root /tmp2/ram/testdav; > open_file_cache off; > client_max_body_size 1000m; > dav_methods PUT; > dav_access user:rw group:r all:r; > create_full_put_path on; > } > } Но не работает, в логах: > 2016/03/16 17:40:20 [alert] 15872#0: *1 write() has written only 24576 of > 2338816 to /tmp/ram/testdav/tengine.tar.0000000002, client: 127.0.0.1, > server: testdav, request: "PUT /tengine.tar HTTP/1.1", host: "testdav" > 2016/03/16 17:40:20 [crit] 15872#0: *1 chmod() > "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or > directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar > HTTP/1.1", host: "testdav" > 2016/03/16 17:40:20 [crit] 15872#0: *1 unlink() > "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or > directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar > HTTP/1.1", host: "testdav" ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Wed Mar 16 15:08:01 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 16 Mar 2016 18:08:01 +0300 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_lua?= In-Reply-To: <56E712DD.3050704@mva.name> References: <20160314132224.GM12808@mdounin.ru> <56E712DD.3050704@mva.name> Message-ID: <1904785.f8KLnbMoWi@vbart-workstation> On Tuesday 15 March 2016 01:37:01 Vadim A. Misbakh-Soloviov wrote: > > Lua - сторонний модуль. И я бы не рекомендовал использовать его > > без нужды, качество кода там - сомнительное. > > Ну, какой есть. Если бы был Lua-модуль от команды NgX — я бы был в > первых рядах, что называется, "писающих кипятком от счастья". Но, увы, > от команды NgX есть только NJS (и тот не в стандартной коробке, и, к > тому же, не смотрел как он там с поддержкой сборки в качестве стороннего > модуля). А Lua есть только от Yichun'а Zhang'а, увы ☹… > > // с другой стороны, я, конечно, не перелопачивал *весь* код ngx-lua, но > в тех местах, где я контрибьютил — код вполне нормальный, на мой > админский (не программерский) взгляд ☺ > [..] Количество строк кода на Си в nginx: nginx $ sloccount src ansic: 121577 Количество строк кода на Си в lua-модуле для nginx (это только модуль, без самого lua-интерпретатора): lua-nginx-module $ sloccount src ansic: 34276 т.е. объем одного lua-модуля превышает четверть nginx-а со всеми его 50+ модулями. Выводы каждый может сделать сам. -- Валентин Бартенев From mva на mva.name Wed Mar 16 17:30:45 2016 From: mva на mva.name (Vadim A. Misbakh-Soloviov) Date: Wed, 16 Mar 2016 23:30:45 +0600 Subject: =?UTF-8?B?0J/QvtC00LTQtdGA0LbQutCwIGlkbi3QtNC+0LzQtdC90L7Qsg==?= Message-ID: <56E99845.5020500@mva.name> Вроде бы подобное в листе уже пробегало, но, что-то, я не смог найти в своих архивах. В общем, я хотел бы спросить на счёт того, то товарищи разработчики думают о том, чтобы добавить опциональную директиву при сборке для линковки с libidn (ну, или не добавлять, а реимплементировать своими силами) для того, чтобы получить поддержку idn-доменов в конфиге? А то уж очень задалбывает конвертировать все IDN-домены перед добавлением, а потом ещё конвертировать обратно чтобы вспомнить что это за домен. В данный момент NginX не матерится на юникодные домены в конфиге, но и не воспринимает их как IDN (нверное, ждёт запрос к юникодному). При этом, на сколько я помню, ни одним стандартом такое нынче не разрешено. Да и когда-то давно такое поддерживал то ли только wget, то ли только curl. В любом случае, ни в DNS, ни в hosts, на сколько я помню, юникодный домен не засунешь. Так что в таком виде эта фича получается не к месту. В то время, как указывать IDN-домены без конвертации было бы довольно удобно :) From mail на knutov.com Wed Mar 16 18:13:22 2016 From: mail на knutov.com (Nick Knutov) Date: Wed, 16 Mar 2016 23:13:22 +0500 Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LrQsCBpZG4t0LTQvtC80LXQvdC+0LI=?= In-Reply-To: <56E99845.5020500@mva.name> References: <56E99845.5020500@mva.name> Message-ID: <56E9A242.1070707@knutov.com> А зачем это всё? Конфиги же генерируются не людьми, комментарии в конфигах никто не запрещал. Мы просто при перегенерации конфигов пишем строчку с комментом и всё удобно (да и остальную информацию для отладки сборки конфигов все равно приходится писать) 16.03.2016 22:30, Vadim A. Misbakh-Soloviov пишет: > Вроде бы подобное в листе уже пробегало, но, что-то, я не смог найти в > своих архивах. > > В общем, я хотел бы спросить на счёт того, то товарищи разработчики > думают о том, чтобы добавить опциональную директиву при сборке для > линковки с libidn (ну, или не добавлять, а реимплементировать своими > силами) для того, чтобы получить поддержку idn-доменов в конфиге? > А то уж очень задалбывает конвертировать все IDN-домены перед > добавлением, а потом ещё конвертировать обратно чтобы вспомнить что это > за домен. -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From denis на webmaster.spb.ru Wed Mar 16 21:17:09 2016 From: denis на webmaster.spb.ru (denis) Date: Thu, 17 Mar 2016 00:17:09 +0300 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_lua?= In-Reply-To: <1904785.f8KLnbMoWi@vbart-workstation> References: <20160314132224.GM12808@mdounin.ru> <56E712DD.3050704@mva.name> <1904785.f8KLnbMoWi@vbart-workstation> Message-ID: <56E9CD55.30203@webmaster.spb.ru> 16.03.2016 18:08, Валентин Бартенев пишет: > > Количество строк кода на Си в nginx: > > nginx $ sloccount src > > ansic: 121577 > > Количество строк кода на Си в lua-модуле для nginx > (это только модуль, без самого lua-интерпретатора): > > lua-nginx-module $ sloccount src > > ansic: 34276 > > т.е. объем одного lua-модуля превышает четверть nginx-а > со всеми его 50+ модулями. > > Выводы каждый может сделать сам. вывод - много кода это плохо? Что мешает тогда взять этот код и почистить его как следует? Или это таки нужный код, который нельзя так выкинуть? И заодно весь софт, где больше миллиона строк, включая ядро линукса. А по делу - если есть код типа ngx_http_subrequest(), что мешает привести код в норму? Понимаю что хочу многого, но почему до сих пор нет нормальных лёгких _современных_ модулей? Желательно не js, очень он.. попахивает, луа лучше. Ну и хорошо бы, чтобы была предкомпиляция, чтобы код не интерпретировался при каждом запуске с нуля, это чересчур накладно. From chipitsine на gmail.com Thu Mar 17 03:58:27 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 17 Mar 2016 08:58:27 +0500 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_lua?= In-Reply-To: <20160316132902.GD12808@mdounin.ru> References: <20160314132224.GM12808@mdounin.ru> <20160316132902.GD12808@mdounin.ru> Message-ID: а как будет сделать правильно? 16 марта 2016 г., 18:29 пользователь Maxim Dounin написал: > Hello! > > On Wed, Mar 16, 2016 at 09:30:04AM +0500, Илья Шипицин wrote: > > > а можете привести примеры сомнительности кода? > > Можно. Пример: > > > https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_subrequest.c#L1437 > > Реимплиментирована с небольними изменениями функция > ngx_http_subrequest(). Соответственно при любых сколько-нибудь > затрагивающих работу подзапросов внутренних изменениях в > nginx - будут проблемы. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Mar 17 04:45:03 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 17 Mar 2016 07:45:03 +0300 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_lua?= In-Reply-To: References: <20160314132224.GM12808@mdounin.ru> <20160316132902.GD12808@mdounin.ru> Message-ID: <20160317044503.GP12808@mdounin.ru> Hello! On Thu, Mar 17, 2016 at 08:58:27AM +0500, Илья Шипицин wrote: > а как будет сделать правильно? Правильно - не пытаться реимплементировать с собственными изменениями внутренние функции nginx'а, а использовать те, что есть. И если они по каким-то причинам недостаточны - думать о том, как сделать так, чтобы они были достаточны, либо расширив стандартные функции, либо переосмыслив работу собственного кода. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Thu Mar 17 07:52:44 2016 From: nginx-forum на forum.nginx.org (snike) Date: Thu, 17 Mar 2016 03:52:44 -0400 Subject: =?UTF-8?B?0LIg0L3QvtCy0L7QuSDQstC10YDRgdC40LggY2hyb21lICg0OS4wLjI2MjMuODcg?= =?UTF-8?B?bSkg0L3QtSDQvtGC0L7QsdGA0LDQttCw0LXRgtGB0Y8g0YLQtdC60YHRgiBh?= =?UTF-8?B?dXRoIGJhc2lj?= Message-ID: Новый хром перестал отображать текст из параметра auth_basic location / { auth_basic "MESSAGE"; auth_basic_user_file conf/htpasswd; } сообщения MESSAGE в окне нет. скриншот http://i.piccy.info/i9/dc60b89471352c1a57e55b246882ae5f/1458201082/13592/1012881/nginx.jpg Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265425,265425#msg-265425 From alex.hha на gmail.com Thu Mar 17 08:25:17 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 17 Mar 2016 10:25:17 +0200 Subject: =?UTF-8?B?UmU6INCyINC90L7QstC+0Lkg0LLQtdGA0YHQuNC4IGNocm9tZSAoNDkuMC4yNjIz?= =?UTF-8?B?Ljg3IG0pINC90LUg0L7RgtC+0LHRgNCw0LbQsNC10YLRgdGPINGC0LXQutGB?= =?UTF-8?B?0YIgYXV0aCBiYXNpYw==?= In-Reply-To: References: Message-ID: А при чем тут nginx? С apache такая же картина ;) On Thu, Mar 17, 2016 at 9:52 AM, snike wrote: > Новый хром перестал отображать текст из параметра auth_basic > > location / { > auth_basic "MESSAGE"; > auth_basic_user_file conf/htpasswd; > } > > > > сообщения MESSAGE в окне нет. > > скриншот > > http://i.piccy.info/i9/dc60b89471352c1a57e55b246882ae5f/1458201082/13592/1012881/nginx.jpg > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,265425,265425#msg-265425 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu Mar 17 10:52:07 2016 From: nginx-forum на forum.nginx.org (e.lodyanov) Date: Thu, 17 Mar 2016 06:52:07 -0400 Subject: =?UTF-8?B?0JLQvtC30LzQvtC20L3QsCDQu9C4INC/0LXRgNC10LDQtNGA0LXRgdCw0YbQuNGP?= =?UTF-8?B?INGBIC9rb2xlc2EvaW5kZXgucGhwINC90LAgL2tvbGVzYS8=?= Message-ID: <5618b9ee5973c44faddcfe4bf1c5a905.NginxMailingListRussian@forum.nginx.org> Привет от дилетантов в nginx. Подскажите, возможна ли переадресация с /kolesa/index.php на /kolesa/? Пробовал такой вариант, но не сработало: server { listen __.___.__.___:80; server_name www.domen.ru/kolesa/index.php; return 301 ^ http://domen.ru/kolesa/$request_uri? permanent; #301 redirect } Подскажите как сделать такую переадресацию. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265428,265428#msg-265428 From alex.hha на gmail.com Thu Mar 17 10:59:28 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 17 Mar 2016 12:59:28 +0200 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQv9C10YDQtdCw0LTRgNC10YHQsNGG?= =?UTF-8?B?0LjRjyDRgSAva29sZXNhL2luZGV4LnBocCDQvdCwIC9rb2xlc2Ev?= In-Reply-To: <5618b9ee5973c44faddcfe4bf1c5a905.NginxMailingListRussian@forum.nginx.org> References: <5618b9ee5973c44faddcfe4bf1c5a905.NginxMailingListRussian@forum.nginx.org> Message-ID: Если только один url то можно так location = /kolesa/index.php { return 301 $scheme://$server_name:$server_port/kolesa/; } 2016-03-17 12:52 GMT+02:00 e.lodyanov : > Привет от дилетантов в nginx. Подскажите, возможна ли переадресация с > /kolesa/index.php на /kolesa/? > Пробовал такой вариант, но не сработало: > server { > listen __.___.__.___:80; > server_name www.domen.ru/kolesa/index.php; > return 301 ^ http://domen.ru/kolesa/$request_uri? permanent; #301 redirect > } > Подскажите как сделать такую переадресацию. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,265428,265428#msg-265428 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu Mar 17 11:37:35 2016 From: nginx-forum на forum.nginx.org (snike) Date: Thu, 17 Mar 2016 07:37:35 -0400 Subject: =?UTF-8?B?UmU6INCyINC90L7QstC+0Lkg0LLQtdGA0YHQuNC4IGNocm9tZSAoNDkuMC4yNjIz?= =?UTF-8?B?Ljg3IG0pINC90LUg0L7RgtC+0LHRgNCw0LbQsNC10YLRgdGPINGC0LXQutGB?= =?UTF-8?B?0YIgYXV0aCBiYXNpYw==?= In-Reply-To: References: Message-ID: <2fc95f6430f55cd0d9bd244d9531eb9c.NginxMailingListRussian@forum.nginx.org> авторизация у мен в nginx , еслии с апачем та же беда то плохо... есть решение? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265425,265433#msg-265433 From nginx-forum на forum.nginx.org Thu Mar 17 11:56:06 2016 From: nginx-forum на forum.nginx.org (e.lodyanov) Date: Thu, 17 Mar 2016 07:56:06 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQv9C10YDQtdCw0LTRgNC10YHQsNGG?= =?UTF-8?B?0LjRjyDRgSAva29sZXNhL2luZGV4LnBocCDQvdCwIC9rb2xlc2Ev?= In-Reply-To: References: Message-ID: <9fb455b7b1d4ac4d2345475af941539b.NginxMailingListRussian@forum.nginx.org> Переадресация срабатывает, но сайт не грузится, пишет на странице обнаружена циклическая переадресация. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265428,265437#msg-265437 From alex.hha на gmail.com Thu Mar 17 11:59:23 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 17 Mar 2016 13:59:23 +0200 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQv9C10YDQtdCw0LTRgNC10YHQsNGG?= =?UTF-8?B?0LjRjyDRgSAva29sZXNhL2luZGV4LnBocCDQvdCwIC9rb2xlc2Ev?= In-Reply-To: <9fb455b7b1d4ac4d2345475af941539b.NginxMailingListRussian@forum.nginx.org> References: <9fb455b7b1d4ac4d2345475af941539b.NginxMailingListRussian@forum.nginx.org> Message-ID: Ну это уже вам виднее, что там должно быть. Если у вас стоит index index.php, то оно и понятно. 2016-03-17 13:56 GMT+02:00 e.lodyanov : > Переадресация срабатывает, но сайт не грузится, пишет на странице > обнаружена > циклическая переадресация. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,265428,265437#msg-265437 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From denis на webmaster.spb.ru Thu Mar 17 11:58:38 2016 From: denis на webmaster.spb.ru (denis) Date: Thu, 17 Mar 2016 14:58:38 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQv9C10YDQtdCw0LTRgNC10YHQsNGG?= =?UTF-8?B?0LjRjyDRgSAva29sZXNhL2luZGV4LnBocCDQvdCwIC9rb2xlc2Ev?= In-Reply-To: <9fb455b7b1d4ac4d2345475af941539b.NginxMailingListRussian@forum.nginx.org> References: <9fb455b7b1d4ac4d2345475af941539b.NginxMailingListRussian@forum.nginx.org> Message-ID: <56EA9BEE.3050003@webmaster.spb.ru> 17.03.2016 14:56, e.lodyanov пишет: > Переадресация срабатывает, но сайт не грузится, пишет на странице обнаружена > циклическая переадресация. всё правильно делает. Вероятно, нужно просто скрывать index.php из адреса, это делается совсем не редиректом. И начинать надо с апача и htaccess, обычно чпу настраиваются там. From basil на vpm.net.ua Thu Mar 17 12:00:00 2016 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Thu, 17 Mar 2016 14:00:00 +0200 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQv9C10YDQtdCw0LTRgNC10YHQsNGG?= =?UTF-8?B?0LjRjyDRgSAva29sZXNhL2luZGV4LnBocCDQvdCwIC9rb2xlc2Ev?= In-Reply-To: <9fb455b7b1d4ac4d2345475af941539b.NginxMailingListRussian@forum.nginx.org> References: <9fb455b7b1d4ac4d2345475af941539b.NginxMailingListRussian@forum.nginx.org> Message-ID: а с чем воюете? а то как-то index.php он дефолтный и в строке браузера и так не должен показываться 17 марта 2016 г., 13:56 пользователь e.lodyanov написал: > Переадресация срабатывает, но сайт не грузится, пишет на странице > обнаружена > циклическая переадресация. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,265428,265437#msg-265437 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu Mar 17 13:10:01 2016 From: nginx-forum на forum.nginx.org (e.lodyanov) Date: Thu, 17 Mar 2016 09:10:01 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQv9C10YDQtdCw0LTRgNC10YHQsNGG?= =?UTF-8?B?0LjRjyDRgSAva29sZXNhL2luZGV4LnBocCDQvdCwIC9rb2xlc2Ev?= In-Reply-To: References: Message-ID: <27c1b243ddc587c3859a7d11c5ba8697.NginxMailingListRussian@forum.nginx.org> Да, скорее всего есть. Нашел такую строчку: index index.php index.html index.htm default.html default.htm; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265428,265441#msg-265441 From nginx-forum на forum.nginx.org Thu Mar 17 13:12:36 2016 From: nginx-forum на forum.nginx.org (e.lodyanov) Date: Thu, 17 Mar 2016 09:12:36 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQv9C10YDQtdCw0LTRgNC10YHQsNGG?= =?UTF-8?B?0LjRjyDRgSAva29sZXNhL2luZGV4LnBocCDQvdCwIC9rb2xlc2Ev?= In-Reply-To: <56EA9BEE.3050003@webmaster.spb.ru> References: <56EA9BEE.3050003@webmaster.spb.ru> Message-ID: <3076b90bea66950f81503c49fde94026.NginxMailingListRussian@forum.nginx.org> Хотел сделать переадресацию, чтобы людей не смущало наличие index.php в строке браузера. Плюс чтобы не было дублей в поисковиках. Но пока вроде не появились дубли. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265428,265442#msg-265442 From nginx-forum на forum.nginx.org Thu Mar 17 13:17:36 2016 From: nginx-forum на forum.nginx.org (e.lodyanov) Date: Thu, 17 Mar 2016 09:17:36 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQv9C10YDQtdCw0LTRgNC10YHQsNGG?= =?UTF-8?B?0LjRjyDRgSAva29sZXNhL2luZGV4LnBocCDQvdCwIC9rb2xlc2Ev?= In-Reply-To: References: Message-ID: <63f3463ca87d8cb676fdd0948ddc8764.NginxMailingListRussian@forum.nginx.org> Показывается. В Хроме по крайней мере. Вообще я затеял это после того, как обнаружил у Яндекса дубли у другой страницы. /moto/ и /moto определил как разные страницы. Я решил проблему следующим образом: server { listen __.___.__.___:80; server_name www.domen.ru/moto; rewrite ^([^?#]*/)([^?#./]+)([?#].*)?$ $1$2/$3 permanent; } Всё работало месяц назад. Даже Яндекс съел. Сейчас проверил, уже не срабатывает. Полтергейст какой-то. Не подскажите что могло случится? Я ничего после этого не изменял. Как решить, чтобы переадресация срабатывала с /moto на /moto/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265428,265443#msg-265443 From nginx-forum на forum.nginx.org Thu Mar 17 13:23:04 2016 From: nginx-forum на forum.nginx.org (vitcool) Date: Thu, 17 Mar 2016 09:23:04 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQv9C10YDQtdCw0LTRgNC10YHQsNGG?= =?UTF-8?B?0LjRjyDRgSAva29sZXNhL2luZGV4LnBocCDQvdCwIC9rb2xlc2Ev?= In-Reply-To: <63f3463ca87d8cb676fdd0948ddc8764.NginxMailingListRussian@forum.nginx.org> References: <63f3463ca87d8cb676fdd0948ddc8764.NginxMailingListRussian@forum.nginx.org> Message-ID: <5e4c2dc6d4bd025ee5cb3078629043e1.NginxMailingListRussian@forum.nginx.org> e.lodyanov Wrote: ------------------------------------------------------- > срабатывает. Полтергейст какой-то. Не подскажите что могло случится? Я > ничего после этого не изменял. Как решить, чтобы переадресация > срабатывала с /moto на /moto/ самый надежный способ - это на бекенде, контроллер запросов может проверять какой пришел запрос и решать передавать его дальше или ставить заголовок 301 с указанием правильного урла Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265428,265444#msg-265444 From me на kemko.ru Thu Mar 17 13:26:04 2016 From: me на kemko.ru (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JDQvdC00YDQtdC10LI=?=) Date: Thu, 17 Mar 2016 13:26:04 +0000 Subject: =?UTF-8?B?UmU6INCyINC90L7QstC+0Lkg0LLQtdGA0YHQuNC4IGNocm9tZSAoNDkuMC4yNjIz?= =?UTF-8?B?Ljg3IG0pINC90LUg0L7RgtC+0LHRgNCw0LbQsNC10YLRgdGPINGC0LXQutGB?= =?UTF-8?B?0YIgYXV0aCBiYXNpYw==?= In-Reply-To: <2fc95f6430f55cd0d9bd244d9531eb9c.NginxMailingListRussian@forum.nginx.org> References: <2fc95f6430f55cd0d9bd244d9531eb9c.NginxMailingListRussian@forum.nginx.org> Message-ID: https://bugs.chromium.org/p/chromium/issues/detail?id=544244 https://chromium.googlesource.com/chromium/src.git/+/d4fe8211476a0bba1a347204e430aa283c2e7d7f Это явно не баг, а фича с точки зрения разработчиков Chromium, так что или авторизовывать не через basic auth, или идти в тикет и убедительно доказывать, что нужно вернуть старое поведение. чт, 17 мар. 2016 г. в 14:37, snike : > авторизация у мен в nginx , еслии с апачем та же беда то плохо... есть > решение? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,265425,265433#msg-265433 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu Mar 17 13:30:11 2016 From: nginx-forum на forum.nginx.org (K.Konstantin) Date: Thu, 17 Mar 2016 09:30:11 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQv9C10YDQtdCw0LTRgNC10YHQsNGG?= =?UTF-8?B?0LjRjyDRgSAva29sZXNhL2luZGV4LnBocCDQvdCwIC9rb2xlc2Ev?= In-Reply-To: <63f3463ca87d8cb676fdd0948ddc8764.NginxMailingListRussian@forum.nginx.org> References: <63f3463ca87d8cb676fdd0948ddc8764.NginxMailingListRussian@forum.nginx.org> Message-ID: А зачем вы используете: server_name www.domen.ru/moto; server_name www.domen.ru/kolesa/index.php; Почему не используете /location ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265428,265447#msg-265447 From vbart на nginx.com Thu Mar 17 13:35:50 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 17 Mar 2016 16:35:50 +0300 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_lua?= In-Reply-To: <56E9CD55.30203@webmaster.spb.ru> References: <1904785.f8KLnbMoWi@vbart-workstation> <56E9CD55.30203@webmaster.spb.ru> Message-ID: <15683392.4hKX66lUtP@vbart-workstation> On Thursday 17 March 2016 00:17:09 denis wrote: > 16.03.2016 18:08, Валентин Бартенев пишет: > > > > Количество строк кода на Си в nginx: > > > > nginx $ sloccount src > > > > ansic: 121577 > > > > Количество строк кода на Си в lua-модуле для nginx > > (это только модуль, без самого lua-интерпретатора): > > > > lua-nginx-module $ sloccount src > > > > ansic: 34276 > > > > т.е. объем одного lua-модуля превышает четверть nginx-а > > со всеми его 50+ модулями. > > > > Выводы каждый может сделать сам. > вывод - много кода это плохо? Что мешает тогда взять этот код и > почистить его как следует? Или это таки нужный код, который нельзя так > выкинуть? И заодно весь софт, где больше миллиона строк, включая ядро > линукса. Совершенно верно, много кода это плохо, особенно если объем кода не соответствует сложности решаемой задачи. Больше кода означает больше ошибок, больше кода означает больше времени на поддержку этого кода, причем для плохо написанного кода, который дублирует различную функциональность, время на поддержку растет экспоненциально. > А по делу - если есть код типа ngx_http_subrequest(), что мешает > привести код в норму? Я уверен, что автор lua-модуля будет рад вашим патчам. > Понимаю что хочу многого, но почему до сих пор нет нормальных лёгких > _современных_ модулей? Желательно не js, очень он.. попахивает, луа > лучше. Ну и хорошо бы, чтобы была предкомпиляция, чтобы код не > интерпретировался при каждом запуске с нуля, это чересчур накладно. > Вы считаете, что существует востребованная ниша и точно знаете как правильно её заполнить. Так что же мешает этим заняться? Если вы желаете помочь разработке, но не имеете необходимых навыков, то самый лучший способ сделать это - оформить подписку на NGINX Plus. Ссылка тут: https://www.nginx.com/products/pricing/ -- Валентин Бартенев From vbart на nginx.com Thu Mar 17 22:26:36 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 18 Mar 2016 01:26:36 +0300 Subject: Acept systemd.socket In-Reply-To: References: <20160315160358.GT11145@sie.protva.ru> Message-ID: <26542743.oGgCdBpbxy@vbart-laptop> On Tuesday 15 March 2016 19:34:54 S.A.N wrote: [..] > > > Nginx загружается намного позже ядра, наша задача - пока Nginx не > > > загрузился, не терять, не дропать пакеты, а сделать очередь, которую > > > обработает Nginx когда запустится. > > > > Вы, вероятно, не поняли. Коннекции не теряются (вообще, не терять > > коннекции и не дропать пакеты -- это разные задачи, вторая для tcp > > не имеет большого смысла). > > > > Есть смысл не режектить коннекции пока сервер не запустится, чтобы > > клиенты не получали отлуп. Ваше решение в этом плане плохо тем, что > > есть интервал времени между подъёмом сетевых интерфейсов и стартом > > сервера, когда коннекции режектятся и клиенты получают отказ. > > Использование systemd для сокетной инициализации от этого не спасает. > > Если же сервис закрыть пакетным фильтром (на DROP) до подъёма > > интерфейса, > > где-нибудь в pre-up, и открыть после старта сервера, то никаких > > режектов не будет. > > Возможно вы правы, но мне как разработчику бекенда, приятней и понятней > настраивать директивы systemd.socket. > > Наши бекенд демоны запускает systemd.socket, он же и следит за ними на > протяжении их жизни. > Nginx по сути такой же демон, но стартуют при загрузки OS, я замерял время > когда доступный systemd.socket и когда Nginx, в результате Nginx готов к > принятию конектов на ~700 ms позже, по сравнению с systemd.socket. > Это не критично и OS перегружается редко, но зачем терять эти ~700 ms, > что-то настраивать в iptables можно, но зачем когда есть systemd. > > Nginx, станет только лучше если реализует прием сокета от systemd.socket. > Это довольно странное желание - чтобы машина, которая по сути ещё не готова к работе, частично делала вид, что она готова принимать трафик. Что вы будете делать если nginx так и не заработает через 700 мс, а балансировщик уже радостно нальет на неё трафик? Почему вы считаете, что эти 700 мс куда-то теряются, хотя тем временем они могли бы быть обслужены живой машиной за меньшее время? А сколько секунд теряется на биос и загрузку ядра? В чем разница? Т.н. HA обеспечивается вовсе не такими методами. Больше похоже на способ тщательно разложить самому себе грабли у входа. -- Валентин Бартенев From undying-m на yandex.ru Fri Mar 18 01:43:49 2016 From: undying-m на yandex.ru (Den Bozhok) Date: Fri, 18 Mar 2016 04:43:49 +0300 Subject: http/2 + backend http/1.1 Message-ID: <1578381458265429@web29g.yandex.ru> Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Mar 18 02:10:43 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 18 Mar 2016 05:10:43 +0300 Subject: http/2 + backend http/1.1 In-Reply-To: <1578381458265429@web29g.yandex.ru> References: <1578381458265429@web29g.yandex.ru> Message-ID: <20160318021043.GE12808@mdounin.ru> Hello! On Fri, Mar 18, 2016 at 04:43:49AM +0300, Den Bozhok wrote: > Возник следующий вопрос. При использовании http/2 для клиентов и при > этом работая с бэкендами по http/1.1, как происходит работа с > соединениями к бэкенду? > > Насколько я знаю, http/1.1 по умолчанию задумывался как протокол > работающий с keepalive. > > Nginx разбирая мультиплексированные запросы от клиента по http/2 > создает по новому соединению к бэкенду для каждого запроса, или > устанавливает одно TCP соединение и посылает все последующие запросы > клиента по этому соединению? Одновременно запущенные HTTP/2 запросы выполняются независимо, ровно так же, как это было бы, если бы эти запросы пришли по разным соединениям. Соответственно если два запроса одновременно уходят на бекенд - будет открыто два соединения на бекенд, и каждый запрос будет отправлен в своём соединении. -- Maxim Dounin http://nginx.org/ From chipitsine на gmail.com Fri Mar 18 05:05:48 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 18 Mar 2016 10:05:48 +0500 Subject: Acept systemd.socket In-Reply-To: <20160316145446.GE20702@cio.protva.ru> References: <20160316072500.GA15191@protva.ru> <20160316145446.GE20702@cio.protva.ru> Message-ID: systemd - это какая-то программа nginx - какая-то программа ни то, ни другое не является ядром. в чем принципиальная разница, т.е. почему считается, что одна программа может запуститься раньше, чем другая программа ? порядок запуска ведь настраивается, вы можете ядру сказать, что у вас init-процессом является то, что вам больше нравится 16 марта 2016 г., 19:54 пользователь Evgeniy Berdnikov написал: > On Wed, Mar 16, 2016 at 08:32:26AM -0400, S.A.N wrote: > > > И более правильным, потому что независимо от чей-то любви к > > > systemd.socket > > > в данном случае он поставленную задачу НЕ решает. Всяко лучше > > > устранить > > > проблему полностью, чем уменьшить её вероятность на несколько > > > процентов. > > > > systemd.socket задачу решает, тесты показали что он заметно раньше готов > > принимать конекты, потом Nginx их принимает, проверил через прокси > > /usr/lib/systemd/systemd-socket-proxyd 0.0.0.0:80 > > > > Я не большой специалист в сетевых интерфейсах, если не сложно объясните > мне > > простыми словами, почему systemd.socket не решает мои задачи? > > Не решает потому, что интерфейсы активируются до того, как systemd > создаёт и привязывает сокеты. Поэтому есть интервал времени, когда > коннекции режектятся. Перечитайте внимательно предыдущие письма. > -- > Eugene Berdnikov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Fri Mar 18 05:25:17 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 18 Mar 2016 10:25:17 +0500 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: Message-ID: не так давно пробегал пример, как webdav подружить с lua, чудеса уровня тех, про которые вы говорите https://forum.nginx.org/read.php?21,259941,259941 16 марта 2016 г., 20:04 пользователь Иван Мишин написал: > Добрый день! > > Вопрос следующий: > Есть nginx 1.8.1, на нем настроен вебдав. Конфиг простой > >> server { >> listen 80; >> server_name testdav; >> >> access_log /var/log/nginx/testdav_access.log main; >> error_log /var/log/nginx/testdav_error.log error; >> location / { >> root /tmp/ram/testdav; >> open_file_cache off; >> client_max_body_size 1000m; >> dav_methods PUT; >> dav_access user:rw group:r all:r; >> create_full_put_path on; >> } > > В случае когда nginx записывает файл в /tmp/ram/testdav и там кончается > место, хочется сделать так чтобы nginx этот файл записал в другое место > /tmp2/ram/testdav. > Есть идеи как это реализовать? > В случае нехватки места nginx отдает 500 ошибку. пробовал конфиг > >> server { >> listen 80; >> server_name testdav; >> >> access_log /var/log/nginx/testdav_access.log main; >> error_log /var/log/nginx/testdav_error.log error; >> >> location / { >> error_page 500 = @e500; >> >> root /tmp/ram/testdav; >> open_file_cache off; >> client_max_body_size 1000m; >> >> dav_methods PUT; >> dav_access user:rw group:r all:r; >> create_full_put_path on; >> } >> >> location @e500 { >> root /tmp2/ram/testdav; >> open_file_cache off; >> client_max_body_size 1000m; >> dav_methods PUT; >> dav_access user:rw group:r all:r; >> create_full_put_path on; >> } >> } > > > Но не работает, в логах: > >> 2016/03/16 17:40:20 [alert] 15872#0: *1 write() has written only 24576 of >> 2338816 to /tmp/ram/testdav/tengine.tar.0000000002, client: 127.0.0.1, >> server: testdav, request: "PUT /tengine.tar HTTP/1.1", host: "testdav" >> 2016/03/16 17:40:20 [crit] 15872#0: *1 chmod() >> "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or >> directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar >> HTTP/1.1", host: "testdav" >> 2016/03/16 17:40:20 [crit] 15872#0: *1 unlink() >> "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or >> directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar >> HTTP/1.1", host: "testdav" > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Mar 18 06:30:47 2016 From: nginx-forum на forum.nginx.org (rba) Date: Fri, 18 Mar 2016 02:30:47 -0400 Subject: =?UTF-8?B?dXBzdHJlYW0g0Lgga2VlcCBhbGl2ZSAoQVBJLCDQodC4KQ==?= Message-ID: <8ea7be9ada8f5966971aa861810b1808.NginxMailingListRussian@forum.nginx.org> Вводная : upstream создаю во время соединения от клиента в acces handler. Ограничение: помимо вытаскивания backend connection в location conf. Вопрос : есть ли возможность передать соединение с бэкендом от одного запроса к другому в рамках одного соединения keep alive от клиента? 1. Подскажите пример и куда глядеть. 2. И от куда брать память(для ngx_peer_connection_t и т.д.) или r->pool остаётся в какой-то мере жив и достаточен для этого? Заранее благодарен. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265455,265455#msg-265455 From chipitsine на gmail.com Fri Mar 18 06:52:22 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 18 Mar 2016 11:52:22 +0500 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvRjCBzdHJlYW0g0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LA=?= =?UTF-8?B?0L3QuNC1IG1hcA==?= In-Reply-To: References: <20160316103609.GK85206@Romans-MacBook-Air.local> <56E93C75.1090309@nginx.com> Message-ID: у вас в секции stream идет проксирование на http. если это не опечатка, то можно переделать на http 16 марта 2016 г., 19:44 пользователь Alex Domoradov написал: > А как примерно будет выглядеть мой конфиг для stream переписанный через > http? > > 2016-03-16 12:59 GMT+02:00 Maxim Konovalov : > >> On 3/16/16 1:39 PM, Alex Domoradov wrote: >> > Понял, спасибо. А может есть какой то workaround так сказать? >> > >> Workaround тут нет, к сожалению, кроме того, что реализовать эту >> логику пока средствами http {}. Судя по вашей конфигурации, это >> возможно. >> >> В среднесрочной перспективе есть планы поддержки переменных/map в >> стриме. >> >> -- >> Maxim Konovalov >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Mar 18 07:36:32 2016 From: nginx-forum на forum.nginx.org (e.lodyanov) Date: Fri, 18 Mar 2016 03:36:32 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQv9C10YDQtdCw0LTRgNC10YHQsNGG?= =?UTF-8?B?0LjRjyDRgSAva29sZXNhL2luZGV4LnBocCDQvdCwIC9rb2xlc2Ev?= In-Reply-To: References: <63f3463ca87d8cb676fdd0948ddc8764.NginxMailingListRussian@forum.nginx.org> Message-ID: Я новичок в этом, где-то в интернете нашёл и скопировал. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265428,265456#msg-265456 From nginx-forum на forum.nginx.org Fri Mar 18 07:37:07 2016 From: nginx-forum на forum.nginx.org (e.lodyanov) Date: Fri, 18 Mar 2016 03:37:07 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQv9C10YDQtdCw0LTRgNC10YHQsNGG?= =?UTF-8?B?0LjRjyDRgSAva29sZXNhL2luZGV4LnBocCDQvdCwIC9rb2xlc2Ev?= In-Reply-To: <5e4c2dc6d4bd025ee5cb3078629043e1.NginxMailingListRussian@forum.nginx.org> References: <63f3463ca87d8cb676fdd0948ddc8764.NginxMailingListRussian@forum.nginx.org> <5e4c2dc6d4bd025ee5cb3078629043e1.NginxMailingListRussian@forum.nginx.org> Message-ID: Таак. И как же это должно быть прописано? И где? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265428,265457#msg-265457 From a.korostelev на ngenix.net Fri Mar 18 07:53:34 2016 From: a.korostelev на ngenix.net (Anatoliy Korostelevm, NGENIX) Date: Fri, 18 Mar 2016 10:53:34 +0300 Subject: mp4 pseudostreaming with proxy_pass and slice Message-ID: <56EBB3FE.4050502@ngenix.net> Здравствуйте! Меня интересует возможность nginx, позволяющая проксировать запросы на mp4 к бекэнду, чтобы при этом не было необходимости выкачивать на бекэнд весь mp4 (файл может быть очень большим), а было лишь достаточно послать range-запрос на необходимые данные, их закешировать и отдавать клиенту. Для тестирования данной возможности я создал следующую конфигурацию (привожу кусок): location / { proxy_pass http://someIP$uri; proxy_set_header Host example.net proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_http_version 1.1; slice 1m; proxy_set_header Range $slice_range; proxy_cache_valid 200 206 1d; proxy_cache irlem; proxy_cache_key $uri$slice_range; } Все работает как и запланировано - если я шлю с клиента на nginx Range-запрос, nginx и клиент получат необходимую часть данных, выравненных по размеру slice. Однако, хотелось бы получать порцию необходимых данных. использую не только Range-запросы, но и явно указывая в URI момент начала (и возможно конца) видео. Например, чтобы при запросе к nginx вида http://mynginx.server/test.mp4?start=40 хотелось бы что nginx преобразовывал start=40 в соответствующий Range-запрос к бэкенду и выкачивал только необходимые данные. Я добавил в конфигурацию своего location параметр mp4 для этого, однако, как выяснилось, mp4 не совместим с proxy_pass. Подскажите, кто-то реализовывал на nginx что-то подобное, и если реализовал то как? Или единственный путь, это писать данную возможность самому (на lua, ngscript, своим модулем, etc)? С уважением, Коростелев Анатолий From undying-m на yandex.ru Fri Mar 18 08:21:44 2016 From: undying-m на yandex.ru (Den Bozhok) Date: Fri, 18 Mar 2016 11:21:44 +0300 Subject: http/2 + backend http/1.1 In-Reply-To: 158188936911436918 References: <1578381458265429@web29g.yandex.ru> <20160318021043.GE12808@mdounin.ru> Message-ID: <2799901458289304@web13o.yandex.ru> Понял, спасибо большое! А что насчёт директивы resolve? Есть ли какая-нибудь информация о передаче её в массы? 18.03.2016, 05:10, "Maxim Dounin" : > Hello! > > On Fri, Mar 18, 2016 at 04:43:49AM +0300, Den Bozhok wrote: > >>     Возник следующий вопрос. При использовании http/2 для клиентов и при >>     этом работая с бэкендами по http/1.1, как происходит работа с >>     соединениями к бэкенду? >> >>     Насколько я знаю, http/1.1 по умолчанию задумывался как протокол >>     работающий с keepalive. >> >>     Nginx разбирая мультиплексированные запросы от клиента по http/2 >>     создает по новому соединению к бэкенду для каждого запроса, или >>     устанавливает одно TCP соединение и посылает все последующие запросы >>     клиента по этому соединению? > > Одновременно запущенные HTTP/2 запросы выполняются независимо, > ровно так же, как это было бы, если бы эти запросы пришли по > разным соединениям. Соответственно если два запроса одновременно > уходят на бекенд - будет открыто два соединения на бекенд, и > каждый запрос будет отправлен в своём соединении. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From maxim на nginx.com Fri Mar 18 08:35:17 2016 From: maxim на nginx.com (Maxim Konovalov) Date: Fri, 18 Mar 2016 11:35:17 +0300 Subject: http/2 + backend http/1.1 In-Reply-To: <2799901458289304@web13o.yandex.ru> References: <1578381458265429@web29g.yandex.ru> <20160318021043.GE12808@mdounin.ru> <2799901458289304@web13o.yandex.ru> Message-ID: <56EBBDC5.8010407@nginx.com> On 3/18/16 11:21 AM, Den Bozhok wrote: > Понял, спасибо большое! > А что насчёт директивы resolve? Есть ли какая-нибудь информация о передаче её в массы? > Вы про опцию "resolve" директивы "server" в модулях *_upstream? Она включает периодический ре-ризолв имен, заданных в секции upstream {}, используя настройки ризолвера в директиве resolver. Вроде бы у нас это задокументировано достаточно хорошо: http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server nginx.org/r/resolver Доступна эта штука только в nginx-plus. Или есть какой-то специфичный вопрос? -- Maxim Konovalov From myc на cname.me Fri Mar 18 08:38:37 2016 From: myc на cname.me (Eugene Mychlo) Date: Fri, 18 Mar 2016 11:38:37 +0300 Subject: mp4 pseudostreaming with proxy_pass and slice In-Reply-To: <56EBB3FE.4050502@ngenix.net> References: <56EBB3FE.4050502@ngenix.net> Message-ID: <7E507B91-2F06-4321-97F4-DCAC97CC8E65@cname.me> > 18 марта 2016 г., в 10:53, Anatoliy Korostelevm, NGENIX написал(а): > > Все работает как и запланировано - если я шлю с клиента на nginx Range-запрос, nginx и клиент получат необходимую часть данных, выравненных по размеру slice. Однако, хотелось бы получать порцию необходимых данных. использую не только Range-запросы, но и явно указывая в URI момент начала (и возможно конца) видео. Например, чтобы при запросе к nginx вида http://mynginx.server/test.mp4?start=40 хотелось бы что nginx преобразовывал start=40 в соответствующий Range-запрос к бэкенду и выкачивал только необходимые данные. Я добавил в конфигурацию своего location параметр mp4 для этого, однако, как выяснилось, mp4 не совместим с proxy_pass. Подскажите, кто-то реализовывал на nginx что-то подобное, и если реализовал то как? Или единственный путь, это писать данную возможность самому (на lua, ngscript, своим модулем, etc)? 1. mp4-модуль - это контент-хендлер. Он умеет работать только с локальными файлами. Модуль реализует протокол progressive download. Progressive download - это костыль, необходимый только флешу для быстрой перемотки, т.к. флеш не умеет делать range-запросы. Можно во флеш-плеере передавать range в аргументах (на стороне сервера это понимать и отдавать нужный фрагмент), а потом на стороне плеера собирать файл. Однако это потребует доработок плеера. Не уверен, что вам нужно это. 2. slice-модуль - это фильтр. Он работает уже после контент-хендлера (значение $slice_range может формироваться раньше). С mp4 модулем он работать не может. :) Однако передать range в аргументах все же можно. Для этого нужно сформировать заголовок Range где-нибудь на REWRITE_PHASE. Это можно сделать lua (про ngscript не скажу) -- Regards, Eugene Mychlo MYC-RIPE EAMYC-RIPN From nginx-forum на forum.nginx.org Fri Mar 18 08:48:47 2016 From: nginx-forum на forum.nginx.org (vitcool) Date: Fri, 18 Mar 2016 04:48:47 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQv9C10YDQtdCw0LTRgNC10YHQsNGG?= =?UTF-8?B?0LjRjyDRgSAva29sZXNhL2luZGV4LnBocCDQvdCwIC9rb2xlc2Ev?= In-Reply-To: References: <63f3463ca87d8cb676fdd0948ddc8764.NginxMailingListRussian@forum.nginx.org> <5e4c2dc6d4bd025ee5cb3078629043e1.NginxMailingListRussian@forum.nginx.org> Message-ID: e.lodyanov Wrote: ------------------------------------------------------- > Таак. И как же это должно быть прописано? И где? как организована обработка запросов на сайте? пользователь набрал в браузере адрес http://[ваш домен]/moto какой скрипт получит этот запрос? в самом начале этого скрипта вы можете проверить заканчивается ли request uri слешом "/" или нет? вот в том месте и решайте Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265428,265458#msg-265458 From alex.hha на gmail.com Fri Mar 18 08:50:13 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Fri, 18 Mar 2016 10:50:13 +0200 Subject: http/2 + backend http/1.1 In-Reply-To: <56EBBDC5.8010407@nginx.com> References: <1578381458265429@web29g.yandex.ru> <20160318021043.GE12808@mdounin.ru> <2799901458289304@web13o.yandex.ru> <56EBBDC5.8010407@nginx.com> Message-ID: > Или есть какой-то специфичный вопрос? я так понял, что суть вопрос в том - когда опиум будет доступен для народа. Т.е. есть ли в планах передача функционала в community версию nginx 2016-03-18 10:35 GMT+02:00 Maxim Konovalov : > On 3/18/16 11:21 AM, Den Bozhok wrote: > > Понял, спасибо большое! > > А что насчёт директивы resolve? Есть ли какая-нибудь информация о > передаче её в массы? > > > Вы про опцию "resolve" директивы "server" в модулях *_upstream? > > Она включает периодический ре-ризолв имен, заданных в секции > upstream {}, используя настройки ризолвера в директиве resolver. > > Вроде бы у нас это задокументировано достаточно хорошо: > > http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server > nginx.org/r/resolver > > Доступна эта штука только в nginx-plus. > > Или есть какой-то специфичный вопрос? > > -- > Maxim Konovalov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Mar 18 08:53:55 2016 From: nginx-forum на forum.nginx.org (e.lodyanov) Date: Fri, 18 Mar 2016 04:53:55 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90LAg0LvQuCDQv9C10YDQtdCw0LTRgNC10YHQsNGG?= =?UTF-8?B?0LjRjyDRgSAva29sZXNhL2luZGV4LnBocCDQvdCwIC9rb2xlc2Ev?= In-Reply-To: References: <63f3463ca87d8cb676fdd0948ddc8764.NginxMailingListRussian@forum.nginx.org> <5e4c2dc6d4bd025ee5cb3078629043e1.NginxMailingListRussian@forum.nginx.org> Message-ID: <0960be1e75eabfb965eda7978449f7a7.NginxMailingListRussian@forum.nginx.org> Приблизительно понял, буду пробовать. Спасибо Вам и всем за ответы! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265428,265459#msg-265459 From maxim на nginx.com Fri Mar 18 08:55:47 2016 From: maxim на nginx.com (Maxim Konovalov) Date: Fri, 18 Mar 2016 11:55:47 +0300 Subject: http/2 + backend http/1.1 In-Reply-To: References: <1578381458265429@web29g.yandex.ru> <20160318021043.GE12808@mdounin.ru> <2799901458289304@web13o.yandex.ru> <56EBBDC5.8010407@nginx.com> Message-ID: <56EBC293.2000208@nginx.com> On 3/18/16 11:50 AM, Alex Domoradov wrote: >> Или есть какой-то специфичный вопрос? > > я так понял, что суть вопрос в том - когда опиум будет доступен для > народа. Т.е. есть ли в планах передача функционала в community > версию nginx > В краткосрочной перспективе таких планов не было. Честно говоря, лично я не видел какого-то существенного количества запросов на бэкпорт этой части из nginx-plus. Подумаем. -- Maxim Konovalov From simplebox66 на gmail.com Fri Mar 18 09:07:19 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 18 Mar 2016 12:07:19 +0300 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: Message-ID: Я подумывал о lua изначально, да только вот эта https://forum.nginx.org/read.php?21,265294,265310 рассылка всю охоту к lua отбила у меня. 18 марта 2016 г., 8:25 пользователь Илья Шипицин написал: > не так давно пробегал пример, как webdav подружить с lua, чудеса уровня > тех, про которые вы говорите > > https://forum.nginx.org/read.php?21,259941,259941 > > 16 марта 2016 г., 20:04 пользователь Иван Мишин > написал: > >> Добрый день! >> >> Вопрос следующий: >> Есть nginx 1.8.1, на нем настроен вебдав. Конфиг простой >> >>> server { >>> listen 80; >>> server_name testdav; >>> >>> access_log /var/log/nginx/testdav_access.log main; >>> error_log /var/log/nginx/testdav_error.log error; >>> location / { >>> root /tmp/ram/testdav; >>> open_file_cache off; >>> client_max_body_size 1000m; >>> dav_methods PUT; >>> dav_access user:rw group:r all:r; >>> create_full_put_path on; >>> } >> >> В случае когда nginx записывает файл в /tmp/ram/testdav и там кончается >> место, хочется сделать так чтобы nginx этот файл записал в другое место >> /tmp2/ram/testdav. >> Есть идеи как это реализовать? >> В случае нехватки места nginx отдает 500 ошибку. пробовал конфиг >> >>> server { >>> listen 80; >>> server_name testdav; >>> >>> access_log /var/log/nginx/testdav_access.log main; >>> error_log /var/log/nginx/testdav_error.log error; >>> >>> location / { >>> error_page 500 = @e500; >>> >>> root /tmp/ram/testdav; >>> open_file_cache off; >>> client_max_body_size 1000m; >>> >>> dav_methods PUT; >>> dav_access user:rw group:r all:r; >>> create_full_put_path on; >>> } >>> >>> location @e500 { >>> root /tmp2/ram/testdav; >>> open_file_cache off; >>> client_max_body_size 1000m; >>> dav_methods PUT; >>> dav_access user:rw group:r all:r; >>> create_full_put_path on; >>> } >>> } >> >> >> Но не работает, в логах: >> >>> 2016/03/16 17:40:20 [alert] 15872#0: *1 write() has written only 24576 >>> of 2338816 to /tmp/ram/testdav/tengine.tar.0000000002, client: 127.0.0.1, >>> server: testdav, request: "PUT /tengine.tar HTTP/1.1", host: "testdav" >>> 2016/03/16 17:40:20 [crit] 15872#0: *1 chmod() >>> "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or >>> directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar >>> HTTP/1.1", host: "testdav" >>> 2016/03/16 17:40:20 [crit] 15872#0: *1 unlink() >>> "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or >>> directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar >>> HTTP/1.1", host: "testdav" >> >> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alex.hha на gmail.com Fri Mar 18 09:25:10 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Fri, 18 Mar 2016 11:25:10 +0200 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: Message-ID: Если дружите с перлом, можете на нем 2016-03-18 11:07 GMT+02:00 Иван Мишин : > Я подумывал о lua изначально, да только вот эта > https://forum.nginx.org/read.php?21,265294,265310 рассылка всю охоту к > lua отбила у меня. > > > 18 марта 2016 г., 8:25 пользователь Илья Шипицин > написал: > > не так давно пробегал пример, как webdav подружить с lua, чудеса уровня >> тех, про которые вы говорите >> >> https://forum.nginx.org/read.php?21,259941,259941 >> >> 16 марта 2016 г., 20:04 пользователь Иван Мишин >> написал: >> >>> Добрый день! >>> >>> Вопрос следующий: >>> Есть nginx 1.8.1, на нем настроен вебдав. Конфиг простой >>> >>>> server { >>>> listen 80; >>>> server_name testdav; >>>> >>>> access_log /var/log/nginx/testdav_access.log main; >>>> error_log /var/log/nginx/testdav_error.log error; >>>> location / { >>>> root /tmp/ram/testdav; >>>> open_file_cache off; >>>> client_max_body_size 1000m; >>>> dav_methods PUT; >>>> dav_access user:rw group:r all:r; >>>> create_full_put_path on; >>>> } >>> >>> В случае когда nginx записывает файл в /tmp/ram/testdav и там кончается >>> место, хочется сделать так чтобы nginx этот файл записал в другое место >>> /tmp2/ram/testdav. >>> Есть идеи как это реализовать? >>> В случае нехватки места nginx отдает 500 ошибку. пробовал конфиг >>> >>>> server { >>>> listen 80; >>>> server_name testdav; >>>> >>>> access_log /var/log/nginx/testdav_access.log main; >>>> error_log /var/log/nginx/testdav_error.log error; >>>> >>>> location / { >>>> error_page 500 = @e500; >>>> >>>> root /tmp/ram/testdav; >>>> open_file_cache off; >>>> client_max_body_size 1000m; >>>> >>>> dav_methods PUT; >>>> dav_access user:rw group:r all:r; >>>> create_full_put_path on; >>>> } >>>> >>>> location @e500 { >>>> root /tmp2/ram/testdav; >>>> open_file_cache off; >>>> client_max_body_size 1000m; >>>> dav_methods PUT; >>>> dav_access user:rw group:r all:r; >>>> create_full_put_path on; >>>> } >>>> } >>> >>> >>> Но не работает, в логах: >>> >>>> 2016/03/16 17:40:20 [alert] 15872#0: *1 write() has written only 24576 >>>> of 2338816 to /tmp/ram/testdav/tengine.tar.0000000002, client: 127.0.0.1, >>>> server: testdav, request: "PUT /tengine.tar HTTP/1.1", host: "testdav" >>>> 2016/03/16 17:40:20 [crit] 15872#0: *1 chmod() >>>> "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or >>>> directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar >>>> HTTP/1.1", host: "testdav" >>>> 2016/03/16 17:40:20 [crit] 15872#0: *1 unlink() >>>> "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or >>>> directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar >>>> HTTP/1.1", host: "testdav" >>> >>> >>> >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From a.korostelev на ngenix.net Fri Mar 18 10:43:36 2016 From: a.korostelev на ngenix.net (Anatoliy Korostelevm, NGENIX) Date: Fri, 18 Mar 2016 13:43:36 +0300 Subject: mp4 pseudostreaming with proxy_pass and slice In-Reply-To: <7E507B91-2F06-4321-97F4-DCAC97CC8E65@cname.me> References: <56EBB3FE.4050502@ngenix.net> <7E507B91-2F06-4321-97F4-DCAC97CC8E65@cname.me> Message-ID: <56EBDBD8.50708@ngenix.net> Спасибо за развернутый ответ. > Однако передать range в аргументах все же можно. > Для этого нужно сформировать заголовок Range где-нибудь на REWRITE_PHASE. > Это можно сделать lua (про ngscript не скажу) Правильно ли я понимаю, что я с помощью lua должен преобразовать входящий аргумент начало видео (скажемhttp://mynginx.server/test.mp4?start=40)в Range-запрос к бэкенду? То есть необходимо получить с бэкенда метаданные mp4-файла (moov-atom) и с помощью moov-atom сконвертировать смещение start=40 в Range-запрос? -- С уважением, Коростелев Анатолий From simplebox66 на gmail.com Fri Mar 18 12:00:29 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 18 Mar 2016 15:00:29 +0300 Subject: =?UTF-8?B?ZXJyb3JfcGFnZSDQvdC1INGA0LDQsdC+0YLQsNC10YI=?= Message-ID: Подскажите почему не работает директива error_page? Конфиг вроде верный. > server { > listen 80; > server_name php-info.club; > access_log /var/log/nginx/php-info.club_access.log main; > error_log /var/log/nginx/php-info.club_error.log error; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > location / { > proxy_pass http://local; > error_page 404 /404e.html; > } > location = /404e.html { > return 444; > } > } ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From pluknet на nginx.com Fri Mar 18 12:06:07 2016 From: pluknet на nginx.com (Sergey Kandaurov) Date: Fri, 18 Mar 2016 15:06:07 +0300 Subject: =?UTF-8?B?UmU6IGVycm9yX3BhZ2Ug0L3QtSDRgNCw0LHQvtGC0LDQtdGC?= In-Reply-To: References: Message-ID: <91FCCF7E-442F-43DC-8A7C-B66C5D827796@nginx.com> On Mar 18, 2016, at 3:00 PM, Иван Мишин wrote: > Подскажите почему не работает директива error_page? Конфиг вроде верный. > server { > listen 80; > server_name php-info.club; > access_log /var/log/nginx/php-info.club_access.log main; > error_log /var/log/nginx/php-info.club_error.log error; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > location / { > proxy_pass http://local; > error_page 404 /404e.html; > } > location = /404e.html { > return 444; > } > } Попробуйте взглянуть в сторону proxy_intercept_errors. -- Sergey Kandaurov From simplebox66 на gmail.com Fri Mar 18 12:07:34 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 18 Mar 2016 15:07:34 +0300 Subject: =?UTF-8?B?UmU6IGVycm9yX3BhZ2Ug0L3QtSDRgNCw0LHQvtGC0LDQtdGC?= In-Reply-To: <91FCCF7E-442F-43DC-8A7C-B66C5D827796@nginx.com> References: <91FCCF7E-442F-43DC-8A7C-B66C5D827796@nginx.com> Message-ID: взглянул уже. Но это не мой случай. Самое интересное у меня в проде этих error_page крутится целое множество. А на тестовом стенде не работает и все тут. 2016-03-18 15:06 GMT+03:00 Sergey Kandaurov : > On Mar 18, 2016, at 3:00 PM, Иван Мишин wrote: > > Подскажите почему не работает директива error_page? Конфиг вроде верный. > > server { > > listen 80; > > server_name php-info.club; > > access_log /var/log/nginx/php-info.club_access.log main; > > error_log /var/log/nginx/php-info.club_error.log error; > > proxy_set_header Host $host; > > proxy_set_header X-Real-IP $remote_addr; > > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > > location / { > > proxy_pass http://local; > > error_page 404 /404e.html; > > } > > location = /404e.html { > > return 444; > > } > > } > > Попробуйте взглянуть в сторону proxy_intercept_errors. > > -- > Sergey Kandaurov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From pluknet на nginx.com Fri Mar 18 12:35:19 2016 From: pluknet на nginx.com (Sergey Kandaurov) Date: Fri, 18 Mar 2016 15:35:19 +0300 Subject: =?UTF-8?B?UmU6IGVycm9yX3BhZ2Ug0L3QtSDRgNCw0LHQvtGC0LDQtdGC?= In-Reply-To: References: <91FCCF7E-442F-43DC-8A7C-B66C5D827796@nginx.com> Message-ID: <68021425-63F1-488B-B3B5-46762E9B9D11@nginx.com> On Mar 18, 2016, at 3:07 PM, Иван Мишин wrote: > взглянул уже. Но это не мой случай. Самое интересное у меня в проде этих error_page крутится целое множество. А на тестовом стенде не работает и все тут. > Видимо, клиенту по прежнему уходит 404-й код (со всеми заголовками). : Кроме того, можно поменять код ответа на другой, : используя синтаксис вида “=ответ” См. http://nginx.org/r/error_page/ru. [..context lost to top posting] -- Sergey Kandaurov From simplebox66 на gmail.com Fri Mar 18 12:43:42 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 18 Mar 2016 15:43:42 +0300 Subject: =?UTF-8?B?UmU6IGVycm9yX3BhZ2Ug0L3QtSDRgNCw0LHQvtGC0LDQtdGC?= In-Reply-To: <68021425-63F1-488B-B3B5-46762E9B9D11@nginx.com> References: <91FCCF7E-442F-43DC-8A7C-B66C5D827796@nginx.com> <68021425-63F1-488B-B3B5-46762E9B9D11@nginx.com> Message-ID: Да пробовал я уже такой вариант. И даже такой пробовал > if ($status = 404) { > return 444; > } Не работает и все тут. 18 марта 2016 г., 15:35 пользователь Sergey Kandaurov написал: > On Mar 18, 2016, at 3:07 PM, Иван Мишин wrote: > > взглянул уже. Но это не мой случай. Самое интересное у меня в проде этих > error_page крутится целое множество. А на тестовом стенде не работает и все > тут. > > > > Видимо, клиенту по прежнему уходит 404-й код (со всеми заголовками). > > : Кроме того, можно поменять код ответа на другой, > : используя синтаксис вида “=ответ” > > См. http://nginx.org/r/error_page/ru. > > [..context lost to top posting] > > -- > Sergey Kandaurov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Mar 18 13:14:26 2016 From: nginx-forum на forum.nginx.org (dim1) Date: Fri, 18 Mar 2016 09:14:26 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIgLSDQsCDQv9C+0LzQvtC20LXRgiBW?= =?UTF-8?B?YXJuaXNoINC/0LXRgNC10LQgbmdpbng/?= In-Reply-To: <26a382eafb9021cc1b4d3c567d5ca8ab.NginxMailingListRussian@forum.nginx.org> References: <26a382eafb9021cc1b4d3c567d5ca8ab.NginxMailingListRussian@forum.nginx.org> Message-ID: Varnish кеширует в памяти. Поможет побороть зависание из-за торозов с дисками установка перед nginx - varnish? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265286,265460#msg-265460 From mdounin на mdounin.ru Fri Mar 18 14:10:01 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 18 Mar 2016 17:10:01 +0300 Subject: =?UTF-8?B?UmU6IHVwc3RyZWFtINC4IGtlZXAgYWxpdmUgKEFQSSwg0KHQuCk=?= In-Reply-To: <8ea7be9ada8f5966971aa861810b1808.NginxMailingListRussian@forum.nginx.org> References: <8ea7be9ada8f5966971aa861810b1808.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160318141001.GG12808@mdounin.ru> Hello! On Fri, Mar 18, 2016 at 02:30:47AM -0400, rba wrote: > Вводная : upstream создаю во время соединения от клиента в acces > handler. > Ограничение: помимо вытаскивания backend connection в location conf. > Вопрос : есть ли возможность передать соединение с бэкендом от > одного запроса к другому в рамках одного соединения keep alive от клиента? > > 1. Подскажите пример и куда глядеть. Глядеть в src/http/modules/ngx_http_upstream_keepalive_module.c. > 2. И от куда брать память(для ngx_peer_connection_t и т.д.) или r->pool > остаётся в какой-то мере жив и достаточен для этого? Нет, r->pool будет уничтожен по окончании исходного запроса клиента. Память для соединения с бекендом следует брать из пула соединения с бекендом же, а относящуюся к соединению с клиентом - из пула соединения с клиентом. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Fri Mar 18 14:25:47 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 18 Mar 2016 17:25:47 +0300 Subject: =?UTF-8?B?UmU6IGVycm9yX3BhZ2Ug0L3QtSDRgNCw0LHQvtGC0LDQtdGC?= In-Reply-To: References: <91FCCF7E-442F-43DC-8A7C-B66C5D827796@nginx.com> Message-ID: <20160318142547.GI12808@mdounin.ru> Hello! On Fri, Mar 18, 2016 at 03:07:34PM +0300, Иван Мишин wrote: > взглянул уже. Но это не мой случай. Самое интересное у меня в проде этих > error_page крутится целое множество. А на тестовом стенде не работает и все > тут. А как это может быть не ваш случай, если _все_ запросы у вас отправляются на бекенд? > > > location / { > > > proxy_pass http://local; > > > error_page 404 /404e.html; > > > } С такой конфигурацией сам nginx вернуть 404 не может, может только передать клиенту то, что сказал бекенд. И если флаг proxy_intercept_errors не включён - то и директива error_page смысла не имеет. -- Maxim Dounin http://nginx.org/ From simplebox66 на gmail.com Fri Mar 18 15:08:38 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 18 Mar 2016 18:08:38 +0300 Subject: =?UTF-8?B?UmU6IGVycm9yX3BhZ2Ug0L3QtSDRgNCw0LHQvtGC0LDQtdGC?= In-Reply-To: <20160318142547.GI12808@mdounin.ru> References: <91FCCF7E-442F-43DC-8A7C-B66C5D827796@nginx.com> <20160318142547.GI12808@mdounin.ru> Message-ID: как заставить nginx отдавать 444 самому? так: > > server { > listen 80; > server_name php-info.club; > access_log /var/log/nginx/php-info.club_access.log main; > error_log /var/log/nginx/php-info.club_error.log error; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > error_page 404 /404e.html; > location / { > proxy_pass http://local; > } > location = /404e.html { > return 444; > } > } 18 марта 2016 г., 17:25 пользователь Maxim Dounin написал: > Hello! > > On Fri, Mar 18, 2016 at 03:07:34PM +0300, Иван Мишин wrote: > > > взглянул уже. Но это не мой случай. Самое интересное у меня в проде этих > > error_page крутится целое множество. А на тестовом стенде не работает и > все > > тут. > > А как это может быть не ваш случай, если _все_ запросы у вас > отправляются на бекенд? > > > > > location / { > > > > proxy_pass http://local; > > > > error_page 404 /404e.html; > > > > } > > С такой конфигурацией сам nginx вернуть 404 не может, может только > передать клиенту то, что сказал бекенд. И если флаг > proxy_intercept_errors не включён - то и директива error_page > смысла не имеет. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Mar 18 15:15:47 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 18 Mar 2016 18:15:47 +0300 Subject: =?UTF-8?B?UmU6IGVycm9yX3BhZ2Ug0L3QtSDRgNCw0LHQvtGC0LDQtdGC?= In-Reply-To: References: <91FCCF7E-442F-43DC-8A7C-B66C5D827796@nginx.com> <20160318142547.GI12808@mdounin.ru> Message-ID: <20160318151547.GL12808@mdounin.ru> Hello! On Fri, Mar 18, 2016 at 06:08:38PM +0300, Иван Мишин wrote: > как заставить nginx отдавать 444 самому? так: Отдавать в каких случаях? Если всегда, то проще всего так: location / { return 444; } Если тогда, когда бекенд вернул 404 - то надо использовать proxy_intercept_errors, как вам и было сказано в первом же ответе. Как-то так: location / { proxy_pass http://backend; proxy_intercept_errors on; error_page 404 = /404.html; } location = /404.html { return 444; } Подробнее тут и по ссылкам: http://nginx.org/r/proxy_intercept_errors/ru -- Maxim Dounin http://nginx.org/ From vbart на nginx.com Fri Mar 18 15:15:51 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 18 Mar 2016 18:15:51 +0300 Subject: =?UTF-8?B?UmU6IGVycm9yX3BhZ2Ug0L3QtSDRgNCw0LHQvtGC0LDQtdGC?= In-Reply-To: References: <20160318142547.GI12808@mdounin.ru> Message-ID: <1895677.o2XV4NBsIi@vbart-workstation> On Friday 18 March 2016 18:08:38 Иван Мишин wrote: > как заставить nginx отдавать 444 самому? так: > > > > server { > > listen 80; > > server_name php-info.club; > > access_log /var/log/nginx/php-info.club_access.log main; > > error_log /var/log/nginx/php-info.club_error.log error; > > proxy_set_header Host $host; > > proxy_set_header X-Real-IP $remote_addr; > > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > > error_page 404 /404e.html; > > location / { > > proxy_pass http://local; > > } > > location = /404e.html { > > return 444; > > } > > } > > [..] Необходимо разрешить перехватывать 404 от бекенда. Это делается с помощью директивы: proxy_intercept_errors on; -- Валентин Бартенев From nginx-forum на forum.nginx.org Fri Mar 18 15:44:23 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Fri, 18 Mar 2016 11:44:23 -0400 Subject: Acept systemd.socket In-Reply-To: <26542743.oGgCdBpbxy@vbart-laptop> References: <26542743.oGgCdBpbxy@vbart-laptop> Message-ID: <7ea95874c9e45f59bdf5d3fee3a39984.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > Это довольно странное желание - чтобы машина, которая по сути ещё не > готова > к работе, частично делала вид, что она готова принимать трафик. Что > вы будете > делать если nginx так и не заработает через 700 мс, а балансировщик > уже > радостно нальет на неё трафик? > > Почему вы считаете, что эти 700 мс куда-то теряются, хотя тем временем > они > могли бы быть обслужены живой машиной за меньшее время? > > А сколько секунд теряется на биос и загрузку ядра? В чем разница? > > Т.н. HA обеспечивается вовсе не такими методами. Больше похоже на > способ > тщательно разложить самому себе грабли у входа. Вы правы, это желания появилось, после нашей реализации активаций бекендов по systemd.socket, мне это так понравилось что захотел все перевести на systemd.socket, Nginx в том числе, но согласен практического смысла в этом мало. Вот как выкручиваются те кому это действительно надо https://developer.atlassian.com/blog/2015/03/docker-systemd-socket-activation/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265330,265496#msg-265496 From undying-m на yandex.ru Fri Mar 18 18:44:31 2016 From: undying-m на yandex.ru (Den Bozhok) Date: Fri, 18 Mar 2016 21:44:31 +0300 Subject: http/2 + backend http/1.1 In-Reply-To: 158188936911436950 References: <1578381458265429@web29g.yandex.ru> <20160318021043.GE12808@mdounin.ru> <2799901458289304@web13o.yandex.ru> <56EBBDC5.8010407@nginx.com> <56EBC293.2000208@nginx.com> Message-ID: <6157561458326671@web17g.yandex.ru> Спасибо. Был бы очень благодарен за бэкпорт. Без этой директивы не всегда получается использовать модуль upstream, когда он очень нужен. Приходится решать костылями, а это не очень красиво. 18.03.2016, 11:54, "Maxim Konovalov" : > On 3/18/16 11:50 AM, Alex Domoradov wrote: > >>>  Или есть какой-то специфичный вопрос? >> >>  я так понял, что суть вопрос в том - когда опиум будет доступен для >>  народа. Т.е. есть ли в планах передача функционала в community >>  версию nginx > > В краткосрочной перспективе таких планов не было. Честно говоря, > лично я не видел какого-то существенного количества запросов на > бэкпорт этой части из nginx-plus. > > Подумаем. > > -- > Maxim Konovalov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From sytar.alex на gmail.com Fri Mar 18 19:37:38 2016 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Fri, 18 Mar 2016 22:37:38 +0300 Subject: Acept systemd.socket In-Reply-To: <7ea95874c9e45f59bdf5d3fee3a39984.NginxMailingListRussian@forum.nginx.org> References: <26542743.oGgCdBpbxy@vbart-laptop> <7ea95874c9e45f59bdf5d3fee3a39984.NginxMailingListRussian@forum.nginx.org> Message-ID: 18 марта 2016 г., 18:44 пользователь S.A.N написал: > > Вот как выкручиваются те кому это действительно надо > > https://developer.atlassian.com/blog/2015/03/docker-systemd-socket-activation/ Бу, так то докер - хост система уже поднята и есть кому держать очередь пакетов и обрабатывать ее. В случае если это bare-system - будет так как писали выше. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Mon Mar 21 03:25:50 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 21 Mar 2016 08:25:50 +0500 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIgLSDQsCDQv9C+0LzQvtC20LXRgiBW?= =?UTF-8?B?YXJuaXNoINC/0LXRgNC10LQgbmdpbng/?= In-Reply-To: References: <26a382eafb9021cc1b4d3c567d5ca8ab.NginxMailingListRussian@forum.nginx.org> Message-ID: на отдачу контента можно настроить, чтобы nginx кешировал в памяти http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_buffers или у вас POST-запросы ? 18 марта 2016 г., 18:14 пользователь dim1 написал: > Varnish кеширует в памяти. > Поможет побороть зависание из-за торозов с дисками установка перед nginx - > varnish? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,265286,265460#msg-265460 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Mon Mar 21 04:42:03 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 21 Mar 2016 09:42:03 +0500 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: Message-ID: модуль nginx-lua разрабатывается в CloudFlare, по некоторым оценкам через CloudFlare проксируется треть российских сайтов, модуль покрыт тестами (их почти 3000), понятно, что гарантий вам никто не даст и использование будет на ваш риск. 18 марта 2016 г., 14:07 пользователь Иван Мишин написал: > Я подумывал о lua изначально, да только вот эта > https://forum.nginx.org/read.php?21,265294,265310 рассылка всю охоту к > lua отбила у меня. > > > 18 марта 2016 г., 8:25 пользователь Илья Шипицин > написал: > > не так давно пробегал пример, как webdav подружить с lua, чудеса уровня >> тех, про которые вы говорите >> >> https://forum.nginx.org/read.php?21,259941,259941 >> >> 16 марта 2016 г., 20:04 пользователь Иван Мишин >> написал: >> >>> Добрый день! >>> >>> Вопрос следующий: >>> Есть nginx 1.8.1, на нем настроен вебдав. Конфиг простой >>> >>>> server { >>>> listen 80; >>>> server_name testdav; >>>> >>>> access_log /var/log/nginx/testdav_access.log main; >>>> error_log /var/log/nginx/testdav_error.log error; >>>> location / { >>>> root /tmp/ram/testdav; >>>> open_file_cache off; >>>> client_max_body_size 1000m; >>>> dav_methods PUT; >>>> dav_access user:rw group:r all:r; >>>> create_full_put_path on; >>>> } >>> >>> В случае когда nginx записывает файл в /tmp/ram/testdav и там кончается >>> место, хочется сделать так чтобы nginx этот файл записал в другое место >>> /tmp2/ram/testdav. >>> Есть идеи как это реализовать? >>> В случае нехватки места nginx отдает 500 ошибку. пробовал конфиг >>> >>>> server { >>>> listen 80; >>>> server_name testdav; >>>> >>>> access_log /var/log/nginx/testdav_access.log main; >>>> error_log /var/log/nginx/testdav_error.log error; >>>> >>>> location / { >>>> error_page 500 = @e500; >>>> >>>> root /tmp/ram/testdav; >>>> open_file_cache off; >>>> client_max_body_size 1000m; >>>> >>>> dav_methods PUT; >>>> dav_access user:rw group:r all:r; >>>> create_full_put_path on; >>>> } >>>> >>>> location @e500 { >>>> root /tmp2/ram/testdav; >>>> open_file_cache off; >>>> client_max_body_size 1000m; >>>> dav_methods PUT; >>>> dav_access user:rw group:r all:r; >>>> create_full_put_path on; >>>> } >>>> } >>> >>> >>> Но не работает, в логах: >>> >>>> 2016/03/16 17:40:20 [alert] 15872#0: *1 write() has written only 24576 >>>> of 2338816 to /tmp/ram/testdav/tengine.tar.0000000002, client: 127.0.0.1, >>>> server: testdav, request: "PUT /tengine.tar HTTP/1.1", host: "testdav" >>>> 2016/03/16 17:40:20 [crit] 15872#0: *1 chmod() >>>> "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or >>>> directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar >>>> HTTP/1.1", host: "testdav" >>>> 2016/03/16 17:40:20 [crit] 15872#0: *1 unlink() >>>> "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or >>>> directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar >>>> HTTP/1.1", host: "testdav" >>> >>> >>> >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sytar.alex на gmail.com Mon Mar 21 08:14:05 2016 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Mon, 21 Mar 2016 11:14:05 +0300 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: Message-ID: 21 марта 2016 г., 7:42 пользователь Илья Шипицин написал: > модуль nginx-lua разрабатывается в CloudFlare, по некоторым оценкам через > CloudFlare проксируется треть российских сайтов, модуль покрыт тестами (их > почти 3000), понятно, что гарантий вам никто не даст и использование будет > на ваш риск. > Илья откуда такая инфа? > > 18 марта 2016 г., 14:07 пользователь Иван Мишин > написал: > > Я подумывал о lua изначально, да только вот эта >> https://forum.nginx.org/read.php?21,265294,265310 рассылка всю охоту к >> lua отбила у меня. >> >> >> 18 марта 2016 г., 8:25 пользователь Илья Шипицин >> написал: >> >> не так давно пробегал пример, как webdav подружить с lua, чудеса уровня >>> тех, про которые вы говорите >>> >>> https://forum.nginx.org/read.php?21,259941,259941 >>> >>> 16 марта 2016 г., 20:04 пользователь Иван Мишин >>> написал: >>> >>>> Добрый день! >>>> >>>> Вопрос следующий: >>>> Есть nginx 1.8.1, на нем настроен вебдав. Конфиг простой >>>> >>>>> server { >>>>> listen 80; >>>>> server_name testdav; >>>>> >>>>> access_log /var/log/nginx/testdav_access.log main; >>>>> error_log /var/log/nginx/testdav_error.log error; >>>>> location / { >>>>> root /tmp/ram/testdav; >>>>> open_file_cache off; >>>>> client_max_body_size 1000m; >>>>> dav_methods PUT; >>>>> dav_access user:rw group:r all:r; >>>>> create_full_put_path on; >>>>> } >>>> >>>> В случае когда nginx записывает файл в /tmp/ram/testdav и там >>>> кончается место, хочется сделать так чтобы nginx этот файл записал в другое >>>> место /tmp2/ram/testdav. >>>> Есть идеи как это реализовать? >>>> В случае нехватки места nginx отдает 500 ошибку. пробовал конфиг >>>> >>>>> server { >>>>> listen 80; >>>>> server_name testdav; >>>>> >>>>> access_log /var/log/nginx/testdav_access.log main; >>>>> error_log /var/log/nginx/testdav_error.log error; >>>>> >>>>> location / { >>>>> error_page 500 = @e500; >>>>> >>>>> root /tmp/ram/testdav; >>>>> open_file_cache off; >>>>> client_max_body_size 1000m; >>>>> >>>>> dav_methods PUT; >>>>> dav_access user:rw group:r all:r; >>>>> create_full_put_path on; >>>>> } >>>>> >>>>> location @e500 { >>>>> root /tmp2/ram/testdav; >>>>> open_file_cache off; >>>>> client_max_body_size 1000m; >>>>> dav_methods PUT; >>>>> dav_access user:rw group:r all:r; >>>>> create_full_put_path on; >>>>> } >>>>> } >>>> >>>> >>>> Но не работает, в логах: >>>> >>>>> 2016/03/16 17:40:20 [alert] 15872#0: *1 write() has written only 24576 >>>>> of 2338816 to /tmp/ram/testdav/tengine.tar.0000000002, client: 127.0.0.1, >>>>> server: testdav, request: "PUT /tengine.tar HTTP/1.1", host: "testdav" >>>>> 2016/03/16 17:40:20 [crit] 15872#0: *1 chmod() >>>>> "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or >>>>> directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar >>>>> HTTP/1.1", host: "testdav" >>>>> 2016/03/16 17:40:20 [crit] 15872#0: *1 unlink() >>>>> "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or >>>>> directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar >>>>> HTTP/1.1", host: "testdav" >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> nginx-ru mailing list >>>> nginx-ru на nginx.org >>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>>> >>> >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From simplebox66 на gmail.com Mon Mar 21 08:23:36 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 21 Mar 2016 11:23:36 +0300 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: Message-ID: Погуглил на тему кто в проде юзает модуль луа, В подтверждение информации которую дал Илья есть пост в блоге cloudflare https://blog.cloudflare.com/pushing-nginx-to-its-limit-with-lua/ Вот еще 2gis неплохо на lua сел судя по всему https://habrahabr.ru/company/2gis/blog/199504/ 21 марта 2016 г., 11:14 пользователь Aleksandr Sytar написал: > > > 21 марта 2016 г., 7:42 пользователь Илья Шипицин > написал: > >> модуль nginx-lua разрабатывается в CloudFlare, по некоторым оценкам через >> CloudFlare проксируется треть российских сайтов, модуль покрыт тестами (их >> почти 3000), понятно, что гарантий вам никто не даст и использование будет >> на ваш риск. >> > > Илья откуда такая инфа? > > >> >> 18 марта 2016 г., 14:07 пользователь Иван Мишин >> написал: >> >> Я подумывал о lua изначально, да только вот эта >>> https://forum.nginx.org/read.php?21,265294,265310 рассылка всю охоту к >>> lua отбила у меня. >>> >>> >>> 18 марта 2016 г., 8:25 пользователь Илья Шипицин >>> написал: >>> >>> не так давно пробегал пример, как webdav подружить с lua, чудеса уровня >>>> тех, про которые вы говорите >>>> >>>> https://forum.nginx.org/read.php?21,259941,259941 >>>> >>>> 16 марта 2016 г., 20:04 пользователь Иван Мишин >>>> написал: >>>> >>>>> Добрый день! >>>>> >>>>> Вопрос следующий: >>>>> Есть nginx 1.8.1, на нем настроен вебдав. Конфиг простой >>>>> >>>>>> server { >>>>>> listen 80; >>>>>> server_name testdav; >>>>>> >>>>>> access_log /var/log/nginx/testdav_access.log main; >>>>>> error_log /var/log/nginx/testdav_error.log error; >>>>>> location / { >>>>>> root /tmp/ram/testdav; >>>>>> open_file_cache off; >>>>>> client_max_body_size 1000m; >>>>>> dav_methods PUT; >>>>>> dav_access user:rw group:r all:r; >>>>>> create_full_put_path on; >>>>>> } >>>>> >>>>> В случае когда nginx записывает файл в /tmp/ram/testdav и там >>>>> кончается место, хочется сделать так чтобы nginx этот файл записал в другое >>>>> место /tmp2/ram/testdav. >>>>> Есть идеи как это реализовать? >>>>> В случае нехватки места nginx отдает 500 ошибку. пробовал конфиг >>>>> >>>>>> server { >>>>>> listen 80; >>>>>> server_name testdav; >>>>>> >>>>>> access_log /var/log/nginx/testdav_access.log main; >>>>>> error_log /var/log/nginx/testdav_error.log error; >>>>>> >>>>>> location / { >>>>>> error_page 500 = @e500; >>>>>> >>>>>> root /tmp/ram/testdav; >>>>>> open_file_cache off; >>>>>> client_max_body_size 1000m; >>>>>> >>>>>> dav_methods PUT; >>>>>> dav_access user:rw group:r all:r; >>>>>> create_full_put_path on; >>>>>> } >>>>>> >>>>>> location @e500 { >>>>>> root /tmp2/ram/testdav; >>>>>> open_file_cache off; >>>>>> client_max_body_size 1000m; >>>>>> dav_methods PUT; >>>>>> dav_access user:rw group:r all:r; >>>>>> create_full_put_path on; >>>>>> } >>>>>> } >>>>> >>>>> >>>>> Но не работает, в логах: >>>>> >>>>>> 2016/03/16 17:40:20 [alert] 15872#0: *1 write() has written only >>>>>> 24576 of 2338816 to /tmp/ram/testdav/tengine.tar.0000000002, client: >>>>>> 127.0.0.1, server: testdav, request: "PUT /tengine.tar HTTP/1.1", host: >>>>>> "testdav" >>>>>> 2016/03/16 17:40:20 [crit] 15872#0: *1 chmod() >>>>>> "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or >>>>>> directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar >>>>>> HTTP/1.1", host: "testdav" >>>>>> 2016/03/16 17:40:20 [crit] 15872#0: *1 unlink() >>>>>> "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or >>>>>> directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar >>>>>> HTTP/1.1", host: "testdav" >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> nginx-ru mailing list >>>>> nginx-ru на nginx.org >>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>>>> >>>> >>>> >>>> _______________________________________________ >>>> nginx-ru mailing list >>>> nginx-ru на nginx.org >>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>>> >>> >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Mon Mar 21 08:33:18 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 21 Mar 2016 13:33:18 +0500 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: Message-ID: 1) насчет трети российских сайтов, мне почему-то так запомнилось, видимо, я неправильно понял вот эту новость https://geektimes.ru/post/270502/ (сами CloudFlare говорят про 2 миллиона доменов) 2) насчет количества тестов, инфа общедоступна https://github.com/openresty/lua-nginx-module/tree/master/t самое крупное внедрение, это, наверное, сам CloudFlare. у нас внедрение есть, в 2gis есть. проблем по части nginx-lua не помню ни разу относиться к этому явлению как к сомнительному качеству кода или нет, вопрос субъективный. но да, гарантий вам никто не даст, решение и риски за вами 21 марта 2016 г., 13:14 пользователь Aleksandr Sytar написал: > > > 21 марта 2016 г., 7:42 пользователь Илья Шипицин > написал: > >> модуль nginx-lua разрабатывается в CloudFlare, по некоторым оценкам через >> CloudFlare проксируется треть российских сайтов, модуль покрыт тестами (их >> почти 3000), понятно, что гарантий вам никто не даст и использование будет >> на ваш риск. >> > > Илья откуда такая инфа? > > >> >> 18 марта 2016 г., 14:07 пользователь Иван Мишин >> написал: >> >> Я подумывал о lua изначально, да только вот эта >>> https://forum.nginx.org/read.php?21,265294,265310 рассылка всю охоту к >>> lua отбила у меня. >>> >>> >>> 18 марта 2016 г., 8:25 пользователь Илья Шипицин >>> написал: >>> >>> не так давно пробегал пример, как webdav подружить с lua, чудеса уровня >>>> тех, про которые вы говорите >>>> >>>> https://forum.nginx.org/read.php?21,259941,259941 >>>> >>>> 16 марта 2016 г., 20:04 пользователь Иван Мишин >>>> написал: >>>> >>>>> Добрый день! >>>>> >>>>> Вопрос следующий: >>>>> Есть nginx 1.8.1, на нем настроен вебдав. Конфиг простой >>>>> >>>>>> server { >>>>>> listen 80; >>>>>> server_name testdav; >>>>>> >>>>>> access_log /var/log/nginx/testdav_access.log main; >>>>>> error_log /var/log/nginx/testdav_error.log error; >>>>>> location / { >>>>>> root /tmp/ram/testdav; >>>>>> open_file_cache off; >>>>>> client_max_body_size 1000m; >>>>>> dav_methods PUT; >>>>>> dav_access user:rw group:r all:r; >>>>>> create_full_put_path on; >>>>>> } >>>>> >>>>> В случае когда nginx записывает файл в /tmp/ram/testdav и там >>>>> кончается место, хочется сделать так чтобы nginx этот файл записал в другое >>>>> место /tmp2/ram/testdav. >>>>> Есть идеи как это реализовать? >>>>> В случае нехватки места nginx отдает 500 ошибку. пробовал конфиг >>>>> >>>>>> server { >>>>>> listen 80; >>>>>> server_name testdav; >>>>>> >>>>>> access_log /var/log/nginx/testdav_access.log main; >>>>>> error_log /var/log/nginx/testdav_error.log error; >>>>>> >>>>>> location / { >>>>>> error_page 500 = @e500; >>>>>> >>>>>> root /tmp/ram/testdav; >>>>>> open_file_cache off; >>>>>> client_max_body_size 1000m; >>>>>> >>>>>> dav_methods PUT; >>>>>> dav_access user:rw group:r all:r; >>>>>> create_full_put_path on; >>>>>> } >>>>>> >>>>>> location @e500 { >>>>>> root /tmp2/ram/testdav; >>>>>> open_file_cache off; >>>>>> client_max_body_size 1000m; >>>>>> dav_methods PUT; >>>>>> dav_access user:rw group:r all:r; >>>>>> create_full_put_path on; >>>>>> } >>>>>> } >>>>> >>>>> >>>>> Но не работает, в логах: >>>>> >>>>>> 2016/03/16 17:40:20 [alert] 15872#0: *1 write() has written only >>>>>> 24576 of 2338816 to /tmp/ram/testdav/tengine.tar.0000000002, client: >>>>>> 127.0.0.1, server: testdav, request: "PUT /tengine.tar HTTP/1.1", host: >>>>>> "testdav" >>>>>> 2016/03/16 17:40:20 [crit] 15872#0: *1 chmod() >>>>>> "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or >>>>>> directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar >>>>>> HTTP/1.1", host: "testdav" >>>>>> 2016/03/16 17:40:20 [crit] 15872#0: *1 unlink() >>>>>> "/var/cache/nginx/client_temp/0000000001" failed (2: No such file or >>>>>> directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar >>>>>> HTTP/1.1", host: "testdav" >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> nginx-ru mailing list >>>>> nginx-ru на nginx.org >>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>>>> >>>> >>>> >>>> _______________________________________________ >>>> nginx-ru mailing list >>>> nginx-ru на nginx.org >>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>>> >>> >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mva на mva.name Mon Mar 21 08:51:47 2016 From: mva на mva.name (=?koi8-r?B?7cnTwsHILfPPzM/X2KPXIPfBxMnN?=) Date: Mon, 21 Mar 2016 14:51:47 +0600 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: Message-ID: <398051458550307@web28m.yandex.ru> Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Mon Mar 21 10:35:05 2016 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 21 Mar 2016 12:35:05 +0200 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: Message-ID: <56EFCE59.9020602@csdoc.com> On 21.03.2016 10:33, Илья Шипицин wrote: > относиться к этому явлению как к сомнительному качеству кода или нет, > вопрос субъективный. но да, гарантий вам никто не даст, > решение и риски за вами Если купить NGINX Plus Extras Package - там внутри будет lua модуль. https://www.nginx.com/products/technical-specs/ Обещают как минимум "Assistance with Installation and Deployment". https://www.nginx.com/support/ -- Best regards, Gena From alex.hha на gmail.com Mon Mar 21 10:41:33 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Mon, 21 Mar 2016 12:41:33 +0200 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: <56EFCE59.9020602@csdoc.com> References: <56EFCE59.9020602@csdoc.com> Message-ID: Было бы круто, если бы можно было покупать отдельные модули, а не весь пакет целиком. Допустим мне надо только балансировка и lua, но при этом я должен купить весь пакет. 2 nginx а есть ли в планах введение какой то более гибкой системы подписки? Например возможность купить отдельные модули, учитывая что вы недавно сделали поддержку динамических модулей. 2016-03-21 12:35 GMT+02:00 Gena Makhomed : > On 21.03.2016 10:33, Илья Шипицин wrote: > > относиться к этому явлению как к сомнительному качеству кода или нет, >> вопрос субъективный. но да, гарантий вам никто не даст, >> решение и риски за вами >> > > Если купить NGINX Plus Extras Package - там внутри будет lua модуль. > https://www.nginx.com/products/technical-specs/ > > Обещают как минимум "Assistance with Installation and Deployment". > https://www.nginx.com/support/ > > -- > Best regards, > Gena > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From maxim на nginx.com Mon Mar 21 10:48:04 2016 From: maxim на nginx.com (Maxim Konovalov) Date: Mon, 21 Mar 2016 13:48:04 +0300 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: <56EFCE59.9020602@csdoc.com> Message-ID: <56EFD164.4060105@nginx.com> On 3/21/16 1:41 PM, Alex Domoradov wrote: > Было бы круто, если бы можно было покупать отдельные модули, а не > весь пакет целиком. Допустим мне надо только балансировка и lua, но > при этом я должен купить весь пакет. > > 2 nginx > а есть ли в планах введение какой то более гибкой системы подписки? > Например возможность купить отдельные модули, учитывая что вы > недавно сделали поддержку динамических модулей. > Пока нет таких планов. Лично я не уверен, что продажи и управление такими подписками получится реализовать без существенного оверхеда. Речь даже не про ИТ системы. -- Maxim Konovalov From nginx-forum на forum.nginx.org Mon Mar 21 11:29:11 2016 From: nginx-forum на forum.nginx.org (dim1) Date: Mon, 21 Mar 2016 07:29:11 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIgLSDQsCDQv9C+0LzQvtC20LXRgiBW?= =?UTF-8?B?YXJuaXNoINC/0LXRgNC10LQgbmdpbng/?= In-Reply-To: References: Message-ID: <984dbffe490b670424ed57db981a1685.NginxMailingListRussian@forum.nginx.org> у меня чистая статика, без бакэнда Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265286,265534#msg-265534 From chipitsine на gmail.com Mon Mar 21 11:58:22 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 21 Mar 2016 16:58:22 +0500 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQstC40YHQsNC10YIgLSDQsCDQv9C+0LzQvtC20LXRgiBW?= =?UTF-8?B?YXJuaXNoINC/0LXRgNC10LQgbmdpbng/?= In-Reply-To: <984dbffe490b670424ed57db981a1685.NginxMailingListRussian@forum.nginx.org> References: <984dbffe490b670424ed57db981a1685.NginxMailingListRussian@forum.nginx.org> Message-ID: статика находится на диске сервера, где запущен nginx ? или вы проксируете ? я не уточнил, мой совет помог бы в случае проксирования (на другой сервер) 2016-03-21 16:29 GMT+05:00 dim1 : > у меня чистая статика, без бакэнда > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,265286,265534#msg-265534 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Mon Mar 21 12:03:28 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 21 Mar 2016 17:03:28 +0500 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: <56EFCE59.9020602@csdoc.com> References: <56EFCE59.9020602@csdoc.com> Message-ID: я имел в виду, что на рассылку рассчитывать не приходится. в рассылке первым делом попросят воспроизвести проблему без сторонних модулей (это на самом деле круто, что для опенсорс продукта есть подобная поддержка, без шуток) ну и топикстартер начал обсуждение в этой рассылке, не в платном канале. 21 марта 2016 г., 15:35 пользователь Gena Makhomed написал: > On 21.03.2016 10:33, Илья Шипицин wrote: > > относиться к этому явлению как к сомнительному качеству кода или нет, >> вопрос субъективный. но да, гарантий вам никто не даст, >> решение и риски за вами >> > > Если купить NGINX Plus Extras Package - там внутри будет lua модуль. > https://www.nginx.com/products/technical-specs/ > > Обещают как минимум "Assistance with Installation and Deployment". > https://www.nginx.com/support/ > > -- > Best regards, > Gena > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From simplebox66 на gmail.com Mon Mar 21 12:09:19 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 21 Mar 2016 15:09:19 +0300 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: <56EFCE59.9020602@csdoc.com> Message-ID: > > Если купить NGINX Plus Extras Package - там внутри будет lua модуль. > https://www.nginx.com/products/technical-specs/ что-то я совсем запутался, в плюсе говорится о поддержке lua модуля, а в этой теме https://forum.nginx.org/read.php?21,265294,265310 Бартенев и Дунин говорят о кривости данного модуля. Как же он оказался в плюсе, если по словам людей из nginx, этот модуль якобы плохой? 21 марта 2016 г., 15:03 пользователь Илья Шипицин написал: > я имел в виду, что на рассылку рассчитывать не приходится. > > в рассылке первым делом попросят воспроизвести проблему без сторонних > модулей (это на самом деле круто, что для опенсорс продукта есть подобная > поддержка, без шуток) > > ну и топикстартер начал обсуждение в этой рассылке, не в платном канале. > > 21 марта 2016 г., 15:35 пользователь Gena Makhomed > написал: > > On 21.03.2016 10:33, Илья Шипицин wrote: >> >> относиться к этому явлению как к сомнительному качеству кода или нет, >>> вопрос субъективный. но да, гарантий вам никто не даст, >>> решение и риски за вами >>> >> >> Если купить NGINX Plus Extras Package - там внутри будет lua модуль. >> https://www.nginx.com/products/technical-specs/ >> >> Обещают как минимум "Assistance with Installation and Deployment". >> https://www.nginx.com/support/ >> >> -- >> Best regards, >> Gena >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From maxim на nginx.com Mon Mar 21 12:22:12 2016 From: maxim на nginx.com (Maxim Konovalov) Date: Mon, 21 Mar 2016 15:22:12 +0300 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: <56EFCE59.9020602@csdoc.com> Message-ID: <56EFE774.90402@nginx.com> On 3/21/16 3:09 PM, Иван Мишин wrote: > Если купить NGINX Plus Extras Package - там внутри будет lua модуль. > https://www.nginx.com/products/technical-specs/ > > что-то я совсем запутался, в плюсе говорится о поддержке lua > модуля, а в этой > теме https://forum.nginx.org/read.php?21,265294,265310 Бартенев и > Дунин говорят о кривости данного модуля. Как же он оказался в плюсе, > если по словам людей из nginx, этот модуль якобы плохой? > Валентин нигде не говорит, что он плохой. Он лишь сообщает очевидную истину, что доп. код несет в себе доп. риски. Максим Дунин пишет, что код далек от совершенства, что скорее всего соответствует действительности для бОльшей части кода, написанного человечеством за всю историю программирования. Оба выражают свое личное мнение (и я с ними тоже). Я вот лично запутался в теме -- какой вопрос обсуждается? -- Maxim Konovalov From simplebox66 на gmail.com Mon Mar 21 12:41:04 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 21 Mar 2016 15:41:04 +0300 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: <56EFE774.90402@nginx.com> References: <56EFCE59.9020602@csdoc.com> <56EFE774.90402@nginx.com> Message-ID: Максим пишет: > Lua - сторонний модуль. И я бы не рекомендовал использовать его > без нужды, качество кода там - сомнительное. При этом этот модуль с кодом сомнительного качества присутствует в плюсе nginx, то покупая nginx plus, клиент получает одну из компонент сомнительного качества. Я вижу это так. Да и если бы он был на столько сомнителен на сколько об этом заявляют Дунин и Бартенев, разве он попал бы в nginx plus? Я вот лично запутался в теме -- какой вопрос обсуждается? От вопроса отклонились, но он по прежнему актуален для меня. Повторюсь, в кратце: - есть nginx, есть вебдав - есть задача: при закачке файла в случае отсутствия места на storage1(/tmp/ram/testdav), nginx должен положить закачиваемый файл на storage2(/etc/nginx/next_stor) - при окончании места на storage1 во время загрузки файла по webdav, клиент получает ответ 500 - сделано перенаправление на другой location с другим root ссылающимся уже на storage2, в случае возникновения 500 (то есть в случае окончания места на storage1). - результат в логах следующий: > 2016/03/18 19:17:33 [alert] 32563#0: *19 write() > "/tmp/ram/testdav/tengine.tar.0000000012" failed (28: No space left on > device), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar > HTTP/1.1", host: "testdav" > 2016/03/18 19:17:33 [crit] 32563#0: *19 chmod() > "/var/cache/nginx/client_temp/0000000011" failed (2: No such file or > directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar > HTTP/1.1", host: "testdav" > 2016/03/18 19:17:33 [crit] 32563#0: *19 unlink() > "/var/cache/nginx/client_temp/0000000011" failed (2: No such file or > directory), client: 127.0.0.1, server: testdav, request: "PUT /tengine.tar > HTTP/1.1", host: "testdav" Есть рекомендации/идеи как реализовать? Если нужен мой конфиг, сообщите я скину. 21 марта 2016 г., 15:22 пользователь Maxim Konovalov написал: > On 3/21/16 3:09 PM, Иван Мишин wrote: > > Если купить NGINX Plus Extras Package - там внутри будет lua модуль. > > https://www.nginx.com/products/technical-specs/ > > > > что-то я совсем запутался, в плюсе говорится о поддержке lua > > модуля, а в этой > > теме https://forum.nginx.org/read.php?21,265294,265310 Бартенев и > > Дунин говорят о кривости данного модуля. Как же он оказался в плюсе, > > если по словам людей из nginx, этот модуль якобы плохой? > > > Валентин нигде не говорит, что он плохой. Он лишь сообщает очевидную > истину, что доп. код несет в себе доп. риски. > > Максим Дунин пишет, что код далек от совершенства, что скорее всего > соответствует действительности для бОльшей части кода, написанного > человечеством за всю историю программирования. > > Оба выражают свое личное мнение (и я с ними тоже). > > Я вот лично запутался в теме -- какой вопрос обсуждается? > > -- > Maxim Konovalov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From basil на vpm.net.ua Mon Mar 21 12:57:18 2016 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Mon, 21 Mar 2016 14:57:18 +0200 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: <56EFCE59.9020602@csdoc.com> <56EFE774.90402@nginx.com> Message-ID: > > От вопроса отклонились, но он по прежнему актуален для меня. Повторюсь, в > кратце: > - есть nginx, есть вебдав > - есть задача: при закачке файла в случае отсутствия места на > storage1(/tmp/ram/testdav), nginx должен положить закачиваемый файл на > storage2(/etc/nginx/next_stor) > - при окончании места на storage1 во время загрузки файла по webdav, > клиент получает ответ 500 > - сделано перенаправление на другой location с другим root ссылающимся уже > на storage2, в случае возникновения 500 (то есть в случае окончания места > на storage1). > данную логику проще реализовать на уровне приложения, ибо не понятно каким образом читать потом эти данные. Хранить индексы какие-то? качество построения системы вызывает очень большие сомнения, если не предусмотрели вопрос упора сверху еще проще использовать лвм, но тоже через какое-то время будет упор сверху ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From maxim на nginx.com Mon Mar 21 13:26:46 2016 From: maxim на nginx.com (Maxim Konovalov) Date: Mon, 21 Mar 2016 16:26:46 +0300 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: <56EFCE59.9020602@csdoc.com> <56EFE774.90402@nginx.com> Message-ID: <56EFF696.3060508@nginx.com> On 3/21/16 3:41 PM, Иван Мишин wrote: > Максим пишет: > > Lua - сторонний модуль. И я бы не рекомендовал использовать его > без нужды, качество кода там - сомнительное. > > При этом этот модуль с кодом сомнительного качества присутствует > в плюсе nginx, то покупая nginx plus, клиент получает одну из > компонент сомнительного качества. Я вижу это так. Да и если бы он > был на столько сомнителен на сколько об этом заявляют Дунин и > Бартенев, разве он попал бы в nginx plus? > [...] Чтобы продолжать эту дискуссию в каком-то более/менее конструктивном русле, нужно определиться с количественными, объективно измеряемыми параметрами этой сомнительности. Плюсовой поддержкой у нас занимается группа квалифицированных инженеров, которые постараются решить любые проблемы с нашим продуктом с заданным SLA. По уже почти трехлетнему опыту продажи этого бандла -- код lua и вокруг него пока не вызывал каких-то существенных проблем в этой части. Если вдруг возникнут -- будем пытаться решить сами, обратимся к автору, приложим максимум усилий. Поддержкой oss в этом и других листах/форумах тоже занимается значимая часть нашего коллектива. Понятно, что без какого-либо SLA. Ну еще раз пытаюсь донести мысль, что Валентин никаких утверждений про качество кода не делал. В качестве рекламной паузы: мы точно так же продаем поддержку на nginx-oss, если кому-то не нравится идея покупать nginx-plus. -- Maxim Konovalov From ano на bestmx.net Mon Mar 21 13:53:57 2016 From: ano на bestmx.net (Andrey Oktyabrskiy) Date: Mon, 21 Mar 2016 16:53:57 +0300 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: <56EFCE59.9020602@csdoc.com> <56EFE774.90402@nginx.com> Message-ID: <0723d88947151a3de218f4549d8664d7@bestmx.net> On 2016-03-21 15:41, Иван Мишин wrote: > От вопроса отклонились, но он по > прежнему актуален для меня. Повторюсь, > в кратце: > - есть nginx, есть вебдав > - есть задача: при закачке файла в > случае отсутствия места на > storage1(/tmp/ram/testdav), nginx должен положить > закачиваемый файл на storage2(/etc/nginx/next_stor) > - при окончании места на storage1 во время > загрузки файла по webdav, клиент получает > ответ 500 > - сделано перенаправление на другой > location с другим root ссылающимся уже на > storage2, в случае возникновения 500 (то > есть в случае окончания места на storage1). > - результат в логах следующий: > >> 2016/03/18 19:17:33 [alert] 32563#0: *19 write() >> "/tmp/ram/testdav/tengine.tar.0000000012" failed (28: No space left >> on device), client: 127.0.0.1, server: testdav, request: "PUT >> /tengine.tar HTTP/1.1", host: "testdav" >> 2016/03/18 19:17:33 [crit] 32563#0: *19 chmod() >> "/var/cache/nginx/client_temp/0000000011" failed (2: No such file or >> directory), client: 127.0.0.1, server: testdav, request: "PUT >> /tengine.tar HTTP/1.1", host: "testdav" >> 2016/03/18 19:17:33 [crit] 32563#0: *19 unlink() >> "/var/cache/nginx/client_temp/0000000011" failed (2: No such file or >> directory), client: 127.0.0.1, server: testdav, request: "PUT >> /tengine.tar HTTP/1.1", host: "testdav" > > Есть рекомендации/идеи как > реализовать? Если нужен мой конфиг, > сообщите я скину. Я бы это делал вообще на уровне мониторинга. storage1 заполнился на 95% - перегенерировали конфиг(и), перечитали, пишем на storage2. Освободили место на storage1, стал он заполнен на 90% - перегенерировали конфиг(и), перечитали, пишем снова на storage1. From bgx на protva.ru Mon Mar 21 14:09:18 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Mon, 21 Mar 2016 17:09:18 +0300 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: <0723d88947151a3de218f4549d8664d7@bestmx.net> References: <56EFCE59.9020602@csdoc.com> <56EFE774.90402@nginx.com> <0723d88947151a3de218f4549d8664d7@bestmx.net> Message-ID: <20160321140918.GA20885@cio.protva.ru> On Mon, Mar 21, 2016 at 04:53:57PM +0300, Andrey Oktyabrskiy wrote: > Я бы это делал вообще на уровне мониторинга. storage1 заполнился на 95% - > перегенерировали конфиг(и), перечитали, пишем на storage2. Освободили место > на storage1, стал он заполнен на 90% - перегенерировали конфиг(и), > перечитали, пишем снова на storage1. Проще поменять симлинк. :) Для атомарности через mv(1) aka rename(2). -- Eugene Berdnikov From ano на bestmx.net Mon Mar 21 14:19:50 2016 From: ano на bestmx.net (Andrey Oktyabrskiy) Date: Mon, 21 Mar 2016 17:19:50 +0300 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: <20160321140918.GA20885@cio.protva.ru> References: <56EFCE59.9020602@csdoc.com> <56EFE774.90402@nginx.com> <0723d88947151a3de218f4549d8664d7@bestmx.net> <20160321140918.GA20885@cio.protva.ru> Message-ID: On 2016-03-21 17:09, Evgeniy Berdnikov wrote: > On Mon, Mar 21, 2016 at 04:53:57PM +0300, Andrey Oktyabrskiy wrote: >> Я бы это делал вообще на уровне мониторинга. storage1 заполнился на >> 95% - >> перегенерировали конфиг(и), перечитали, пишем на storage2. Освободили >> место >> на storage1, стал он заполнен на 90% - перегенерировали конфиг(и), >> перечитали, пишем снова на storage1. > > Проще поменять симлинк. :) Для атомарности через mv(1) aka rename(2). Что кому проще, это уж каждый для себя решит. Суть в том, чтобы не доводить до переполнения. From basil на vpm.net.ua Mon Mar 21 14:39:29 2016 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Mon, 21 Mar 2016 16:39:29 +0200 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDQt9Cw0L/QuNGB0Ywg0YTQsNC50LvQsCDQv9C+INC00YDRg9Cz?= =?UTF-8?B?0L7QvNGDIHJvb3Qg0LIg0YHQu9GD0YfQsNC1INC10YHQu9C4INC30LDQutC+?= =?UTF-8?B?0L3Rh9C40LvQvtGB0Ywg0LzQtdGB0YLQvg==?= In-Reply-To: References: <56EFCE59.9020602@csdoc.com> <56EFE774.90402@nginx.com> <0723d88947151a3de218f4549d8664d7@bestmx.net> <20160321140918.GA20885@cio.protva.ru> Message-ID: > > Что кому проще, это уж каждый для себя решит. Суть в том, чтобы не >> доводить до переполнения. >> > Сначала придумываем трудности - а потом героически их преодолеваем ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From swood на fotofor.biz Tue Mar 22 22:37:22 2016 From: swood на fotofor.biz (Anton Kiryushkin) Date: Wed, 23 Mar 2016 01:37:22 +0300 Subject: nginx-1.9.12 & bytes module Message-ID: Добрый вечер. Попробовал переехать на одном из серверов на 1.9.12 и не получилось по весьма неожиданной причине. Дело в том, что там используется ngx_http_bytes_filter_module от Максима Дунина (кажется). Который вдруг стал себя не узнавать: nginx: [emerg] unknown directive "bytes" Хотя в конфиге как и прежде указано просто: bytes on; Не подскажете, что с этим можно сделать? Nginx, конечно же, собран с этим модулем. -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.hha на gmail.com Tue Mar 22 22:42:03 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Wed, 23 Mar 2016 00:42:03 +0200 Subject: nginx-1.9.12 & bytes module In-Reply-To: References: Message-ID: Вы его случайно не динамически собрали? Я про модуль 2016-03-23 0:37 GMT+02:00 Anton Kiryushkin : > Добрый вечер. > > Попробовал переехать на одном из серверов на 1.9.12 и не получилось по > весьма неожиданной причине. Дело в том, что там используется > ngx_http_bytes_filter_module от Максима Дунина (кажется). Который вдруг > стал себя не узнавать: > > nginx: [emerg] unknown directive "bytes" > > > Хотя в конфиге как и прежде указано просто: > > bytes on; > > > Не подскажете, что с этим можно сделать? Nginx, конечно же, собран с этим > модулем. > > -- > Best regards, > Anton Kiryushkin > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From swood на fotofor.biz Tue Mar 22 23:23:55 2016 From: swood на fotofor.biz (Anton Kiryushkin) Date: Wed, 23 Mar 2016 02:23:55 +0300 Subject: nginx-1.9.12 & bytes module In-Reply-To: References: Message-ID: Кажется, я сделал как всегда, add-module. А как я мог собрать его динамически и почему другие модули у меня собрались как надо? 23 марта 2016 г., 1:42 пользователь Alex Domoradov написал: > Вы его случайно не динамически собрали? Я про модуль > > 2016-03-23 0:37 GMT+02:00 Anton Kiryushkin : > >> Добрый вечер. >> >> Попробовал переехать на одном из серверов на 1.9.12 и не получилось по >> весьма неожиданной причине. Дело в том, что там используется >> ngx_http_bytes_filter_module от Максима Дунина (кажется). Который вдруг >> стал себя не узнавать: >> >> nginx: [emerg] unknown directive "bytes" >> >> >> Хотя в конфиге как и прежде указано просто: >> >> bytes on; >> >> >> Не подскажете, что с этим можно сделать? Nginx, конечно же, собран с этим >> модулем. >> >> -- >> Best regards, >> Anton Kiryushkin >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxim на nginx.com Wed Mar 23 07:55:26 2016 From: maxim на nginx.com (Maxim Konovalov) Date: Wed, 23 Mar 2016 10:55:26 +0300 Subject: nginx-1.9.12 & bytes module In-Reply-To: References: Message-ID: <56F24BEE.3030609@nginx.com> On 3/23/16 2:23 AM, Anton Kiryushkin wrote: > Кажется, я сделал как всегда, add-module. А как я мог собрать его > динамически и почему другие модули у меня собрались как надо? > Начните с nginx -V. > 23 марта 2016 г., 1:42 пользователь Alex Domoradov > > написал: > > Вы его случайно не динамически собрали? Я про модуль > > 2016-03-23 0:37 GMT+02:00 Anton Kiryushkin >: > > Добрый вечер. > > Попробовал переехать на одном из серверов на 1.9.12 и не > получилось по весьма неожиданной причине. Дело в том, что > там используется ngx_http_bytes_filter_module от Максима > Дунина (кажется). Который вдруг стал себя не узнавать: > > nginx: [emerg] unknown directive "bytes" > > > Хотя в конфиге как и прежде указано просто: > > bytes on; > > > Не подскажете, что с этим можно сделать? Nginx, конечно же, > собран с этим модулем. > > > -- > Best regards, > Anton Kiryushkin > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > -- > Best regards, > Anton Kiryushkin > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Maxim Konovalov From v.tolstov на selfip.ru Wed Mar 23 08:22:53 2016 From: v.tolstov на selfip.ru (Vasiliy Tolstov) Date: Wed, 23 Mar 2016 11:22:53 +0300 Subject: =?UTF-8?B?0YHQsdGA0L7RgdC40YLRjCDQutC10Ygg0YHQviDQstGB0LXRhSDRhNGA0L7QvdGC?= =?UTF-8?B?0LXQvdC00L7Qsg==?= Message-ID: Добрый день. Уверен, что многие уже реализовывали что-то подобное. Есть 4 фронтенда, при попадании определенного запроса на любой из фронтендов, нужно очистить кеш на всех остальных. Как это сделать с наименьшим количесвтом костылей и наиболее идеологически верно? Возможности сделать шаредную фс между всеми фронтендами - нет. Спасибо. -- Vasiliy Tolstov, e-mail: v.tolstov на selfip.ru From chipitsine на gmail.com Wed Mar 23 08:38:15 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 23 Mar 2016 13:38:15 +0500 Subject: =?UTF-8?B?UmU6INGB0LHRgNC+0YHQuNGC0Ywg0LrQtdGIINGB0L4g0LLRgdC10YUg0YTRgNC+?= =?UTF-8?B?0L3RgtC10L3QtNC+0LI=?= In-Reply-To: References: Message-ID: кешировать умеют в том числе браузеры. вы настроили принудительный кеш на nginx, с запретом кеширования в браузерах ? наиболее идеологически правильно - выбрать такой ключ кеширования, чтобы не приходилось сбрасывать кеш. 23 марта 2016 г., 13:22 пользователь Vasiliy Tolstov написал: > Добрый день. Уверен, что многие уже реализовывали что-то подобное. > Есть 4 фронтенда, при попадании определенного запроса на любой из > фронтендов, нужно очистить кеш на всех остальных. Как это сделать с > наименьшим количесвтом костылей и наиболее идеологически верно? > Возможности сделать шаредную фс между всеми фронтендами - нет. > Спасибо. > > -- > Vasiliy Tolstov, > e-mail: v.tolstov на selfip.ru > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From v.tolstov на selfip.ru Wed Mar 23 08:44:16 2016 From: v.tolstov на selfip.ru (Vasiliy Tolstov) Date: Wed, 23 Mar 2016 11:44:16 +0300 Subject: =?UTF-8?B?UmU6INGB0LHRgNC+0YHQuNGC0Ywg0LrQtdGIINGB0L4g0LLRgdC10YUg0YTRgNC+?= =?UTF-8?B?0L3RgtC10L3QtNC+0LI=?= In-Reply-To: References: Message-ID: 23 марта 2016 г., 11:38 пользователь Илья Шипицин написал: > кешировать умеют в том числе браузеры. > вы настроили принудительный кеш на nginx, с запретом кеширования в браузерах > ? > > наиболее идеологически правильно - выбрать такой ключ кеширования, чтобы не > приходилось сбрасывать кеш. У меня nginx стоит перед s3 совместимым бекендом. Собственно по урлу файл могут обновить, надо сбросить кеш. -- Vasiliy Tolstov, e-mail: v.tolstov на selfip.ru From swood на fotofor.biz Wed Mar 23 08:56:23 2016 From: swood на fotofor.biz (Anton Kiryushkin) Date: Wed, 23 Mar 2016 08:56:23 +0000 Subject: nginx-1.9.12 & bytes module In-Reply-To: <56F24BEE.3030609@nginx.com> References: <56F24BEE.3030609@nginx.com> Message-ID: Я так и сделал. Модуль есть. Ср, 23 марта 2016 г. в 10:54, Maxim Konovalov : > On 3/23/16 2:23 AM, Anton Kiryushkin wrote: > > Кажется, я сделал как всегда, add-module. А как я мог собрать его > > динамически и почему другие модули у меня собрались как надо? > > > Начните с nginx -V. > > > 23 марта 2016 г., 1:42 пользователь Alex Domoradov > > > написал: > > > > Вы его случайно не динамически собрали? Я про модуль > > > > 2016-03-23 0:37 GMT+02:00 Anton Kiryushkin > >: > > > > Добрый вечер. > > > > Попробовал переехать на одном из серверов на 1.9.12 и не > > получилось по весьма неожиданной причине. Дело в том, что > > там используется ngx_http_bytes_filter_module от Максима > > Дунина (кажется). Который вдруг стал себя не узнавать: > > > > nginx: [emerg] unknown directive "bytes" > > > > > > Хотя в конфиге как и прежде указано просто: > > > > bytes on; > > > > > > Не подскажете, что с этим можно сделать? Nginx, конечно же, > > собран с этим модулем. > > > > > > -- > > Best regards, > > Anton Kiryushkin > > > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > > -- > > Best regards, > > Anton Kiryushkin > > > > > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > -- > Maxim Konovalov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From mva на mva.name Wed Mar 23 09:32:24 2016 From: mva на mva.name (Vadim A. Misbakh-Soloviov) Date: Wed, 23 Mar 2016 15:32:24 +0600 Subject: nginx-1.9.12 & bytes module In-Reply-To: References: <56F24BEE.3030609@nginx.com> Message-ID: <3872177.xYXCTmAzpa@note> Скорее всего, Максим имел в виду "запостите сюда" :) ----------- следущая часть ----------- Вложение не в текстовом формате было извлечено… Имя: signature.asc Тип: application/pgp-signature Размер: 819 байтов Описание: This is a digitally signed message part. URL: From chipitsine на gmail.com Wed Mar 23 11:25:32 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 23 Mar 2016 16:25:32 +0500 Subject: =?UTF-8?B?UmU6INGB0LHRgNC+0YHQuNGC0Ywg0LrQtdGIINGB0L4g0LLRgdC10YUg0YTRgNC+?= =?UTF-8?B?0L3RgtC10L3QtNC+0LI=?= In-Reply-To: References: Message-ID: а в браузере ? 23 марта 2016 г., 13:44 пользователь Vasiliy Tolstov написал: > 23 марта 2016 г., 11:38 пользователь Илья Шипицин > написал: > > кешировать умеют в том числе браузеры. > > вы настроили принудительный кеш на nginx, с запретом кеширования в > браузерах > > ? > > > > наиболее идеологически правильно - выбрать такой ключ кеширования, чтобы > не > > приходилось сбрасывать кеш. > > > У меня nginx стоит перед s3 совместимым бекендом. Собственно по урлу > файл могут обновить, надо сбросить кеш. > > -- > Vasiliy Tolstov, > e-mail: v.tolstov на selfip.ru > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From v.tolstov на selfip.ru Wed Mar 23 11:41:00 2016 From: v.tolstov на selfip.ru (Vasiliy Tolstov) Date: Wed, 23 Mar 2016 14:41:00 +0300 Subject: =?UTF-8?B?UmU6INGB0LHRgNC+0YHQuNGC0Ywg0LrQtdGIINGB0L4g0LLRgdC10YUg0YTRgNC+?= =?UTF-8?B?0L3RgtC10L3QtNC+0LI=?= In-Reply-To: References: Message-ID: 23 марта 2016 г., 14:25 пользователь Илья Шипицин написал: > а в браузере ? В браузере пока не так важно, так как expire стоит небольшой и в общем-то расчет на большое число разных клиентов, а не на одного и того же человека. -- Vasiliy Tolstov, e-mail: v.tolstov на selfip.ru From mdounin на mdounin.ru Wed Mar 23 12:42:03 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 23 Mar 2016 15:42:03 +0300 Subject: nginx-1.9.12 & bytes module In-Reply-To: References: Message-ID: <20160323124203.GP37718@mdounin.ru> Hello! On Wed, Mar 23, 2016 at 01:37:22AM +0300, Anton Kiryushkin wrote: > Добрый вечер. > > Попробовал переехать на одном из серверов на 1.9.12 и не получилось по > весьма неожиданной причине. Дело в том, что там используется > ngx_http_bytes_filter_module от Максима Дунина (кажется). Который вдруг > стал себя не узнавать: > > nginx: [emerg] unknown directive "bytes" > > > Хотя в конфиге как и прежде указано просто: > > bytes on; > > > Не подскажете, что с этим можно сделать? Nginx, конечно же, собран с этим > модулем. Для сборки модуля с nginx 1.9.10+ нужен вот этот вот коммит: http://mdounin.ru/hg/ngx_http_bytes_filter_module/rev/b676808a49bc -- Maxim Dounin http://nginx.org/ From chipitsine на gmail.com Thu Mar 24 06:12:37 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 24 Mar 2016 11:12:37 +0500 Subject: =?UTF-8?B?UmU6INGB0LHRgNC+0YHQuNGC0Ywg0LrQtdGIINGB0L4g0LLRgdC10YUg0YTRgNC+?= =?UTF-8?B?0L3RgtC10L3QtNC+0LI=?= In-Reply-To: References: Message-ID: "proxy_cache_valid" с значением, идентичным тому, что вы отдаете в expire, не решит задачу ? 23 марта 2016 г., 16:41 пользователь Vasiliy Tolstov написал: > 23 марта 2016 г., 14:25 пользователь Илья Шипицин > написал: > > а в браузере ? > > > В браузере пока не так важно, так как expire стоит небольшой и в > общем-то расчет на большое число разных клиентов, а не на одного и > того же человека. > > -- > Vasiliy Tolstov, > e-mail: v.tolstov на selfip.ru > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From v.tolstov на selfip.ru Thu Mar 24 12:12:30 2016 From: v.tolstov на selfip.ru (Vasiliy Tolstov) Date: Thu, 24 Mar 2016 15:12:30 +0300 Subject: =?UTF-8?B?UmU6INGB0LHRgNC+0YHQuNGC0Ywg0LrQtdGIINGB0L4g0LLRgdC10YUg0YTRgNC+?= =?UTF-8?B?0L3RgtC10L3QtNC+0LI=?= In-Reply-To: References: Message-ID: 24 марта 2016 г., 9:12 пользователь Илья Шипицин написал: > proxy_cache_valid" с значением, идентичным тому, что вы отдаете в expire, не > решит задачу ? Не совсем, так как это никак не решает проблему с тем, что на сторадж по s3 загрузили данные. Мне нужно инвалидировать кеш в этом случае. И если инвалидировать с того сервера, на который пришел запрос легко, то вот как быть с другими не ясно. Первое что приходит в голову - lua =). Но мало ли... -- Vasiliy Tolstov, e-mail: v.tolstov на selfip.ru From chipitsine на gmail.com Thu Mar 24 12:58:51 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 24 Mar 2016 17:58:51 +0500 Subject: =?UTF-8?B?UmU6INGB0LHRgNC+0YHQuNGC0Ywg0LrQtdGIINGB0L4g0LLRgdC10YUg0YTRgNC+?= =?UTF-8?B?0L3RgtC10L3QtNC+0LI=?= In-Reply-To: References: Message-ID: кеш на nginx - это кеш на прокси-сервере, также есть клиентский кеш в браузере. судя по вашему утверждению, если браузер закеширует на то время, на которое вы разрешили - это допустимо (даже в случае, если в стораж загружен новый контент), однако то же самое предположение в отношение кеша на прокси недопустимо. почему ? 24 марта 2016 г., 17:12 пользователь Vasiliy Tolstov написал: > 24 марта 2016 г., 9:12 пользователь Илья Шипицин > написал: > > proxy_cache_valid" с значением, идентичным тому, что вы отдаете в > expire, не > > решит задачу ? > > > Не совсем, так как это никак не решает проблему с тем, что на сторадж > по s3 загрузили данные. Мне нужно инвалидировать кеш в этом случае. И > если инвалидировать с того сервера, на который пришел запрос легко, то > вот как быть с другими не ясно. Первое что приходит в голову - lua =). > Но мало ли... > > -- > Vasiliy Tolstov, > e-mail: v.tolstov на selfip.ru > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Mar 24 13:01:28 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 24 Mar 2016 18:01:28 +0500 Subject: =?UTF-8?B?UmU6INGB0LHRgNC+0YHQuNGC0Ywg0LrQtdGIINGB0L4g0LLRgdC10YUg0YTRgNC+?= =?UTF-8?B?0L3RgtC10L3QtNC+0LI=?= In-Reply-To: References: Message-ID: дело в чем, прокси сервер может быть в конкретный момент времени недоступен. а вы в это время хотите удалить файл. странная это штука, очищать кеш. много гемороя на ровном месте 24 марта 2016 г., 17:12 пользователь Vasiliy Tolstov написал: > 24 марта 2016 г., 9:12 пользователь Илья Шипицин > написал: > > proxy_cache_valid" с значением, идентичным тому, что вы отдаете в > expire, не > > решит задачу ? > > > Не совсем, так как это никак не решает проблему с тем, что на сторадж > по s3 загрузили данные. Мне нужно инвалидировать кеш в этом случае. И > если инвалидировать с того сервера, на который пришел запрос легко, то > вот как быть с другими не ясно. Первое что приходит в голову - lua =). > Но мало ли... > > -- > Vasiliy Tolstov, > e-mail: v.tolstov на selfip.ru > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Sun Mar 27 18:30:25 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 27 Mar 2016 23:30:25 +0500 Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LrQsCBpZG4t0LTQvtC80LXQvdC+0LI=?= In-Reply-To: <56E99845.5020500@mva.name> References: <56E99845.5020500@mva.name> Message-ID: Microsoft позволяет unicode в своих dns-серверах (к слову, символ подчеркивания они тоже разрешают). возможно, имело бы смысл проверять значение server_name на корректность с точки зрения днс, как вариант подстраховки от человеческого фактора среда, 16 марта 2016 г. пользователь Vadim A. Misbakh-Soloviov написал: > Вроде бы подобное в листе уже пробегало, но, что-то, я не смог найти в > своих архивах. > > В общем, я хотел бы спросить на счёт того, то товарищи разработчики > думают о том, чтобы добавить опциональную директиву при сборке для > линковки с libidn (ну, или не добавлять, а реимплементировать своими > силами) для того, чтобы получить поддержку idn-доменов в конфиге? > А то уж очень задалбывает конвертировать все IDN-домены перед > добавлением, а потом ещё конвертировать обратно чтобы вспомнить что это > за домен. > > В данный момент NginX не матерится на юникодные домены в конфиге, но и > не воспринимает их как IDN (нверное, ждёт запрос к юникодному). > При этом, на сколько я помню, ни одним стандартом такое нынче не > разрешено. Да и когда-то давно такое поддерживал то ли только wget, то > ли только curl. В любом случае, ни в DNS, ни в hosts, на сколько я > помню, юникодный домен не засунешь. Так что в таком виде эта фича > получается не к месту. В то время, как указывать IDN-домены без > конвертации было бы довольно удобно :) > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Mar 29 15:32:46 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 29 Mar 2016 18:32:46 +0300 Subject: nginx-1.9.13 Message-ID: <20160329153246.GP36620@mdounin.ru> Изменения в nginx 1.9.13 29.03.2016 *) Изменение: неидемпотентные запросы (POST, LOCK, PATCH) теперь по умолчанию не передаются на другой сервер, если запрос уже был отправлен на бэкенд; параметр non_idempotent директивы proxy_next_upstream явно разрешает повторять такие запросы. *) Добавление: модуль ngx_http_perl_module теперь можно собрать динамически. *) Добавление: поддержка UDP в модуле stream. *) Добавление: директива aio_write. *) Добавление: теперь cache manager следит за количеством элементов в кэше и старается не допускать переполнений зоны разделяемой памяти. *) Исправление: при использовании директив sendfile и aio с подзапросами в логах могли появляться сообщения "task already active" и "second aio post". *) Исправление: при использовании кэширования в логах могли появляться сообщения "zero size buf in output", если клиент закрывал соединение преждевременно. *) Исправление: при использовании кэширования соединения с клиентами могли закрываться без необходимости. Спасибо Justin Li. *) Исправление: nginx мог нагружать процессор при использовании директивы sendfile на Linux и Solaris, если отправляемый файл был изменён в процессе отправки. *) Исправление: при использовании директив sendfile и "aio threads" соединения могли зависать. *) Исправление: в директивах proxy_pass, fastcgi_pass, scgi_pass и uwsgi_pass при использовании переменных. Спасибо Piotr Sikora. *) Исправление: в модуле ngx_http_sub_filter_module. *) Исправление: если в закэшированном соединении к бэкенду происходила ошибка, запрос передавался на другой сервер без учёта директивы proxy_next_upstream. *) Исправление: ошибки "CreateFile() failed" при создании временных файлов на Windows. -- Maxim Dounin http://nginx.org/ From mva на mva.name Tue Mar 29 16:48:35 2016 From: mva на mva.name (Vadim A. Misbakh-Soloviov) Date: Tue, 29 Mar 2016 22:48:35 +0600 Subject: nginx-1.9.13 In-Reply-To: <20160329153246.GP36620@mdounin.ru> References: <20160329153246.GP36620@mdounin.ru> Message-ID: <8953922.GYoaWXo8SM@note> о, спасибо! А то я уже собирался спрашивать, не забыли ли про него :) ----------- следущая часть ----------- Вложение не в текстовом формате было извлечено… Имя: signature.asc Тип: application/pgp-signature Размер: 819 байтов Описание: This is a digitally signed message part. URL: From thresh на nginx.com Tue Mar 29 17:17:35 2016 From: thresh на nginx.com (Konstantin Pavlov) Date: Tue, 29 Mar 2016 20:17:35 +0300 Subject: =?UTF-8?B?UmU6INC/0LDQutC10YLRiyDRgSDQtNC40L3QsNC80LjRh9C10YHQutC40LzQuCA=?= =?UTF-8?B?0LzQvtC00YPQu9GP0LzQuCDQtNC70Y8g0YLQtdGB0YLQuNGA0L7QstCw0L0=?= =?UTF-8?B?0LjRjw==?= In-Reply-To: <5DD8B48A-A85C-46F1-B652-9676EDA4640F@nginx.com> References: <5DD8B48A-A85C-46F1-B652-9676EDA4640F@nginx.com> Message-ID: <56FAB8AF.50102@nginx.com> Здравствуйте, Мы только что опубликовали официальные пакеты для релиза 1.9.13, при этом были добавлены еще два пакета с динамическими модулями на всех поддерживаемых платформах: - perl, nginx-module-perl - njs, nginx-module-njs Хорошего дня, On 24/02/2016 22:08, Sergey Budnevitch wrote: > Добрый день. > > Раньше мы собирали nginx со всеми модулями, которые не требовали дополнительных > библиотек, чтобы не добавлять лишние зависимости. С динамическими модулями > можно вынести подобные модули в отдельные пакеты, таким образом дополнительные > зависимости будут только у тех пакетов, для которых они необходимы. > > Для версии 1.9.12 мы собрали пакеты с модулями xslt, image-filter и geoip. > Установить, например, image-filter можно на RHEL/CentOS командой: > > % yum install nginx-module-image-filter > > или на Ubuntu/Debian: > > % apt-get install nginx-module-image-filter > > затем для загрузки модуля необходимо добавить в nginx.conf директиву: > > load_module modules/ngx_http_image_filter_module.so; > > Пожалуйста, потестируйте новые пакеты с динамическими модулями и дайте знать > об ошибках, если таковые будут. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Konstantin Pavlov From nginx-forum на forum.nginx.org Tue Mar 29 23:45:13 2016 From: nginx-forum на forum.nginx.org (Maximus43) Date: Tue, 29 Mar 2016 19:45:13 -0400 Subject: =?UTF-8?B?SFRUUFMg0LPRgNGD0LfQuNGCINGC0L7Qu9GM0LrQviDQvtC00L3QviDRj9C00YA=?= =?UTF-8?B?0L4g0L/RgNC+0YbQtdGB0YHQvtGA0LA=?= Message-ID: <1b66892f5896e0500f9f393db486a6cc.NginxMailingListRussian@forum.nginx.org> Здравствуйте! Операционная система FreeBSD 10.2-RELEASE. Версия - nginx/1.9.12 Проблема в следующем: при тестировании http нагрузка распределяется по workers равномерно, производительность высокая. При тестировании https нагрузка идет на одно ядро системы, top выглядит вот так: last pid: 8458; load averages: 0.61, 0.25, 0.26 up 0+04:33:46 23:42:54 26 processes: 1 running, 25 sleeping CPU: 12.4% user, 0.0% nice, 0.1% system, 0.4% interrupt, 87.1% idle Mem: 138M Active, 1380M Inact, 623M Wired, 827M Buf, 5763M Free Swap: 764M Total, 764M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 8419 www 33 22 -5 948M 71348K uwait 3 2:13 99.37% nginx 7661 www 33 49 -5 928M 56440K uwait 0 1:31 0.00% nginx 1112 root 1 20 0 26152K 18072K select 5 0:02 0.00% ntpd 1166 root 1 27 0 61224K 7012K select 7 0:02 0.00% sshd 7653 root 1 43 0 932M 64412K pause 6 0:01 0.00% nginx 8416 www 33 23 -5 948M 71296K uwait 7 0:01 0.00% nginx 8417 www 33 22 -5 948M 71296K uwait 1 0:01 0.00% nginx 8418 www 33 23 -5 948M 71296K uwait 0 0:01 0.00% nginx 8415 www 33 23 -5 948M 71296K uwait 1 0:01 0.00% nginx 2731 maximus 1 20 0 86492K 7432K select 1 0:01 0.00% sshd 908 root 1 20 0 14512K 2092K select 5 0:01 0.00% syslogd 8414 www 33 23 -5 948M 71296K uwait 2 0:00 0.00% nginx 2735 root 1 20 0 17844K 3736K wait 4 0:00 0.00% bash 1169 root 1 20 0 24136K 5824K select 0 0:00 0.00% sendmail 8413 www 33 22 -5 948M 71296K uwait 3 0:00 0.00% nginx 8412 www 33 22 -5 948M 71296K uwait 2 0:00 0.00% nginx 8420 www 1 20 0 932M 64376K kqread 4 0:00 0.00% nginx 8458 root 1 20 0 21940K 3044K CPU5 5 0:00 0.00% top 1176 root 1 20 0 16612K 2344K nanslp 4 0:00 0.00% cron 2728 root 1 23 0 86492K 7428K select 7 0:00 0.00% sshd 2733 root 1 21 0 50368K 3528K select 0 0:00 0.00% sudo 1222 root 1 52 0 14508K 2084K ttyin 7 0:00 0.00% getty Результаты тестов http и https отличаются на два порядка.Куда копать? Заранее спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265719,265719#msg-265719 From mdounin на mdounin.ru Wed Mar 30 02:37:37 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 30 Mar 2016 05:37:37 +0300 Subject: =?UTF-8?B?UmU6IEhUVFBTINCz0YDRg9C30LjRgiDRgtC+0LvRjNC60L4g0L7QtNC90L4g0Y8=?= =?UTF-8?B?0LTRgNC+INC/0YDQvtGG0LXRgdGB0L7RgNCw?= In-Reply-To: <1b66892f5896e0500f9f393db486a6cc.NginxMailingListRussian@forum.nginx.org> References: <1b66892f5896e0500f9f393db486a6cc.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160330023737.GG36620@mdounin.ru> Hello! On Tue, Mar 29, 2016 at 07:45:13PM -0400, Maximus43 wrote: > Здравствуйте! > > Операционная система FreeBSD 10.2-RELEASE. > Версия - nginx/1.9.12 > > Проблема в следующем: > при тестировании http нагрузка распределяется по workers равномерно, > производительность высокая. При тестировании https нагрузка идет на одно > ядро системы, top выглядит вот так: > last pid: 8458; load averages: 0.61, 0.25, 0.26 > up 0+04:33:46 23:42:54 > 26 processes: 1 running, 25 sleeping > CPU: 12.4% user, 0.0% nice, 0.1% system, 0.4% interrupt, 87.1% idle > Mem: 138M Active, 1380M Inact, 623M Wired, 827M Buf, 5763M Free > Swap: 764M Total, 764M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 8419 www 33 22 -5 948M 71348K uwait 3 2:13 99.37% nginx > 7661 www 33 49 -5 928M 56440K uwait 0 1:31 0.00% nginx > 1112 root 1 20 0 26152K 18072K select 5 0:02 0.00% ntpd > 1166 root 1 27 0 61224K 7012K select 7 0:02 0.00% sshd > 7653 root 1 43 0 932M 64412K pause 6 0:01 0.00% nginx [...] > Результаты тестов http и https отличаются на два порядка.Куда копать? > Заранее спасибо! Наиболее затратная часть в https - это handshake, и упирается он в процессор. Сколько именно будет стоить handshake - зависит от используемых шифров. Типичные цифры - ~600 handshake'ов в секунду на ядро при использовании RSA 2048 бит. Если же взять ключи побольше или использовать в добавок обмен эфимерными ключами Diffie-Hellman'а, то можно и десятки handshake'ов в секунду получить. Так что два порядка разницы между http и https - это не странно ни разу. Основной метод борьбы с этим в реальной жизни - использование постоянных соединений и кеширование сессий, см. http://nginx.org/r/ssl_session_cache/ru. Кроме того, поведение nginx'а по умолчанию рассчитано на большое количество клиентов, и если ваши тесты не обеспечивают достаточного параллелизма - всё достаточно легко может уйти в один процесс. Особенно на FreeBSD, где nginx точно знает, сколько соединений ожидает в очереди, и может их все принять скопом - что обычно хорошо, но при микробенчмарках https - не очень, т.к. не позволяет полностью утилизировать все имеющиеся ядра процессора. Для микробенчмарков - стоит как минимум выключать accept_mutex, см. http://nginx.org/r/accept_mutex/ru. -- Maxim Dounin http://nginx.org/ From defan на nginx.com Wed Mar 30 03:36:29 2016 From: defan на nginx.com (Andrei Belov) Date: Wed, 30 Mar 2016 06:36:29 +0300 Subject: =?UTF-8?B?UmU6IEhUVFBTINCz0YDRg9C30LjRgiDRgtC+0LvRjNC60L4g0L7QtNC90L4g0Y8=?= =?UTF-8?B?0LTRgNC+INC/0YDQvtGG0LXRgdGB0L7RgNCw?= In-Reply-To: <1b66892f5896e0500f9f393db486a6cc.NginxMailingListRussian@forum.nginx.org> References: <1b66892f5896e0500f9f393db486a6cc.NginxMailingListRussian@forum.nginx.org> Message-ID: <4EF90483-4C5F-4259-8A15-4017EF51E8D9@nginx.com> > On 30 Mar 2016, at 02:45, Maximus43 wrote: > > Здравствуйте! > > Операционная система FreeBSD 10.2-RELEASE. > Версия - nginx/1.9.12 > > Проблема в следующем: > при тестировании http нагрузка распределяется по workers равномерно, > производительность высокая. При тестировании https нагрузка идет на одно > ядро системы, top выглядит вот так: > last pid: 8458; load averages: 0.61, 0.25, 0.26 > up 0+04:33:46 23:42:54 > 26 processes: 1 running, 25 sleeping > CPU: 12.4% user, 0.0% nice, 0.1% system, 0.4% interrupt, 87.1% idle > Mem: 138M Active, 1380M Inact, 623M Wired, 827M Buf, 5763M Free > Swap: 764M Total, 764M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 8419 www 33 22 -5 948M 71348K uwait 3 2:13 99.37% nginx > 7661 www 33 49 -5 928M 56440K uwait 0 1:31 0.00% nginx > 1112 root 1 20 0 26152K 18072K select 5 0:02 0.00% ntpd > 1166 root 1 27 0 61224K 7012K select 7 0:02 0.00% sshd > 7653 root 1 43 0 932M 64412K pause 6 0:01 0.00% nginx > 8416 www 33 23 -5 948M 71296K uwait 7 0:01 0.00% nginx > 8417 www 33 22 -5 948M 71296K uwait 1 0:01 0.00% nginx > 8418 www 33 23 -5 948M 71296K uwait 0 0:01 0.00% nginx > 8415 www 33 23 -5 948M 71296K uwait 1 0:01 0.00% nginx > 2731 maximus 1 20 0 86492K 7432K select 1 0:01 0.00% sshd > 908 root 1 20 0 14512K 2092K select 5 0:01 0.00% > syslogd > 8414 www 33 23 -5 948M 71296K uwait 2 0:00 0.00% nginx > 2735 root 1 20 0 17844K 3736K wait 4 0:00 0.00% bash > 1169 root 1 20 0 24136K 5824K select 0 0:00 0.00% > sendmail > 8413 www 33 22 -5 948M 71296K uwait 3 0:00 0.00% nginx > 8412 www 33 22 -5 948M 71296K uwait 2 0:00 0.00% nginx > 8420 www 1 20 0 932M 64376K kqread 4 0:00 0.00% nginx > 8458 root 1 20 0 21940K 3044K CPU5 5 0:00 0.00% top > 1176 root 1 20 0 16612K 2344K nanslp 4 0:00 0.00% cron > 2728 root 1 23 0 86492K 7428K select 7 0:00 0.00% sshd > 2733 root 1 21 0 50368K 3528K select 0 0:00 0.00% sudo > 1222 root 1 52 0 14508K 2084K ttyin 7 0:00 0.00% getty > > Результаты тестов http и https отличаются на два порядка.Куда копать? > Заранее спасибо! А чем тестируете и как? From aa.vasilenko на gmail.com Wed Mar 30 17:22:18 2016 From: aa.vasilenko на gmail.com (Alex Vasilenko) Date: Wed, 30 Mar 2016 17:22:18 +0000 Subject: =?UTF-8?Q?nginx_fastcgi=5Fcache_=D0=B8_Vary_headers?= Message-ID: Приветствую! Есть контент, который кэшируется директивами fastcgi_cache: > fastcgi_cache_path /var/cache/nginx/api_cache levels=1:2 keys_zone=api_cache:50m max_size=1000m inactive=600m; > fastcgi_cache api_cache; > fastcgi_cache_valid 200 1m; > fastcgi_cache_use_stale error timeout invalid_header updating; > fastcgi_cache_lock on; > fastcgi_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; Цель - кэшировать ответы в зависимости от языка в запросе Accept-Language Собственно ответ следующего вида: > HTTP/1.1 200 OK > Server: nginx > Date: Wed, 30 Mar 2016 17:13:01 GMT > Content-Type: application/json > Transfer-Encoding: chunked > Connection: close > Vary: Accept-Encoding > Cache-Control: max-age=3600, public > Expires: Wed, 30 Mar 2016 18:12:26 GMT > Vary: Accept-Language Насколько я понял из документации это должно позволить переопределять и время кэширования и fastcgi_cache_key будет немного другой и включит в себе хедеры в Vary. Но если б все было как предполагалось - я бы сюда не писал :). Собственно и Cache-Control и Vary заголовки игнорируются, кэшируется на минуту с первым попавшим языком. Что я не так делаю? nginx version: nginx/1.8.1 Спасибо! Александр ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From andrey на kopeyko.ru Wed Mar 30 18:41:59 2016 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Wed, 30 Mar 2016 21:41:59 +0300 (MSK) Subject: =?UTF-8?Q?Re=3A_nginx_fastcgi=5Fcache_=D0=B8_Vary_headers?= In-Reply-To: References: Message-ID: On Wed, 30 Mar 2016, Alex Vasilenko wrote: > Приветствую! Добрый вечер, Alex! > Есть контент, который кэшируется директивами fastcgi_cache: ... > Цель - кэшировать ответы в зависимости от языка в запросе Accept-Language > Собственно ответ следующего вида: ^^^^^ Вот тут у вас начинается недопонимание... > Насколько я понял из документации > > это > должно позволить переопределять и время кэширования и fastcgi_cache_key > будет немного другой и включит в себе хедеры в Vary. *_cache_key может включать в себя лишь заголовки запроса; вы же хотите добавить в него заголовок из ответа бэкенда. Так не получится ;-) > Собственно и Cache-Control и Vary > заголовки игнорируются, кэшируется на минуту с первым попавшим языком. Вот здесь вы близки к пониманию происходящего, и к решению. > Что я не так делаю? Вам надо добавить в fastcgi_cache_key заголовок "Accept-Language" из запроса, как-то так: fastcgi_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|http_accept_language|$request_uri"; Но будьте готовы к разрастанию кеша, потому что запросы к одному URI но с чуть разными заголовками Accept-Language="ru,ru-RU;q=0.7,en;q=0.3" и Accept-Language="ru;q=0.7,en;q=0.3" создадут 2 разных файла в кеше. -- Best regards, Andrey Kopeyko From mdounin на mdounin.ru Wed Mar 30 19:35:02 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 30 Mar 2016 22:35:02 +0300 Subject: =?UTF-8?Q?Re=3A_nginx_fastcgi=5Fcache_=D0=B8_Vary_headers?= In-Reply-To: References: Message-ID: <20160330193502.GV36620@mdounin.ru> Hello! On Wed, Mar 30, 2016 at 09:41:59PM +0300, Andrey Kopeyko wrote: > On Wed, 30 Mar 2016, Alex Vasilenko wrote: [...] > >Собственно и Cache-Control и Vary > >заголовки игнорируются, кэшируется на минуту с первым попавшим языком. > > Вот здесь вы близки к пониманию происходящего, и к решению. > > >Что я не так делаю? > > Вам надо добавить в fastcgi_cache_key заголовок "Accept-Language" из > запроса, как-то так: > > fastcgi_cache_key > "$request_method|$http_if_modified_since|$http_if_none_match|$host|http_accept_language|$request_uri"; > > Но будьте готовы к разрастанию кеша, потому что запросы к одному URI но с > чуть разными заголовками > Accept-Language="ru,ru-RU;q=0.7,en;q=0.3" > и > Accept-Language="ru;q=0.7,en;q=0.3" > > создадут 2 разных файла в кеше. Начиная с версии 1.7.7 nginx умеет сам смотреть на заголовок Vary, возвращаемый в ответе бекендом, и учитывать его при кешировании, при необходимости создавая для разных вариантов ресурса производные ключи и кеш-файлы, http://nginx.org/ru/CHANGES.ru: *) Изменение: теперь nginx учитывает при кэшировании строку "Vary" в заголовке ответа бэкенда. От разрастания кеша это, конечно, не спасёт, но должно работать само. (Чтобы кеш не разростался сверх необходимого - нужно знать логику выбора представления на бекенде, и повторить её в рамках создания ключа кеширования, других вариантов просто нет.) Судя по тому, что "и Cache-Control и Vary заголовки игнорируются" - проблему стоит искать где-то в районе конфига, там скорее всего кто-то написал fastcgi_ignore_headers как минимум со значениями Cache-Control, Expires и Vary. (Отдельно отмечу, что нескольких заголовков Vary в ответе - плохая идея, nginx использует последний из них. Но в данном случае проблема явно не в этом, т.к. Cache-Control также игнорируется.) -- Maxim Dounin http://nginx.org/ From aa.vasilenko на gmail.com Wed Mar 30 21:02:31 2016 From: aa.vasilenko на gmail.com (Alex Vasilenko) Date: Wed, 30 Mar 2016 21:02:31 +0000 Subject: =?UTF-8?Q?Re=3A_nginx_fastcgi=5Fcache_=D0=B8_Vary_headers?= In-Reply-To: <20160330193502.GV36620@mdounin.ru> References: <20160330193502.GV36620@mdounin.ru> Message-ID: Максим, Стыдно признать, но вы оказались полностью правы. Cache-Control с Expires был в fastcgi_ignore_headers. А Vary в ответе был еще один, который собственно перезатирал предыдущие. Как я могу указать несколько заголовков с Vary в таком случае? Vary: Accept-Language, X-Authentication (через запятую)? Будет ли Accept-Encoding автоматически добавлен нджинксом в ответ в Vary хедер в таком случае? Спасибо! Александр On Wed, Mar 30, 2016 at 9:35 PM Maxim Dounin wrote: > Hello! > > On Wed, Mar 30, 2016 at 09:41:59PM +0300, Andrey Kopeyko wrote: > > > On Wed, 30 Mar 2016, Alex Vasilenko wrote: > > [...] > > > >Собственно и Cache-Control и Vary > > >заголовки игнорируются, кэшируется на минуту с первым попавшим языком. > > > > Вот здесь вы близки к пониманию происходящего, и к решению. > > > > >Что я не так делаю? > > > > Вам надо добавить в fastcgi_cache_key заголовок "Accept-Language" из > > запроса, как-то так: > > > > fastcgi_cache_key > > > "$request_method|$http_if_modified_since|$http_if_none_match|$host|http_accept_language|$request_uri"; > > > > Но будьте готовы к разрастанию кеша, потому что запросы к одному URI но с > > чуть разными заголовками > > Accept-Language="ru,ru-RU;q=0.7,en;q=0.3" > > и > > Accept-Language="ru;q=0.7,en;q=0.3" > > > > создадут 2 разных файла в кеше. > > Начиная с версии 1.7.7 nginx умеет сам смотреть на заголовок Vary, > возвращаемый в ответе бекендом, и учитывать его при кешировании, > при необходимости создавая для разных вариантов ресурса > производные ключи и кеш-файлы, http://nginx.org/ru/CHANGES.ru: > > *) Изменение: теперь nginx учитывает при кэшировании строку "Vary" в > заголовке ответа бэкенда. > > От разрастания кеша это, конечно, не спасёт, но должно работать > само. (Чтобы кеш не разростался сверх необходимого - нужно знать > логику выбора представления на бекенде, и повторить её в рамках > создания ключа кеширования, других вариантов просто нет.) > > Судя по тому, что "и Cache-Control и Vary заголовки игнорируются" - > проблему стоит искать где-то в районе конфига, там скорее всего > кто-то написал fastcgi_ignore_headers как минимум со значениями > Cache-Control, Expires и Vary. > > (Отдельно отмечу, что нескольких заголовков Vary в ответе - > плохая идея, nginx использует последний из них. Но в данном > случае проблема явно не в этом, т.к. Cache-Control также > игнорируется.) > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bazilek на gmail.com Thu Mar 31 10:05:13 2016 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Thu, 31 Mar 2016 13:05:13 +0300 Subject: Без темы Message-ID: Коллеги, подскажите почему nginx может иногда отдавать 200 OK и 0 байт в ответе, случается для HIT, MISS, EXPIRED du -mk /var/lib/nginx/cache/x/d/07/9933b0653bece6387a95b7ad7d15007d 388 /var/lib/nginx/cache/x/d/07/9933b0653bece6387a95b7ad7d15007d head -n 10 /var/lib/nginx/cache/x/d/07/9933b0653bece6387a95b7ad7d15007d D V0 V4 Va "33fcea30-60630" KEY: http://x/hls/480p/1459415596925.ts HTTP/1.1 200 OK Server: nginx/1.8.0 Date: Thu, 31 Mar 2016 09:13:24 GMT Content-Type: video/mp2t Content-Length: 394800 Connection: close Last-Modified: Thu, 31 Mar 2016 09:13:20 GMT ETag: "33fcea30-60630" 2.61.162.132 - - [31/Mar/2016:09:13:37 +0000] "GET /hls/480p/1459415596925.ts HTTP/1.1" 200 0 "x" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2486.0 Safari/537.36 Edge/13.10586" "-" 0.000 - - - HIT 394800 где log_format combined_extra '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" "$http_x_forwarded_for" $request_time $upstream_header_time $upstream_response_time $upstream_response_length $upstream_cache_status $upstream_http_content_length'; Спасибо -- Best regards, Vasil Mikhalenya ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Mar 31 10:22:40 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 31 Mar 2016 15:22:40 +0500 Subject: [no subject] In-Reply-To: References: Message-ID: 304-й залип в кеше с пустым телом ? 2016-03-31 15:05 GMT+05:00 Vasil Mikhalenya : > Коллеги, подскажите почему nginx может иногда отдавать 200 OK и 0 байт в > ответе, > случается для HIT, MISS, EXPIRED > > du -mk /var/lib/nginx/cache/x/d/07/9933b0653bece6387a95b7ad7d15007d > 388 /var/lib/nginx/cache/x/d/07/9933b0653bece6387a95b7ad7d15007d > > head -n 10 /var/lib/nginx/cache/x/d/07/9933b0653bece6387a95b7ad7d15007d > D V0 V4 Va "33fcea30-60630" > KEY: http://x/hls/480p/1459415596925.ts > HTTP/1.1 200 OK > Server: nginx/1.8.0 > Date: Thu, 31 Mar 2016 09:13:24 GMT > Content-Type: video/mp2t > Content-Length: 394800 > Connection: close > Last-Modified: Thu, 31 Mar 2016 09:13:20 GMT > ETag: "33fcea30-60630" > > 2.61.162.132 - - [31/Mar/2016:09:13:37 +0000] "GET > /hls/480p/1459415596925.ts HTTP/1.1" 200 0 "x" "Mozilla/5.0 (Windows NT > 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2486.0 > Safari/537.36 Edge/13.10586" "-" 0.000 - - - HIT 394800 > > где log_format combined_extra '$remote_addr - $remote_user [$time_local] ' > > '"$request" $status $body_bytes_sent ' > > '"$http_referer" "$http_user_agent" "$http_x_forwarded_for" $request_time > $upstream_header_time $upstream_response_time $upstream_response_length > $upstream_cache_status $upstream_http_content_length'; > > Спасибо > > -- > Best regards, > Vasil Mikhalenya > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Mar 31 13:40:10 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 31 Mar 2016 16:40:10 +0300 Subject: your mail In-Reply-To: References: Message-ID: <20160331134010.GX36620@mdounin.ru> Hello! On Thu, Mar 31, 2016 at 01:05:13PM +0300, Vasil Mikhalenya wrote: > Коллеги, подскажите почему nginx может иногда отдавать 200 OK и 0 байт в > ответе, > случается для HIT, MISS, EXPIRED > > du -mk /var/lib/nginx/cache/x/d/07/9933b0653bece6387a95b7ad7d15007d > 388 /var/lib/nginx/cache/x/d/07/9933b0653bece6387a95b7ad7d15007d > > head -n 10 /var/lib/nginx/cache/x/d/07/9933b0653bece6387a95b7ad7d15007d > D V0 V4 Va "33fcea30-60630" > KEY: http://x/hls/480p/1459415596925.ts > HTTP/1.1 200 OK > Server: nginx/1.8.0 > Date: Thu, 31 Mar 2016 09:13:24 GMT > Content-Type: video/mp2t > Content-Length: 394800 > Connection: close > Last-Modified: Thu, 31 Mar 2016 09:13:20 GMT > ETag: "33fcea30-60630" > > 2.61.162.132 - - [31/Mar/2016:09:13:37 +0000] "GET > /hls/480p/1459415596925.ts HTTP/1.1" 200 0 "x" "Mozilla/5.0 (Windows NT > 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2486.0 > Safari/537.36 Edge/13.10586" "-" 0.000 - - - HIT 394800 > > где log_format combined_extra '$remote_addr - $remote_user [$time_local] ' > > '"$request" $status $body_bytes_sent ' > > '"$http_referer" "$http_user_agent" "$http_x_forwarded_for" $request_time > $upstream_header_time $upstream_response_time $upstream_response_length > $upstream_cache_status $upstream_http_content_length'; В $body_bytes_sent - количество байт, реально отправленное клиенту. Если клиент успел закрыть соединение до того, как nginx совершил первую попытку отправить что-то в ответ - там будет 0. При этом код ответа будет указан 200, если nginx успел сформировать заголовок ответа до того, как узнал, что клиент закрыл соединение. -- Maxim Dounin http://nginx.org/ From bazilek на gmail.com Thu Mar 31 14:53:55 2016 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Thu, 31 Mar 2016 17:53:55 +0300 Subject: nginx zero byte response from non-zero file in cache Message-ID: не понял, в кеше файл есть, ответ апстрима был HTTP/1.1 200 OK, размер 394800, он же на диске однако nginx иногда отдает 200 OK и ноль байт прошу, прощения за отсутствующий subject, поправил On Thu, Mar 31, 2016 at 1:22 PM, Илья Шипицин wrote: > 304-й залип в кеше с пустым телом ? > > 2016-03-31 15:05 GMT+05:00 Vasil Mikhalenya : > >> Коллеги, подскажите почему nginx может иногда отдавать 200 OK и 0 байт в >> ответе, >> случается для HIT, MISS, EXPIRED >> >> du -mk /var/lib/nginx/cache/x/d/07/9933b0653bece6387a95b7ad7d15007d >> 388 /var/lib/nginx/cache/x/d/07/9933b0653bece6387a95b7ad7d15007d >> >> head -n 10 /var/lib/nginx/cache/x/d/07/9933b0653bece6387a95b7ad7d15007d >> D V0 V4 Va "33fcea30-60630" >> KEY: http://x/hls/480p/1459415596925.ts >> HTTP/1.1 200 OK >> Server: nginx/1.8.0 >> Date: Thu, 31 Mar 2016 09:13:24 GMT >> Content-Type: video/mp2t >> Content-Length: 394800 >> Connection: close >> Last-Modified: Thu, 31 Mar 2016 09:13:20 GMT >> ETag: "33fcea30-60630" >> >> 2.61.162.132 - - [31/Mar/2016:09:13:37 +0000] "GET >> /hls/480p/1459415596925.ts HTTP/1.1" 200 0 "x" "Mozilla/5.0 (Windows NT >> 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2486.0 >> Safari/537.36 Edge/13.10586" "-" 0.000 - - - HIT 394800 >> >> где log_format combined_extra '$remote_addr - $remote_user [$time_local] >> ' >> >> '"$request" $status $body_bytes_sent ' >> >> '"$http_referer" "$http_user_agent" "$http_x_forwarded_for" $request_time >> $upstream_header_time $upstream_response_time $upstream_response_length >> $upstream_cache_status $upstream_http_content_length'; >> >> Спасибо >> >> -- >> Best regards, >> Vasil Mikhalenya >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Vasil Mikhalenya ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu Mar 31 15:45:33 2016 From: nginx-forum на forum.nginx.org (tepkuh) Date: Thu, 31 Mar 2016 11:45:33 -0400 Subject: reverse proxy + mysql + video Message-ID: Коллеги, Хочется странного ;) Собственно задача следующая: Есть база данных в моём случаи mysql. В ней хранятся видео файлы. Хочется чтобы nginx доставал эти файлы из БД, кэшировал их и передавал дальше клиенту. Просто достать данные из БД не проблема есть модуль nginx-mysql-module. Но как заставить закэшировать данные, и дать возможность перемотки видео в плеере не представляю. Подскажите куда копать, плиз Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265759,265759#msg-265759 From mdounin на mdounin.ru Thu Mar 31 15:50:34 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 31 Mar 2016 18:50:34 +0300 Subject: =?UTF-8?Q?Re=3A_nginx_fastcgi=5Fcache_=D0=B8_Vary_headers?= In-Reply-To: References: <20160330193502.GV36620@mdounin.ru> Message-ID: <20160331155033.GD36620@mdounin.ru> Hello! On Wed, Mar 30, 2016 at 09:02:31PM +0000, Alex Vasilenko wrote: > Максим, > > Стыдно признать, но вы оказались полностью правы. Cache-Control с Expires > был в fastcgi_ignore_headers. А Vary в ответе был еще один, который > собственно перезатирал предыдущие. > > Как я могу указать несколько заголовков с Vary в таком случае? Vary: > Accept-Language, X-Authentication (через запятую)? Да, в одном заголовке через запятую - это правильно. > Будет ли Accept-Encoding автоматически добавлен нджинксом в ответ в Vary > хедер в таком случае? По умолчанию nginx в Vary ничего не добавляет. Если там нужен Accept-Encoding - лучше его явно же и указать. Если же речь про gzip-фильтр и настройку gzip_vary, то она добавляет отдельный заголовок. Соответственно если это будет происходить на бекенде - будете наступать на ту же проблему с несколькими заголовками Vary. Впрочем, жать ответы на бекенде в зависимости от Accept-Encoding - в любом случае не очень хорошая идея, лучше их жать на фронтенде (либо же всегда жать на бекенде, а потом разжимать на фронтенде). -- Maxim Dounin http://nginx.org/ From bazilek на gmail.com Thu Mar 31 19:14:11 2016 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Thu, 31 Mar 2016 22:14:11 +0300 Subject: your mail In-Reply-To: <20160331134010.GX36620@mdounin.ru> References: <20160331134010.GX36620@mdounin.ru> Message-ID: не похоже что все так просто, на 1300K записей в access логе, 10K записей с 200 и 0 body_bytes_sent, из них 1K уникальных ip (соответственно клиентов) какие еще варианты возможны? спасибо 2016-03-31 16:40 GMT+03:00 Maxim Dounin : > Hello! > > On Thu, Mar 31, 2016 at 01:05:13PM +0300, Vasil Mikhalenya wrote: > > > Коллеги, подскажите почему nginx может иногда отдавать 200 OK и 0 байт в > > ответе, > > случается для HIT, MISS, EXPIRED > > > > du -mk /var/lib/nginx/cache/x/d/07/9933b0653bece6387a95b7ad7d15007d > > 388 /var/lib/nginx/cache/x/d/07/9933b0653bece6387a95b7ad7d15007d > > > > head -n 10 /var/lib/nginx/cache/x/d/07/9933b0653bece6387a95b7ad7d15007d > > D V0 V4 Va "33fcea30-60630" > > KEY: http://x/hls/480p/1459415596925.ts > > HTTP/1.1 200 OK > > Server: nginx/1.8.0 > > Date: Thu, 31 Mar 2016 09:13:24 GMT > > Content-Type: video/mp2t > > Content-Length: 394800 > > Connection: close > > Last-Modified: Thu, 31 Mar 2016 09:13:20 GMT > > ETag: "33fcea30-60630" > > > > 2.61.162.132 - - [31/Mar/2016:09:13:37 +0000] "GET > > /hls/480p/1459415596925.ts HTTP/1.1" 200 0 "x" "Mozilla/5.0 (Windows NT > > 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) > Chrome/46.0.2486.0 > > Safari/537.36 Edge/13.10586" "-" 0.000 - - - HIT 394800 > > > > где log_format combined_extra '$remote_addr - $remote_user [$time_local] > ' > > > > '"$request" $status $body_bytes_sent ' > > > > '"$http_referer" "$http_user_agent" "$http_x_forwarded_for" $request_time > > $upstream_header_time $upstream_response_time $upstream_response_length > > $upstream_cache_status $upstream_http_content_length'; > > В $body_bytes_sent - количество байт, реально отправленное > клиенту. Если клиент успел закрыть соединение до того, как nginx > совершил первую попытку отправить что-то в ответ - там будет 0. > При этом код ответа будет указан 200, если nginx успел > сформировать заголовок ответа до того, как узнал, что клиент > закрыл соединение. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Vasil Mikhalenya ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Mar 31 20:01:04 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 31 Mar 2016 23:01:04 +0300 Subject: your mail In-Reply-To: References: <20160331134010.GX36620@mdounin.ru> Message-ID: <20160331200104.GK36620@mdounin.ru> Hello! On Thu, Mar 31, 2016 at 10:14:11PM +0300, Vasil Mikhalenya wrote: > не похоже что все так просто, > > на 1300K записей в access логе, 10K записей с 200 и 0 body_bytes_sent, из > них 1K уникальных ip (соответственно клиентов) Т.е. чуть меньше, чем 1% запросов. В зависимости от конкретного вида нагрузки на сервер - это может быть вполне нормальным. Посмотрите error log на уровне info, там, скорее всего, будут соответствующие ошибки записи. > какие еще варианты возможны? Ещё возможно некорректное логгирование при использовании "aio threads; sendfile on;" на линуксе, если клиент закрывает соединение до того, как тред успел сообщить в основной процесс, сколько байт отправил sendfile(). Но вероятность такого события - на порядки меньше. -- Maxim Dounin http://nginx.org/ From bazilek на gmail.com Thu Mar 31 20:49:44 2016 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Thu, 31 Mar 2016 23:49:44 +0300 Subject: your mail In-Reply-To: <20160331200104.GK36620@mdounin.ru> References: <20160331134010.GX36620@mdounin.ru> <20160331200104.GK36620@mdounin.ru> Message-ID: aio threads не используется sendfile включен спасибо, будем искать корреляцию известны ли типичные причины такого поведения клиентов? 2016-03-31 23:01 GMT+03:00 Maxim Dounin : > Hello! > > On Thu, Mar 31, 2016 at 10:14:11PM +0300, Vasil Mikhalenya wrote: > > > не похоже что все так просто, > > > > на 1300K записей в access логе, 10K записей с 200 и 0 body_bytes_sent, из > > них 1K уникальных ip (соответственно клиентов) > > Т.е. чуть меньше, чем 1% запросов. В зависимости от конкретного > вида нагрузки на сервер - это может быть вполне нормальным. > Посмотрите error log на уровне info, там, скорее всего, будут > соответствующие ошибки записи. > > > какие еще варианты возможны? > > Ещё возможно некорректное логгирование при использовании "aio > threads; sendfile on;" на линуксе, если клиент закрывает > соединение до того, как тред успел сообщить в основной процесс, > сколько байт отправил sendfile(). Но вероятность такого события - > на порядки меньше. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Vasil Mikhalenya ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Mar 31 21:04:16 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 1 Apr 2016 00:04:16 +0300 Subject: your mail In-Reply-To: References: <20160331134010.GX36620@mdounin.ru> <20160331200104.GK36620@mdounin.ru> Message-ID: <20160331210415.GM36620@mdounin.ru> Hello! On Thu, Mar 31, 2016 at 11:49:44PM +0300, Vasil Mikhalenya wrote: > aio threads не используется > sendfile включен > > спасибо, будем искать корреляцию > > известны ли типичные причины такого поведения клиентов? Совсем типичный пример - когда пользователь не дожидается окончания загрузки страницы, и закрывает браузер и/или конкретное окно/вкладку в нём. В результате загрузка недогруженных ещё ресурсов - останавливается в непредсказуемых местах. Собственно, это вот этот вопрос из FAQ, вид сбоку: http://nginx.org/en/docs/faq/accept_failed.html -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Thu Mar 31 21:29:33 2016 From: nginx-forum на forum.nginx.org (Maximus43) Date: Thu, 31 Mar 2016 17:29:33 -0400 Subject: =?UTF-8?B?UmU6IEhUVFBTINCz0YDRg9C30LjRgiDRgtC+0LvRjNC60L4g0L7QtNC90L4g0Y8=?= =?UTF-8?B?0LTRgNC+INC/0YDQvtGG0LXRgdGB0L7RgNCw?= In-Reply-To: <4EF90483-4C5F-4259-8A15-4017EF51E8D9@nginx.com> References: <4EF90483-4C5F-4259-8A15-4017EF51E8D9@nginx.com> Message-ID: <713db3ee2130ff4b169804c5339703c9.NginxMailingListRussian@forum.nginx.org> > > Результаты тестов http и https отличаются на два порядка.Куда > копать? > > Заранее спасибо! > > А чем тестируете и как? Тестирую стандартно, с помощью Apache Benchmark (ab) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265719,265776#msg-265776 From nginx-forum на forum.nginx.org Thu Mar 31 21:31:19 2016 From: nginx-forum на forum.nginx.org (Maximus43) Date: Thu, 31 Mar 2016 17:31:19 -0400 Subject: =?UTF-8?B?UmU6IEhUVFBTINCz0YDRg9C30LjRgiDRgtC+0LvRjNC60L4g0L7QtNC90L4g0Y8=?= =?UTF-8?B?0LTRgNC+INC/0YDQvtGG0LXRgdGB0L7RgNCw?= In-Reply-To: <20160330023737.GG36620@mdounin.ru> References: <20160330023737.GG36620@mdounin.ru> Message-ID: <470ee61c07d87250e8d2527fe80dc867.NginxMailingListRussian@forum.nginx.org> Спасибо большое, Максим. Стало понятно, куда копать, сейчас результаты тестов оправдывают ожидания. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,265719,265777#msg-265777 From sejo412 на gmail.com Thu Mar 31 23:10:20 2016 From: sejo412 на gmail.com (Paul Sin) Date: Fri, 1 Apr 2016 02:10:20 +0300 Subject: reverse proxy + mysql + video In-Reply-To: References: Message-ID: копать вниз.. к центру Земли.. извините, не удержался ) >> Просто достать данные из БД не проблема есть модуль nginx-mysql-module. Но как заставить закэшировать данные, и дать возможность перемотки видео в плеере не представляю. а в чем проблема? откуда Вы берете видео - не принципиально 31 марта 2016 г., 18:45 пользователь tepkuh написал: > Коллеги, > Хочется странного ;) Собственно задача следующая: > Есть база данных в моём случаи mysql. В ней хранятся видео файлы. Хочется > чтобы nginx доставал эти файлы из БД, кэшировал их и передавал дальше > клиенту. Просто достать данные из БД не проблема есть модуль > nginx-mysql-module. Но как заставить закэшировать данные, и дать > возможность > перемотки видео в плеере не представляю. > > Подскажите куда копать, плиз > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,265759,265759#msg-265759 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- best reguards Paul Sin ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: