Quantcast
Channel: Nginx Forum - Nginx Mailing List - Russian
Viewing all 3102 articles
Browse latest View live
↧

Проконсультируйте по отдаче больших файлов. (no replies)

November 16, 2013, 9:08 am
$
0
0
Зачада такая: Имеется мощный сервер (FreeBsd 9.2, 8 ядер проц, 32гб памяти, 24х2тб винты, порт 1гбит/с), необходимо раздавать с него видеофайлы размером 50-500МБ
Проблема в том, что не получается заставить nginx отдавать больше 500Мбит/с, после рестарта он какое-то время отдает под 800, но потом скорость отдачи проседает и всё.
Конфиг nginx

worker_processes auto;
timer_resolution 100ms;
worker_rlimit_nofile 204800;
worker_priority -5;

events {
use kqueue;
worker_connections 8192;
}


http {
include mime.types;
default_type application/octet-stream;

sendfile off;
aio on;
etag off;

access_log off;
log_not_found off;
directio off;
expires max;
proxy_buffering off;

server {..........}
}

Настройки /etc/sysctl.conf

kern.ipc.nmbjumbop=192000
kern.ipc.nmbclusters=400000
kern.ipc.maxsockbuf=83886080
kern.ipc.maxsockets=204800
net.inet.tcp.maxtcptw=163840
kern.maxfiles=204800
kern.ipc.somaxconn=4096
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
sysctl kern.ipc.shmall=67108864
kern.ipc.shmall=67108864
net.inet.tcp.rfc3465=0
net.route.netisr_maxqlen=4096
kern.ipc.maxsockbuf=83886080
net.inet.tcp.recvbuf_inc=524288
net.inet.tcp.recvbuf_max=16777216
net.inet.tcp.sendbuf_inc=524288
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.sendspace=65536

Винчестеры не заняты.
Есть какие-нибудь идеи?
↧
Search

Не работает простое условие на фильтрацию относительного пути (no replies)

November 24, 2013, 3:38 am
$
0
0
Здравствуйте! Атакуют сетевые сканеры, до передачи запроса в Apache в конфигурации Nginx/1.4.2 прописано простое условие:

if ($uri !~ ^/) { return 400; }

Большая часть запросов отсеивается, но некоторые почему-то пропускает. Запросы, насколько понимаю, направлены на использование Nginx в качестве удаленного прокси-сервера. В журналах Apache наблюдаюся записи типа GET http://www.yahoo.com/ HTTP/1.1" 302 206.

Собственно вопрос, почему некоторые из таких запросов проходят такое простое условие фильтрации?
↧
↧

Re: вопрос по fastcgi_store (no replies)

November 26, 2013, 8:39 am
$
0
0
Hello!

On Tue, Nov 26, 2013 at 03:54:48PM +0200, Eugeny Zadevalov wrote:

> Здравствуйте,
>
> Есть конфигурация один в один как в примере http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_store
>
> Из документации не ясно, можно ли заставить nginx не сохранять ответ
> бекенда в файл в каких то случаях?
>
> Допустим, если бекенд возвращает заголовок какой-то, или если статус
> ответа скажем 404 или ещё как нибудь?

Строго говоря - штатного способа нет. Если сохранение ответов
включено, то ответы всегда сохраняются.

Хак - вернуть "X-Accel-Buffering: no", при небуферизированном
проксировании ответы не сохраняются. Для fastcgi это будет
работать в nginx 1.5.6+ (в более ранних версиях отсутствует
возможность небуферизированной работы с fastcgi-бекендами, см.
http://nginx.org/r/fastcgi_buffering).

--
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Re: Затыки при отдаче статики (6 replies)

November 26, 2013, 8:39 am
$
0
0
On 23.11.2013 14:32, Gelun, Artem wrote:

> ... чтение из tmpfs (считай, RAM) "застевает" в произвольные моменты
> времени по непонятным причинам.

причины могут быть разные. например, 1 - машина уходит в swap,
и на самом деле тогда "чтение из tmpfs" будет чтением с диска.
2 - если из tmpfs файлы считывает тот же nginx, который отдает
и файлы с диска. на дисковых операциях worker`ы nginx блокируюся,
поэтому и чтение из tmpfs тоже происходит с задержками и медленно.
3 - используется nginx с "левыми" модулями, которые и дают такие глюки.
4 - используется древняя версия nginx из EPEL, а не Pre-Built Packages
для CentOS/RHEL из официального сайта http://nginx.org/en/download.html
подробнее - см. пост http://habrahabr.ru/post/195742/#comment_6797402
5 - и т.д. и т.п.

On 23.11.2013 13:11, Gelun, Artem wrote:

>> Для HDD nginx и ОС нужно настраивать так чтобы nginx читал с диска
>> как можно бОльшими в пределах разумного кусками, 512к-2048к например.

в некоторых случаях nginx сможет отдавать файлы быстрее, если выключить
sendfile и правильно настроить output_buffers (есть в архиве рассылки)

еще для отдачи больших файлов может помочь включение режима aio,
вот первая статья на эту тему: http://habrahabr.ru/post/68480/

чтобы уменьшить количество операций ввода/вывода - имеет смысл
для access_log включить buffer, например, размером в 1 мегабайт,
или вообще отключить access_log - "access_log off;".

все диски и разделы имеет смысл монтировать с опцией noatime.
в некоторых случаях может помочь использование XFS вместо ext4.

> Насколько я понимаю, sendfile (который включен и должен отрабатывать)
> не блокирует worker'а.

блокирует. чтобы worker не блокировался - надо включать aio,
http://nginx.org/en/docs/http/ngx_http_core_module.html#aio

> Единственное подозрение - воркеры блокируются при
> открытии файла с "перегруженного" HDD. Но:
> 1) как это проверить?

с помощью http://nginx.org/ru/docs/debugging_log.html
указав debug_connection только для своего IP-адреса.

> 3) Если я правильно понимаю, при размере файла < размера буфера сокета и
> если sendfile_max_chunk не установлен, то sendfile должен вызываться
> один раз. Соответсвенно, если затык в nginx, то он будет перед началом
> отдачи данных.

о том, что происходит когда включен sendfile и не установлен
параметр sendfile_max_chunk - написано в документации к nginx.

если выставить очень большой буфер сокета, - при 700-1000 rps
не знаю как поведет себя операционная система в такой ситуации.

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

уязвимость к Slowloris может быть и в том случае, если поставить
"output_buffers 1 512k;", потому что никакой искуственный интеллект
в nginx пока что не встроен и он не сможет распознать эту атаку
и автоматически сбросить размер буферов для медленных клиентов.
например, "output_buffers auto;" или "output_buffers adaptive;"

но если не поставить "output_buffers 1 512k;" - тогда будет много
iops для чтения файла с диска мелкими фрагментами и сервер тоже
будет не доступен клиентам, как и в случае DDoS-атаки Slowloris.

вот советы по тюнингу nginx в аналогичной ситуации:
http://mailman.nginx.org/pipermail/nginx/2012-May/033761.html

эти вопросы про оптимальную настройку nginx для отдачи файлов
уже давно FAQ, но на странице http://nginx.org/en/docs/faq.html
рекомендаций по настройке nginx для отдачи статики почему-то нет.

P.S.

кстати, стили на странице http://nginx.org/en/docs/faq.html
используются ужасные, все элементы списка сливаются между собой,
если между list items сделать больше интервал - читабельность вырастет.
да и подчеркивания в тексте имееют смысл только тогда, когда это редкие
слова или фразы являются гиперссылками. если весь текст подчеркнут -
читать его очень трудно и неудобно. на сайте http://nginx.org/ не нашел
информации куда писать с предложениями по улучшению доки, поэтому пишу
в список рассылки - вдруг кто-то увидит и исправит эти глюки/проблемы?

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Re: X-Accel-Redirect и uri escape (no replies)

November 26, 2013, 8:39 am
$
0
0
Hello,

Хотел обойтись малой кровью_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
↧

Re: логика работы Host при проксировании (2 replies)

November 26, 2013, 8:39 am
$
0
0
Здравствуйте.

Host здесь ни при чем.
Смотреть нужно в сторону proxy_redirect:
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_redirect


26 ноября 2013 г., 15:58 пользователь denis <denis@webmaster.spb.ru>написал:

> Добрый день.
>
> Не могу понять логику работы с Host. Есть приложение, которое надо
> проксировать на нестандартном порту (пример конфига)
>
> server
> {
> listen *:8080;
>
> server_name aaa.spb.ru;
>
> include conf.all/tunes-main.conf;
>
> location / {
> proxy_redirect off;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For
> $proxy_add_x_forwarded_for;
> proxy_set_header Host $host;
>
> proxy_pass http://192.168.2.32:8080;
> }
> }
>
> При обращении там идут редиректы, при этом Location возвращается без
> указания порта (8080) и поэтому ничего не работает.
> При этом установка
> proxy_set_header Host aaa.spb.ru:8080;
> после блока proxy_set_header также ничего не дает - этот блок вынесен в
> отдельный файл для всех сайтов.
>
> Но стоит убрать строку proxy_set_header Host $host; - и порт нормально
> появляется в редиректе. В чём логика? Host нельзя переопределить 2 строкой?
> или при этом уходит запрос с 2 хостами и система сама выбирает что больше
> нравится? или как? И как тогда правильнее задать в выносном блоке, можно ли
> как Host $host$port? Или просто не добавлять, а для секции с изменением
> порта - задавать Host уже в нужном location?
>
> И попутно мелкий вопросик: была ситуация наоборот, проксируем запрос
> внутрь с 80 порта на 8080, пока явно не прописали Host $host:80; -
> периодически порт 8080 проявлялся в адресной строке. Хотя на десятке других
> серверов такого не было, при том что секция одинаковая.
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




--
Best Regards,
Vadim Lazovskiy
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Re: Затыки при отдаче статики (no replies)

November 26, 2013, 8:39 am
$
0
0
On Saturday 23 November 2013 15:11:27 Gelun, Artem wrote:
[..]
> Насколько я понимаю, sendfile (который включен и должен отрабатывать) не
> блокирует worker'а.

На Linux блокирует если в памяти запрошенных данных нет.

[..]
> 3) Если я правильно понимаю, при размере файла < размера буфера сокета и
> если sendfile_max_chunk не установлен, то sendfile должен вызываться один
> раз.

Нет, он будет зваться ровно столько раз, сколько понадобиться для отдачи
всего файла.

У вас nginx собран без сторонних модулей?

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Re: Затыки при отдаче статики (no replies)

November 26, 2013, 8:39 am
$
0
0
23 ноября 2013 г., 13:03 пользователь Alex Vorona <voron@amhost.net>написал:

> 22.11.2013 22:47, Gelun, Artem wrote:
> > Добрый вечер, коллеги
> >
> > Помогите, пожалуйста, разобраться с тормозами при отдаче статики (файлы
> > порядка 2-4 МБайт, около 700-1000 rps, keep-alive не используется со
> > стороны клиента (!), 99% клиентских сессий - с localhost, отдача начинает
> > тормозить где-то на 2.7-3 Gbps)
> > проблема выглядит как периодическое "залипание" загрузки файла на
> некоторый
> > интервал (от долей секунды до нескольких секунд).
> перегрузка дисков?
>

Для "боевой" нагрузки - возможно и так. Но что тогда с tmpfs?
Или имеется ввиду перегрузка дисков и блокировка чего то (чего и когда?),
что влечёт затыки и для tmpfs?


> [...]
> > LA на сервере высокий (в основном, из-за чтения с HDD), на 16 ядрах
> > держится около 16.
> Если клиент умеет ходить в unix-сокет (например nginx) - попробуйте
> перевести. Для HDD
> nginx и ОС нужно настраивать так чтобы nginx читал с диска как можно
> бОльшими в пределах
> разумного кусками, 512к-2048к например. Для этого прочитанные данные
> должны влазить в
> буфер сокета, желательно также увеличить readahead, например через
> blockdev --setra
>

опять же, tmpfs, RA не актуален.
unix socket не умеет (пока). Вообще, мысль хорошая, спасибо.
в listen для проверки выставил уже запредельный sndbuf=8192k (благо памяти
хватает), в sysctl - "net.ipv4.tcp_wmem = 4096 131072 8388608" - всё равно
затыки даже на файлах по 4МБайта.

При том затыкается именно где-то посередине в большинстве случаев, но в
разные моменты (т.е. нет явной связи с объёмом закачки). Действительно
ощущение, что что-то куда-то не влазит. Но, опять же, куда?


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

Насколько я понимаю, sendfile (который включен и должен отрабатывать) не
блокирует worker'а. Единственное подозрение - воркеры блокируются при
открытии файла с "перегруженного" HDD. Но:
1) как это проверить?
2) увеличение кол-ва worker'ов (до 64) не помогает
3) Если я правильно понимаю, при размере файла < размера буфера сокета и
если sendfile_max_chunk не установлен, то sendfile должен вызываться один
раз. Соответсвенно, если затык в nginx, то он будет перед началом отдачи
данных. Но затыкаться может где угодно - и на 9%, и на 15%, и на 67%...
(опять же, речь про tmpfs, с которой вообще никто ничего не читает, кроме
теста)



>
> А вообще я не уверен что при перегруженных HDD проблема имеет решение,
> если поступающих
> запросов больше, чем может обслужить дисковая подсистема.
>
> _______________________________________________
> 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
↧
Search

Re: X-Accel-Redirect и uri escape (5 replies)

November 26, 2013, 8:39 am
$
0
0
Hello!

On Mon, Nov 25, 2013 at 07:38:08PM +0300, Rommer wrote:

> Hello,
>
> Насколько я вижу, все предыдущие попытки ни к чему конструктивному
> так и не привели.
>
> Поэтому предлагаю новую опцию safe_redirect on/off.
> Если установлена в "on" в http, server или location, откуда
> идет proxy_pass, путь в X-Accel-Redirect воспринимает
> как escaped uri. По дефолту стоит в off и поведение
> парсера не меняет.

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

Проблема в том, что никто так и не сделал приличный патч,
консистентно меняющий поведение парсера.

[...]

> diff -Nru a/src/http/ngx_http_core_module.c b/src/http/ngx_http_core_module.c
> --- a/src/http/ngx_http_core_module.c 2013-11-19 15:25:25.000000000 +0400
> +++ b/src/http/ngx_http_core_module.c 2013-11-25 18:49:09.253001176 +0400
> @@ -746,6 +746,13 @@
> offsetof(ngx_http_core_loc_conf_t, resolver_timeout),
> NULL },
>
> + { ngx_string("safe_redirect"),
> + NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_FLAG,
> + ngx_conf_set_flag_slot,
> + NGX_HTTP_LOC_CONF_OFFSET,
> + offsetof(ngx_http_core_loc_conf_t, safe_redirect),
> + NULL },

Совершенно непонятно, зачем вы решили сделать опцию в
ngx_http_core_module...

[...]

> --- a/src/http/ngx_http_upstream.c 2013-11-19 15:25:25.000000000 +0400
> +++ b/src/http/ngx_http_upstream.c 2013-11-25 20:19:44.019000094 +0400
> @@ -1893,14 +1893,18 @@
> static ngx_int_t
> ngx_http_upstream_process_headers(ngx_http_request_t *r, ngx_http_upstream_t *u)
> {
> + u_char *dst, *src;
> + size_t len;
> ngx_str_t *uri, args;
> ngx_uint_t i, flags;
> ngx_list_part_t *part;
> ngx_table_elt_t *h;
> ngx_http_upstream_header_t *hh;
> ngx_http_upstream_main_conf_t *umcf;
> + ngx_http_core_loc_conf_t *clcf;
>
> umcf = ngx_http_get_module_main_conf(r, ngx_http_upstream_module);
> + clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);
>
> if (u->headers_in.x_accel_redirect
> && !(u->conf->ignore_headers & NGX_HTTP_UPSTREAM_IGN_XA_REDIRECT))
> @@ -1938,9 +1942,27 @@
> ngx_str_null(&args);
> flags = NGX_HTTP_LOG_UNSAFE;
>
> - if (ngx_http_parse_unsafe_uri(r, uri, &args, &flags) != NGX_OK) {
> - ngx_http_finalize_request(r, NGX_HTTP_NOT_FOUND);
> - return NGX_DONE;
> + if (clcf->safe_redirect) {

...и при этом используете её только в upstream'е.

> +
> + dst = uri->data;
> + src = uri->data;
> +
> + ngx_unescape_uri(&dst, &src, uri->len, NGX_UNESCAPE_URI);
> +
> + len = (uri->data + uri->len) - src;
> + if (len) {
> + dst = ngx_movemem(dst, src, len);
> + }
> +
> + uri->len = dst - uri->data;
> +
> + } else {
> +
> + if (ngx_http_parse_unsafe_uri(r, uri, &args, &flags) != NGX_OK) {
> + ngx_http_finalize_request(r, NGX_HTTP_NOT_FOUND);
> + return NGX_DONE;
> + }
> +

Так совсем неправильно: аргументы в "X-Accel-Redirect"
обрабатываются только в том случае, если флаг clcf->safe_redirect
не установлен. Не говоря уже про unsafe-проверки, которые не
делаются.

И даже если сделать как в SSI, то проблема "?" в пути не решается.

--
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
↧

nginx security advisory (CVE-2013-4547) (no replies)

November 26, 2013, 8:39 am
$
0
0
Hello!

Ivan Fratric из Google Security Team обнаружил ошибку в nginx, которая
позволяет в некоторых случаях обходить ограничения безопасности с
помощью специального запроса, а также может иметь другие последствия
(CVE-2013-4547).

Некоторые проверки URI запроса не делались над символом, следующим за
незакодированным символом пробела (незакодированный пробел недопустим в
соответствии с протоколом HTTP, однако поддерживается начиная с nginx
0.8.41 из соображений совместимости). Одним из результатов ошибки была
возможность получить доступ к файлу, закрытому с помощью ограничений
доступа вида

location /protected/ {
deny all;
}

запросив его как "/foo /../protected/file" (в случае статических файлов -
только если существует каталог "foo ", с пробелом на конце), а также
возможность вызывать специальную обработку файла с пробелом на конце в
конфигурации вида

location ~ \.php$ {
fastcgi_pass ...
}

запросив файл как "/file \0.php".

Проблеме подвержены версии nginx 0.8.41 - 1.5.6.

Проблема исправлена в nginx 1.5.7, 1.4.4.

Патч, исправляющий проблему, доступен тут:

http://nginx.org/download/patch.2013.space.txt

В качестве временной защиты можно в каждом блоке server{}
воспользоваться конфигурацией вида:

if ($request_uri ~ " ") {
return 444;
}


--
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Re: Затыки при отдаче статики (no replies)

November 26, 2013, 8:39 am
$
0
0
Геннадий, Вы говорите про оптимизацию дисковой подсистемы. А я - про то,
что чтение из tmpfs (считай, RAM) "застевает" в произвольные моменты
времени по непонятным причинам. Это несколько разные проблемы. В этом
случае ни ngx_slowfs_cache, ни SSD, ни двойное проксирование решения не
дадут.


23 ноября 2013 г., 16:07 пользователь Gena Makhomed <gmm@csdoc.com> написал:

> On 23.11.2013 11:03, Alex Vorona wrote:
>
> А вообще я не уверен что при перегруженных HDD проблема имеет решение,
>> если поступающих запросов больше, чем может обслужить дисковая подсистема.
>>
>
> есть очень похожая задача - что делать, если трафика больше,
> чем Bandwidth сетевой подсистемы. и эта задача успешно решена
> практически во всех операционных системах. например, для линукса
> - http://xgu.ru/wiki/QoS_в_Linux, Hierarchy Token Bucket и т.п.
>
> разница только в том, что Bandwidth сетевой подсистемы измеряется
> в мегабитах в секунду, а Bandwidth дисковой подсистемы - в IOPS.
> например, в новых версиях OpenVZ уже появилась опция --iopslimit iops
> также в линуксе есть ionice с 4 класами и 8 приоритетами внутри класса.
>
> теоретически, - если клиенты не однородны, (например, те, кто платит
> деньги за доступ к контенту и те, кто получает доступ к нему бесплатно)
> то можно разделить их по классам и назначить разные уровни приоритета.
> сейчас же обычно все свалено в одну кучу, и никаких QoS настроек нет.
>
> поскольку native поддержки для этого в nginx нет и вряд ли когда-либо
> появится, то это все придется делать средствами операционной системы.
>
> хотя обычно тюнинг nginx и операционной системы, чтобы данные с дисков
> читались большими блоками по 1 мегабайту - помогает и этого достаточно.
>
> еще скрытые резервы для повышения производительности могут быть в том,
> что дисковое хранилище собрано в виде RAID массива 5/6/10/... - в таком
> случае сам RAID массив является узким местом и его лучше разобрать
> на "отдельные" диски или RAID-1 массивы из N дисков. в этом случае,
> если software raid / hardware raid не кривой - скорость random
> чтения с RAID-1 массива из N дисков будет примерно в N раз выше.
>
> или же - добавить SSD к системе хранения файлов в том или ином виде
> (Bcache,Flashcache,Btier,EnhanceIO, nginx+ngx_slowfs_cache, etc...)
> туда уйдет самый "горячий" контент и вся система выдаст больше IOPS.
>
> кстати, странно что функциональности модуля ngx_slowfs_cache
> нет в основной ветке nginx, - чтобы сделать что-то аналогичное
> без ngx_slowfs_cache придется использовать "двойное проксирование".
> хотя может быть overhead от этого не большой и это вполне приемлимо.
> но настройка получается не тривиальной: http://habrahabr.ru/post/202290/
>
> --
> 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
↧

логика работы Host при проксировании (no replies)

November 26, 2013, 8:39 am
$
0
0
Добрый день.

Не могу понять логику работы с Host. Есть приложение, которое надо
проксировать на нестандартном порту (пример конфига)

server
{
listen *:8080;

server_name aaa.spb.ru;

include conf.all/tunes-main.conf;

location / {
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
proxy_set_header Host $host;

proxy_pass http://192.168.2.32:8080;
}
}

При обращении там идут редиректы, при этом Location возвращается без
указания порта (8080) и поэтому ничего не работает.
При этом установка
proxy_set_header Host aaa.spb.ru:8080;
после блока proxy_set_header также ничего не дает - этот блок вынесен в
отдельный файл для всех сайтов.

Но стоит убрать строку proxy_set_header Host $host; - и порт нормально
появляется в редиректе. В чём логика? Host нельзя переопределить 2
строкой? или при этом уходит запрос с 2 хостами и система сама выбирает
что больше нравится? или как? И как тогда правильнее задать в выносном
блоке, можно ли как Host $host$port? Или просто не добавлять, а для
секции с изменением порта - задавать Host уже в нужном location?

И попутно мелкий вопросик: была ситуация наоборот, проксируем запрос
внутрь с 80 порта на 8080, пока явно не прописали Host $host:80; -
периодически порт 8080 проявлялся в адресной строке. Хотя на десятке
других серверов такого не было, при том что секция одинаковая.

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Re: Добавить переменую $cache status (no replies)

November 26, 2013, 8:39 am
$
0
0
18.11.2013, 23:46, "S.A.N" <nginx-forum@nginx.us>:
> Реальный пример из жизни, у нас есть страница товара, ниже выводим
> комментарии пользователей, хедер страницы Last-Modified – это дата
> создания/редактирования товара, это необходимо для поисковиков RSS клиентов
Для поисковиков можно генерировать sitemap, какое дело rss клиентам до last-modified обычной html страницы не сообразил, что скрывается под и т.д. не знаю.

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
↧

Re: X-Accel-Redirect и uri escape (1 reply)

November 26, 2013, 8:39 am
$
0
0
Hello!

On Mon, Nov 25, 2013 at 05:00:31AM +0300, Роман Шишнев wrote:

> Hello,
>
> Обнаружил несколько странное поведение nginx при обработке
> X-Accel-Redirect от upstream:
>
> При появлении знака "?" в имени файла в заголовке, uri обрезается до
> этого знака, а все остальное складывается в аргументы. Попробовал
> этот знак заменить на %3F, все стало ещё интереснее - в uri заменяются
> на стороне nginx все символы "%" на "%25", в итоге выходит что-то вроде
> "%253F" при передаче на следующий upstream.
>
> Полагаю, если в имени файла встретится последовательность "\r\n", этот
> файл вообще нельзя будет отправить в nginx с помощью X-Accel-Redirect.
> В явном виде эта последовательность закончит uri в заголовке на себе,
> а остаток имени будет следующим зоголовком, а в виде %0D%0A будет
> превращена в %250D%250A.
>
> В первом случае файл "aaa\r\nRefresh: 0;url=login" отправит клиента
> по другому адресу, а во втором случае комбинацию никакой upstream не
> разберет.
>
> Вопрос как сейчас передавать в nginx с помощью X-Accel-Redirect
> файлы в имени которых есть спец-символы?
>
> Может стоит сделать отдельную опцию (что-нибудь в духе
> safe_redirect on/off) при включении которой nginx не будет
> дополнительно escape'ать uri в X-Accel-Redirect?

Сейчас nginx полагает, что в X-Accel-Redirect передаётся
незакодированный URI. Есть мнение, что это неправильно (в
частности потому, что файл с "?" в имени отправить нельзя), и
надо изменить логику так, чтобы передавался закодированный URI.

Где-то тут про это есть чуть больше подробностей, а также ссылки
на предыдущие попытки решить проблему:

http://trac.nginx.org/nginx/ticket/316

--
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Затыки при отдаче статики (2 replies)

November 26, 2013, 8:39 am
$
0
0
Добрый вечер, коллеги

Помогите, пожалуйста, разобраться с тормозами при отдаче статики (файлы
порядка 2-4 МБайт, около 700-1000 rps, keep-alive не используется со
стороны клиента (!), 99% клиентских сессий - с localhost, отдача начинает
тормозить где-то на 2.7-3 Gbps)

проблема выглядит как периодическое "залипание" загрузки файла на некоторый
интервал (от долей секунды до нескольких секунд).

Конфигурация:

worker_processes 16;
worker_rlimit_nofile 21000;
worker_priority -5;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
timer_resolution 100ms;
events {
worker_connections 10240;
use epoll;
}
http {
sendfile on;
# sendfile_max_chunk 1m;
open_file_cache max=10240 inactive=300s;
open_file_cache_valid 2000s;
open_file_cache_min_uses 1;
open_file_cache_errors on;
# aio on;
# directio 4k;
# directio_alignment 4k;
# output_buffers 128 512k;
keepalive_timeout 60;
underscores_in_headers on;
server_tokens off;
tcp_nodelay on;

...
}

Всё что закомментировано - проверялось без результата.

Для теста сделал tmpfs (чтобы исключить тормоза HDD), поставил рядом
apache2 (чтобы минимизировать вероятность тормозов сетевого стека), с
соседнего сервера делаю запрос на файл в tmpfs, apache выдаёт его стабильно
с 24-25MBps, nginx тот же файл - в лучшем случае 12MBps,

Затыки также замечаются и на локалхосте. Скорость - от тех же 12MBps до
720MBps. Апач стабильно держит >1GBps. Вот пример времени выполнения
запросов с локалхоста:

real 0m4.167s
user 0m0.008s
sys 0m0.042s

real 0m2.085s
user 0m0.006s
sys 0m0.049s

real 0m2.079s
user 0m0.007s
sys 0m0.055s

real 0m0.623s
user 0m0.007s
sys 0m0.064s

real 0m1.225s
user 0m0.004s
sys 0m0.052s

real 0m0.333s
user 0m0.005s
sys 0m0.057s

real 0m2.097s
user 0m0.004s
sys 0m0.058s

*ОС:* 2.6.32-358.6.2.el6.x86_64 #1 SMP Thu May 16 20:59:36 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux

net.core.netdev_max_backlog=20480
net.core.rmem_default=131072
net.core.rmem_max=1310720
net.core.somaxconn=2048
net.core.wmem_default=131072
net.core.wmem_max=1310720
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.all.log_martians=1
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.all.secure_redirects=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.default.accept_source_route=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.default.secure_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.icmp_ignore_bogus_error_responses=1
net.ipv4.ip_forward=0
net.ipv4.tcp_dsack=1
net.ipv4.tcp_mem=24576 32768 131072
net.ipv4.tcp_rmem=4096 65536 524288
net.ipv4.tcp_sack=1
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_window_scaling=1
net.ipv4.tcp_wmem=4096 65536 524288
net.ipv4.udp_mem=8388608 12582912 33554432
net.ipv4.udp_rmem_min=16384
net.ipv4.udp_wmem_min=16384

проверялось также с:
net.ipv4.tcp_sack=0
, бОльшими числами в tcp_mem, tcp_wmem
, бОльшим числом worker'ов (до 32)

результат одинаков.

LA на сервере высокий (в основном, из-за чтения с HDD), на 16 ядрах
держится около 16.

Что я не так готовлю?
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
Search

вопрос по fastcgi_store (no replies)

November 26, 2013, 8:39 am
$
0
0
Здравствуйте,

Есть конфигурация один в один как в примере
http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_store

Из документации не ясно, можно ли заставить nginx не сохранять ответ
бекенда в файл в каких то случаях?

Допустим, если бекенд возвращает заголовок какой-то, или если статус
ответа скажем 404 или ещё как нибудь?

Спасибо!

--
Eugeny Zadevalov

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

X-Accel-Redirect и uri escape (no replies)

November 26, 2013, 8:39 am
$
0
0
Hello,

Обнаружил несколько странное поведение nginx при обработке
X-Accel-Redirect от upstream:

При появлении знака "?" в имени файла в заголовке, uri обрезается до
этого знака, а все остальное складывается в аргументы. Попробовал
этот знак заменить на %3F, все стало ещё интереснее - в uri заменяются
на стороне nginx все символы "%" на "%25", в итоге выходит что-то вроде
"%253F" при передаче на следующий upstream.

Полагаю, если в имени файла встретится последовательность "\r\n", этот
файл вообще нельзя будет отправить в nginx с помощью X-Accel-Redirect.
В явном виде эта последовательность закончит uri в заголовке на себе,
а остаток имени будет следующим зоголовком, а в виде %0D%0A будет
превращена в %250D%250A.

В первом случае файл "aaa\r\nRefresh: 0;url=login" отправит клиента
по другому адресу, а во втором случае комбинацию никакой upstream не
разберет.

Вопрос как сейчас передавать в nginx с помощью X-Accel-Redirect
файлы в имени которых есть спец-символы?

Может стоит сделать отдельную опцию (что-нибудь в духе
safe_redirect on/off) при включении которой nginx не будет
дополнительно escape'ать uri в X-Accel-Redirect?

--93FB2808C9.1385344859/rl01.atservers.net--

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
↧

Re: limit rate, limit req и limit conn внутри условия IF (no replies)

November 26, 2013, 8:39 am
$
0
0
Оно отправилось раньше, чем надо было...
Так вот, как вариант, можно создать аналогичный server{} без лимитов и с другим server_name и пускай скрипты ломятся туда.

09.11.2013, 21:01, "sofiamay" <nginx-forum@nginx.us>:
> Здравствуйте. Вот такой вот конфиг прекрасно работает внутри Location или
> внутри Server:
>
> location / {
> limit_req zone=reqip burst=128;
> limit_conn url_ip 4;
> set $limit_rate 312k;
> limit_rate  312k;
> }
>
> Но стоит вместо location / { написать if ($remote_addr = 'xx.xx.xx.xx') { то
> сервер ругается, ничего не работает.
> Мне нужно чтобы для всех клиентов действовали ограничения, а для сервера нет
> (когда запросы на сервер идут с самого сервера через скрипты).
>
> Подскажите пожалуйста, неужели все эти настройки Nginx не позволяет
> размещать внутри условия? Может я чего не так делаю. Если всё настолько
> плохо и не позволяет, то подскажите пожалуйста может кто-то знает каким
> путем можно решить возникшую проблему... Спасибо
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244549,244549#msg-244549
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Re: limit rate, limit req и limit conn внутри условия IF (no replies)

November 26, 2013, 8:39 am
$
0
0
Hello.
Можно, к примеру, сделать такой

09.11.2013, 21:01, "sofiamay" <nginx-forum@nginx.us>:
> Здравствуйте. Вот такой вот конфиг прекрасно работает внутри Location или
> внутри Server:
>
> location / {
> limit_req zone=reqip burst=128;
> limit_conn url_ip 4;
> set $limit_rate 312k;
> limit_rate  312k;
> }
>
> Но стоит вместо location / { написать if ($remote_addr = 'xx.xx.xx.xx') { то
> сервер ругается, ничего не работает.
> Мне нужно чтобы для всех клиентов действовали ограничения, а для сервера нет
> (когда запросы на сервер идут с самого сервера через скрипты).
>
> Подскажите пожалуйста, неужели все эти настройки Nginx не позволяет
> размещать внутри условия? Может я чего не так делаю. Если всё настолько
> плохо и не позволяет, то подскажите пожалуйста может кто-то знает каким
> путем можно решить возникшую проблему... Спасибо
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244549,244549#msg-244549
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Re: nginx-1.5.7 (no replies)

November 26, 2013, 8:39 am
$
0
0
На бэкенд ничего не ложится. Просто nginx должен был отправлять данные
сразу (т.к. речь идет про небуферизованное проксирование), а он их
задерживал.


21 ноября 2013 г., 9:25 пользователь Алексей Сундуков <
public-mail@alekciy.ru> написал:

> >часть данных, полученных от бэкенда при
> >небуферизированном проксировании, могла не отправляться клиенту
> >сразу, если использовались директивы gzip или gunzip.
>
> А это означает, что gzip или gunzip для клиента отключаются или же на
> бэкэнд ложиться задача сжатия ответа, а nginx просто сразу отправляет
> клиенту полученные с бэкэнда данные?
>
> _______________________________________________
> 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
↧
Viewing all 3102 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>