Re: модуль на заказ
Здравствуйте, Alexander. Попробуйте написать его сами на одном из встроенных в nginx языков: Javascript, Perl или Lua. > Скажите, пожалуйста, где можно заказать написание модуля? > Выполнялет ли такие заказы Nginx Inc.? -- С уважением, Михаил mailto:postmas...@softsearch.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Писать в лог доступ к определенным ссылкам
nginx.org/r/map/ru
000 0;
значит, что $confirm будет ноль, тогда когда значением строчки
$req_confirm$ref_confirm$uri_confirm будет 0, а во всех остальных случаях,
так как
default 1;
будет единица, что соотвествует логическому ИЛИ.
Вашей ошибкой было то, что map не принимает в качестве первого параметра
произвольную подстроку, лишь одну или более переменных. Ну и разделить
на отдельные map'ы получается понятнее и сложнее ошибиться в регэкспе.
В письме от 24 февраля 2016 01:22:57 пользователь IvanMiller написал:
> Да, мне надо ИЛИ. Ваш вариант сработал, буду тестировать.
> Дайте линк, откуда можно понять все про map.
> что значит 000 0 ? Почему так записывается ?
>
> Иван Wrote:
> ---
> > Попробуйте заменить
> > map $request:$http_referer:$uri $confirm {
> >
> > "~^/mail_confirm/:/mydomain-e.com/mail_confirm/:mail_confirm"
> >
> > 1;
> >
> > default 0;
> >
> > }
> >
> > сначала на
> >
> > map $request $req_confirm {
> >
> > ~/mail_confirm/ 1;
> > default 0;
> >
> > }
> > map $http_referer $ref_confirm {
> >
> > ~/mydomain-e.com/mail_confirm/ 1;
> > default 0;
> >
> > }
> > map $uri $uri_confirm {
> >
> > ~mail_confirm 1;
> > default 0;
> >
> > }
> >
> > далее, если Вам таки нужен И, то
> > map $req_confirm$ref_confirm$uri_confirm $confirm {
> >
> > 111 1;
> > default 0;
> >
> > }
> >
> > Если же хотите ИЛИ, то
> > map $req_confirm$ref_confirm$uri_confirm $confirm {
> >
> > default 1;
> > 000 0;
> >
> > }
> >
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Писать в лог доступ к определенным ссылкам
Да, мне надо ИЛИ. Ваш вариант сработал, буду тестировать.
Дайте линк, откуда можно понять все про map.
что значит 000 0 ? Почему так записывается ?
Иван Wrote:
---
> В письме от 21 февраля 2016 00:29:35 пользователь IvanMiller написал:
> > Любое совпадение.
> >
> > http {
> > map $request:$http_referer:$uri $confirm {
> >
> "~^/mail_confirm/:/mydomain-e.com/mail_confirm/:mail_confirm" 1;
> > default 0;
> >}
>
> Уточните, пожалуйста, ЛЮБОЕ совпадение подаразумевает ИЛИ, Вы же
> пишете
> конструкцию для И.
>
> То есть логи будут писаться, если
> $request ~ ^/mail_confirm/ И $http_referer ~
> /mydomain-e.com/mail_confirm/ И
> $uri ~ mail_confirm.
>
> Попробуйте заменить
> map $request:$http_referer:$uri $confirm {
> "~^/mail_confirm/:/mydomain-e.com/mail_confirm/:mail_confirm"
> 1;
> default 0;
> }
>
> сначала на
>
> map $request $req_confirm {
> ~/mail_confirm/ 1;
> default 0;
> }
> map $http_referer $ref_confirm {
> ~/mydomain-e.com/mail_confirm/ 1;
> default 0;
> }
> map $uri $uri_confirm {
> ~mail_confirm 1;
> default 0;
> }
>
> далее, если Вам таки нужен И, то
> map $req_confirm$ref_confirm$uri_confirm $confirm {
> 111 1;
> default 0;
> }
>
> Если же хотите ИЛИ, то
> map $req_confirm$ref_confirm$uri_confirm $confirm {
> default 1;
> 000 0;
> }
>
> >
> > server {
> >
>
> > if (!-e $request_filename) {
> > rewrite ^ /index.php last;
> > }
>
> Здесь и ниже if лучше заменить на
> try_files $uri /index.php
>
> > location /refac {
> > if (!-e $request_filename) {
> > rewrite ^ /refac/index.php last;
> > }
> > }
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,264614,264743#msg-264743
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SIGABRT в самописном модуле
Спасибо за ответ. Эх, не хотелось бы с перлом связываться, избыточен он для такой задачи. Посмотрю в сторону lua. Жаль, что nginScript еще не функциональный совсем. Базовых классов нет :( ~~~ wbr, Alexander Uskov - Исходное сообщение - > От: "Vadim A. Misbakh-Soloviov" > Кому: nginx-ru@nginx.org > Отправленные: Вторник, 23 Февраль 2016 г 23:56:38 > Тема: Re: SIGABRT в самописном модуле > > Прошу прощения, что отвечаю не на поставленный вопрос, но то, что вы > делали отдельным модулем — лично я бы делал скриптом в локейшне > используя Lua-модуль (ну, либо встроенный Perl, если кому-то > удобнее). > > А по теме — как помочь отладить "чтобы клиенты не жаловались", кроме > как > предложением поднять "зеркало", я думаю, не смогу не только я, но и > вообще никто. > > По поводу потенциальных мест, вызывающих double free/corruption — мне > кажется, что с большой вероятностью это одна из строк с вхождением > ".len" (Думаю, скорее всего, ошибка на единицу. В код, если честно, > не > вчитывался, да и не видя его целиком - бесполезное это занятие). > > > 22.02.2016 18:58, Alexander Uskov пишет: > > Нашел еще вылет. Сильно реже, но с подобной диагностикой вылетает > > по SIGSEGV. > > > > ~~~ > > wbr, Alexander Uskov > > > > - Пересланное сообщение - > > От: "Alexander Uskov" > > Кому: nginx-de...@nginx.org > > Отправленные: Понедельник, 22 Февраль 2016 г 12:22:57 > > Тема: SIGABRT в самописном модуле > > > > Добый день. > > > > Есть самописный модуль со следующей задачей: > > Поймать обращение у url, если есть определенный GET параметр, то > > отдать файл с диска, поменяв в нем %V на значение параметра, > > если нет, то попытаться прочесть значение куки, если нет и его, то > > сгенерить этот параметр и сделать постоянный редирект на > > ?параметр=значение. > > > > Модуль писал года 2 назад, сам в C сильно плаваю. > > Скомпилинное решение сейчас работает в продакшине. > > Попытался пересобрать всё на новой машине (пересборка того, что > > сейчас работает дала такие-же результаты), > > появилась проблемма: > > *** Error in `nginx: worker process': double free or corruption > > (!prev): 0x01ad6180 *** > > === Backtrace: = > > /lib64/libc.so.6(+0x7d023)[0x7f19765a8023] > > nginx: worker process(ngx_destroy_pool+0x6f)[0x412a7f] > > nginx: worker process(ngx_http_free_request+0x108)[0x38] > > nginx: worker process[0x444c49] > > nginx: worker process(ngx_http_core_content_phase+0x39)[0x440a29] > > nginx: worker process(ngx_http_core_run_phases+0x25)[0x43b2d5] > > nginx: worker process(ngx_http_process_request+0xa3)[0x446113] > > nginx: worker process[0x446976] > > nginx: worker process[0x431dd7] > > nginx: worker process(ngx_process_events_and_timers+0x53)[0x42a293] > > nginx: worker process[0x42fe41] > > nginx: worker process(ngx_spawn_process+0x164)[0x42e854] > > nginx: worker process[0x430014] > > nginx: worker process(ngx_master_process_cycle+0x1cb)[0x430adb] > > nginx: worker process(main+0x826)[0x4106d6] > > /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f197654cb15] > > nginx: worker process[0x4109f1] > > === Memory map: > > 0040-004b7000 r-xp 08:03 8257917 > >/usr/sbin/nginx > > 006b6000-006b7000 r--p 000b6000 08:03 8257917 > >/usr/sbin/nginx > > 006b7000-006ce000 rw-p 000b7000 08:03 8257917 > >/usr/sbin/nginx > > 006ce000-006dd000 rw-p 00:00 0 > > 01aa5000-01b8d000 rw-p 00:00 0 > > [heap] > > 01b8d000-01bcf000 rw-p 00:00 0 > > [heap] > > 7f196c00-7f196c021000 rw-p 00:00 0 > > 7f196c021000-7f197000 ---p 00:00 0 > > 7f19723db000-7f19723f r-xp 08:03 2097154 > >/usr/lib64/libgcc_s-4.8.5-20150702.so.1 > > ... > > 7f1977e61000-7f1977e62000 rw-p 00:00 0 > > 7ffcbba5a000-7ffcbba7b000 rw-p 00:00 0 > > [stack] > > 7ffcbbb24000-7ffcbbb26000 r-xp 00:00 0 > > [vdso] > > ff60-ff601000 r-xp 00:00 0 > > [vsyscall] > > 2016/02/22 12:34:43 [alert] 22924#0: worker process 22925 exited on > > signal 6 > > *** Error in `nginx: worker process': double free or corruption > > (!prev): 0x01b40cf0 *** > > > > Вылазит не на все запросы, а только под нагрузкой :( Поэтому > > дианностировать сильно сложно. > > > > Насколько смог отдиагностировать, проблема появляется именно в > > части, когда идет запрос без параметра. > > Т-е проблема где-то в следующем участке кода: > > > > // Проверяю, передано ли что в GET, передано ли GET['c'] и его > > длинну, если да, ни чего не делаю, иначе - редирект. > > if (r->args.len && > > ngx_http_arg(r, (u_char *) zero_js_config->get_parm.data, > > zero_js_config->get_parm.len, &get_c) == NGX_OK && > > get_c.len <=14 && > > get_c.len>
Злощасный try_files и alias
https://trac.nginx.org/nginx/ticket/97
подскажите, до сих пор нет решения этой проблемы?
Есть
server {
root /vhosts/api.example.net/public_html;
location ~ /api/2.0 {
alias /vhosts/api.example.net/api/v2.0/public_html;
try_files $uri $uri/ /index.php?$query_string;
}
}
при таком конфиге и обращении к /api/1.0 файлы ищутся в /vhosts/
api.example.net/public_html, вместо /vhosts/
api.example.net/api/v2.0/public_html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SIGABRT в самописном модуле
Прошу прощения, что отвечаю не на поставленный вопрос, но то, что вы
делали отдельным модулем — лично я бы делал скриптом в локейшне
используя Lua-модуль (ну, либо встроенный Perl, если кому-то удобнее).
А по теме — как помочь отладить "чтобы клиенты не жаловались", кроме как
предложением поднять "зеркало", я думаю, не смогу не только я, но и
вообще никто.
По поводу потенциальных мест, вызывающих double free/corruption — мне
кажется, что с большой вероятностью это одна из строк с вхождением
".len" (Думаю, скорее всего, ошибка на единицу. В код, если честно, не
вчитывался, да и не видя его целиком - бесполезное это занятие).
22.02.2016 18:58, Alexander Uskov пишет:
> Нашел еще вылет. Сильно реже, но с подобной диагностикой вылетает по SIGSEGV.
>
> ~~~
> wbr, Alexander Uskov
>
> - Пересланное сообщение -
> От: "Alexander Uskov"
> Кому: nginx-de...@nginx.org
> Отправленные: Понедельник, 22 Февраль 2016 г 12:22:57
> Тема: SIGABRT в самописном модуле
>
> Добый день.
>
> Есть самописный модуль со следующей задачей:
> Поймать обращение у url, если есть определенный GET параметр, то отдать файл
> с диска, поменяв в нем %V на значение параметра,
> если нет, то попытаться прочесть значение куки, если нет и его, то сгенерить
> этот параметр и сделать постоянный редирект на
> ?параметр=значение.
>
> Модуль писал года 2 назад, сам в C сильно плаваю.
> Скомпилинное решение сейчас работает в продакшине.
> Попытался пересобрать всё на новой машине (пересборка того, что сейчас
> работает дала такие-же результаты),
> появилась проблемма:
> *** Error in `nginx: worker process': double free or corruption (!prev):
> 0x01ad6180 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x7d023)[0x7f19765a8023]
> nginx: worker process(ngx_destroy_pool+0x6f)[0x412a7f]
> nginx: worker process(ngx_http_free_request+0x108)[0x38]
> nginx: worker process[0x444c49]
> nginx: worker process(ngx_http_core_content_phase+0x39)[0x440a29]
> nginx: worker process(ngx_http_core_run_phases+0x25)[0x43b2d5]
> nginx: worker process(ngx_http_process_request+0xa3)[0x446113]
> nginx: worker process[0x446976]
> nginx: worker process[0x431dd7]
> nginx: worker process(ngx_process_events_and_timers+0x53)[0x42a293]
> nginx: worker process[0x42fe41]
> nginx: worker process(ngx_spawn_process+0x164)[0x42e854]
> nginx: worker process[0x430014]
> nginx: worker process(ngx_master_process_cycle+0x1cb)[0x430adb]
> nginx: worker process(main+0x826)[0x4106d6]
> /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f197654cb15]
> nginx: worker process[0x4109f1]
> === Memory map:
> 0040-004b7000 r-xp 08:03 8257917
> /usr/sbin/nginx
> 006b6000-006b7000 r--p 000b6000 08:03 8257917
> /usr/sbin/nginx
> 006b7000-006ce000 rw-p 000b7000 08:03 8257917
> /usr/sbin/nginx
> 006ce000-006dd000 rw-p 00:00 0
> 01aa5000-01b8d000 rw-p 00:00 0
> [heap]
> 01b8d000-01bcf000 rw-p 00:00 0
> [heap]
> 7f196c00-7f196c021000 rw-p 00:00 0
> 7f196c021000-7f197000 ---p 00:00 0
> 7f19723db000-7f19723f r-xp 08:03 2097154
> /usr/lib64/libgcc_s-4.8.5-20150702.so.1
> ...
> 7f1977e61000-7f1977e62000 rw-p 00:00 0
> 7ffcbba5a000-7ffcbba7b000 rw-p 00:00 0
> [stack]
> 7ffcbbb24000-7ffcbbb26000 r-xp 00:00 0
> [vdso]
> ff60-ff601000 r-xp 00:00 0
> [vsyscall]
> 2016/02/22 12:34:43 [alert] 22924#0: worker process 22925 exited on signal 6
> *** Error in `nginx: worker process': double free or corruption (!prev):
> 0x01b40cf0 ***
>
> Вылазит не на все запросы, а только под нагрузкой :( Поэтому дианностировать
> сильно сложно.
>
> Насколько смог отдиагностировать, проблема появляется именно в части, когда
> идет запрос без параметра.
> Т-е проблема где-то в следующем участке кода:
>
> // Проверяю, передано ли что в GET, передано ли GET['c'] и его длинну, если
> да, ни чего не делаю, иначе - редирект.
> if (r->args.len &&
> ngx_http_arg(r, (u_char *) zero_js_config->get_parm.data,
> zero_js_config->get_parm.len, &get_c) == NGX_OK &&
> get_c.len <=14 &&
> get_c.len>10) {
>/* void() */
> } else {
> // Отдаем редирект с кукой в GET
>
> // Пытаемся найти COOKIE['client_cc']
> n = ngx_http_parse_multi_header_lines(&r->headers_in.cookies,
> &zero_js_config->cookie_name, &cookie);
>
> // Если кука есть и ее длинна <=14 заносим значение в uniqid иначе
> генерим php_uniqid()
> if (n != NGX_DECLINED && cookie.len<=14) {
> ngx_sprintf(uniqid, "%V", &cookie);
> } else {
> ngx_gettimeofday(&tv);
> sec = (int) tv.tv_sec;
> usec = (int) (tv.tv_usec % 0x10);
>
Re: модуль на заказ
Приветствую. On 2/23/16 11:33 AM, Alexander Uskov wrote: > Добрый день, > > Скажите, пожалуйста, где можно заказать написание модуля? Выполнялет ли такие > заказы Nginx Inc.? > Нет, не выполняем. -- Maxim Konovalov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: slice module + thread pools
23 февраля 2016 г., 11:22 пользователь Vadim Lazovskiy < vadim.lazovs...@gmail.com> написал: > Здравствуйте. > > Возникает проблема с отдачей данных из кэша при использовании связки slice > module + aio treads. > > Проблема 1 (aio выключено, slice включен): > Если запустить скачивание файла через прокси, прервать на середине, а > потом запустить заново, закешированная часть отдается медленно (5-8 > мегабайт/сек). Ежели докачать файл через прокси до конца, последующие > запросы к нему происходят на максимальной скорости (1Gbps в тесте). > > С чем может быть связана медленная отдача закешированных слайсов? > > Уточнение. Апстрим ограничивает скорость отдачи до 1Мбайт/сек. slice module вместо того чтобы быстро собрать имеющиеся в кэше слайсы и отправить их клиенту начинает запрашивать новые (отсутствующие?) у апстрима. Как раз в этот момент и проседает скорость отдачи имеющихся слайсов. -- WBR, Vadim Lazovskiy ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: slice module + thread pools
> > > Проблема 1 (aio выключено, slice включен): > Если запустить скачивание файла через прокси, прервать на середине, а > потом запустить заново, закешированная часть отдается медленно (5-8 > мегабайт/сек). Ежели докачать файл через прокси до конца, последующие > запросы к нему происходят на максимальной скорости (1Gbps в тесте). > > С чем может быть связана медленная отдача закешированных слайсов? > > Уточнение. Апстрим ограничивает скорость отдачи до 1Мбайт/сек. slice module вместо того чтобы быстро собрать имеющиеся в кэше слайсы и отправить их клиенту начинает запрашивать новые (отсутствующие?) у апстрима. Как раз в этот момент и проседает скорость отдачи имеющихся слайсов. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
модуль на заказ
Добрый день, Скажите, пожалуйста, где можно заказать написание модуля? Выполнялет ли такие заказы Nginx Inc.? ~~~ wbr, Alexander Uskov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
slice module + thread pools
Здравствуйте.
Возникает проблема с отдачей данных из кэша при использовании связки slice
module + aio treads.
Проблема 1 (aio выключено, slice включен):
Если запустить скачивание файла через прокси, прервать на середине, а потом
запустить заново, закешированная часть отдается медленно (5-8
мегабайт/сек). Ежели докачать файл через прокси до конца, последующие
запросы к нему происходят на максимальной скорости (1Gbps в тесте).
С чем может быть связана медленная отдача закешированных слайсов?
Проблема 2 (aio включено slice включен):
Если запустить скачивание файла через прокси, скорость очень низкая,
соединение постоянно разрывается. В логах при этом:
2016/02/23 10:36:11 [alert] 11124#11124: task #1 already active
2016/02/23 10:36:12 [alert] 11124#11124: task #4 already active
2016/02/23 10:36:14 [alert] 11124#11124: task #7 already active
2016/02/23 10:36:17 [alert] 11124#11124: task #10 already active
2016/02/23 10:37:59 [alert] 11124#11124: task #23 already active
2016/02/23 10:38:07 [alert] 11124#11124: task #35 already active
2016/02/23 10:38:17 [alert] 11124#11124: task #37 already active
Если отключить slice module, все становится хорошо.
С чем могут быть связаны данные проблемы?
Спасибо.
Конфиг:
thread_pool pool_ssd01 threads=16;
proxy_cache_path /disks/ssd01 levels=1:2 keys_zone=cache_ssd01:4m
use_temp_path=off inactive=7d max_size=230G;
split_clients $request_uri $disk {
100% ssd01;
}
location /streams/ {
location ~
^/streams/(?[^/]+)/(?.*)$ {
if ($allowed = 0) {
return 403;
}
slice 10m;
aio threads=pool_$disk;
proxy_pass http://
$upstream_hostname/$upstream_uri$is_args$args;
proxy_set_header Host $upstream_hostname;
proxy_set_header Range $slice_range;
proxy_ignore_client_abort on;
proxy_cache cache_$disk;
proxy_cache_key
$upstream_hostname$upstream_uri$slice_range;
proxy_cache_revalidate on;
proxy_cache_bypass $arg_start;
proxy_no_cache $arg_start;
proxy_cache_lock on;
proxy_cache_lock_age 60s;
proxy_cache_use_stale error timeout invalid_header
updating http_500 http_502 http_503 http_504 http_403;
}
}
# uname -a
Linux localhost.localdomain 3.16.0-4-amd64 #1 SMP Debian
3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux
# /usr/sbin/nginx -V
nginx version: nginx/1.9.11
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
--modules-path=%{_libdir}/nginx/modules --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-threads --with-stream
--with-stream_ssl_module --with-http_slice_module --with-mail
--with-mail_ssl_module --with-file-aio --with-http_v2_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
--
WBR,
Vadim Lazovskiy
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
