Re: Логгирование коннектов без запросов

[kpoxa]

Добрый день.

Я конечно могу описать кейс, когда это нужно. А именно когда есть
сохраненный трафик и надо понять, к чему он относится. Подробнее не могу, у
меня подписка о неразглашении.

чт, 27 февр. 2020 г. в 15:22, Maxim Dounin :

> Hello!
>
> On Thu, Feb 27, 2020 at 01:08:47PM +0300, kpoxa wrote:
>
> > Браузеры часто делают коннекты без запросов, которые выглядят как "а ну
> ка
> > я сделаю коннект, мало ли что надо будет.. не.. не понадобилось, разрываю
> > коннект"
> > и информации об этом коннекте в access_log конечно же нет, но логгировать
> > такие коннекты надо. Как это можно сделать?
> > Если писать свой модуль, то в какой обработчик придёт подобная
> информация?
>
> Сейчас для http эта информация есть только на уровне debug log'а.
> И в своём модуле - её тоже никак не получить, модули в http
> начинают работать только после получения заголовков запроса.
>
> Мы пару раз задумывались над вопросом "а не добавить ли строчку в
> error log на уровне info?", вида "client X connected to Y",
> аналогично тому, что делается в mail и stream.  Но пока нет
> разумного ответа на вопрос "а надо ли это вообще кому-то".
>
> --
> Maxim Dounin
> http://mdounin.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

Логгирование коннектов без запросов

[kpoxa]

Добрый день.

Браузеры часто делают коннекты без запросов, которые выглядят как "а ну ка
я сделаю коннект, мало ли что надо будет.. не.. не понадобилось, разрываю
коннект"
и информации об этом коннекте в access_log конечно же нет, но логгировать
такие коннекты надо. Как это можно сделать?
Если писать свой модуль, то в какой обработчик придёт подобная информация?
--
Рустам.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: stream server by sni

[kpoxa]

Тут всё хорошо, кроме того, что не будет разных серверов с разными ssl
сертификатами, как могло бы быть.

чт, 19 дек. 2019 г. в 15:45, Илья Шипицин :

> на ssl_preread можно попробовать
>
> https://nginx.org/ru/docs/stream/ngx_stream_ssl_preread_module.html
>
> чт, 19 дек. 2019 г. в 17:02, kpoxa :
>
>> Добрый день.
>>
>> А есть возможность повесить на 1 ip:port 2 и более серверов тима stream с
>> выбором сервера по sni ?
>>
>> --
>> Рустам
>>
>>
>> ___
>> 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

stream server by sni

[kpoxa]

Добрый день.

А есть возможность повесить на 1 ip:port 2 и более серверов тима stream с
выбором сервера по sni ?

--
Рустам
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Не планируется ли написание модуля для DNS over HTTP?

[kpoxa]

Добрый день.

Вариант 2, чтобы он транслировал запросы на внешний НДС по UPD/TCP.

вт, 19 нояб. 2019 г. в 14:35, Maxim Dounin :

> Hello!
>
> On Thu, Nov 14, 2019 at 12:21:54PM +0300, kpoxa wrote:
>
> > Не планируется ли написание модуля к nginx для DNS over HTTP?
>
> Пока в планах нет.
> На всякий случай уточню - что именно хочется от nginx'а:
>
> - чтобы он отвечал на DoH-запросы сам,
> - чтобы он транслировал их на какой-то внешний DNS-сервер по UDP/TCP,
> - или чтобы умел использовать DoH в рамках директивы resolver?
>
> --
> Maxim Dounin
> http://mdounin.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

Не планируется ли написание модуля для DNS over HTTP?

[kpoxa]

Добрый день.

Не планируется ли написание модуля к nginx для DNS over HTTP?

--
Рустам
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Немного про логику кеша

[kpoxa]

Добрый день.

Что-то у меня не сходится, не понимаю:

Запрос в 22/May/2019:17:15:43
Файл элемента кеша создан  May 18 12:46
inactive=1d
ответ 302
proxy_cache_valid 301 302 404 15s;

Более подробно:


В логе запрос с попаданием в кеш

[22/May/2019:17:15:43 +0300] "/s13/27/public_pin_l/241/2352410650.jpg"
ip=15.85.172.17 status=302 size=0 upTime=- upstream_addr=-
upstream_status=- request_time=0.000 cache=HIT ref="-" http

Вычисляем файл кеша:

echo -n /s13/27/public_pin_l/241/2352410650.jpg | md5sum
044e2e2e9226a8f10d25d480a49d2000

Вот он

-rw--- 1 www-data www-data 684 May 18 12:46
044e2e2e9226a8f10d25d480a49d2000

Содержит он


cat 044e2e2e9226a8f10d25d480a49d2000
ђa]ђФЯ\ТYЁK~¬
KEY: /s13/27/public_pin_l/241/2352410650.jpg
HTTP/1.1 302 Found
Server: nginx/1.15.8
Date: Sat, 18 May 2019 09:46:56 GMT
Content-Length: 0
Connection: close
Cache-Control: max-age=2592000
Expires: Mon, 17 Jun 2019 09:46:56 GMT
Location: /s107/797257fdf5bc88f5/2352410650.jpg
Pragma: no-cache
X-Powered: iconv
Content-Type: image/jpeg

Конфиг вот такой:

user  www-data;
worker_processes  auto;
worker_rlimit_nofile 16;
thread_pool pool_1 threads=128;
thread_pool pool_2 threads=128;
error_log   /var/log/nginx/error.log warn;
events {
worker_connections  15;
use epoll;
}
http {
server_tokens off;
include   mime.types;
default_type  application/octet-stream;
log_format  stat'[$time_local] "$request_uri" ip=$remote_addr
status=$status size=$body_bytes_sent upTime=$upstream_response_time
upstream_addr=$upstream_addr upstream_status=$upstream_status'
' request_time=$request_time
cache=$upstream_cache_status ref="$http_referer" $scheme $http2';
log_not_found   off;
sendfile   on;
tcp_nopush on;
keepalive_timeout  300;
gzip  off;
reset_timedout_connection on;
client_body_buffer_size 128k;
client_max_body_size20m;
open_file_cache  max=1 inactive=5m;
open_file_cache_valid2m;
open_file_cache_min_uses 1;
open_file_cache_errors   on;
proxy_temp_path   /run/shm;
proxy_cache_key   $uri$is_args$args;
proxy_cache_valid 200 30d;
proxy_cache_valid 301 302 404 15s;
proxy_cache_lock  off;
proxy_cache_use_stale error timeout invalid_header http_500
http_502 http_503 http_504 http_404;
proxy_redirectoff;
recursive_error_pages on;
proxy_buffers 16 16k;
proxy_buffer_size 64k;
proxy_ignore_client_abort off;
proxy_intercept_errorson;
proxy_next_upstream   error timeout invalid_header http_500
http_502 http_503 http_504 http_404;
proxy_set_header  Host$host;
proxy_set_header  X-Real-IP   $remote_addr;
proxy_set_header  X-Forwarded-For
$proxy_add_x_forwarded_for;
proxy_max_temp_file_size  0;
include upstream/upstream_cache.conf;
include upstream/upstream_storage.conf;
include upstream/all_in_one_storage_upstream.conf;
include nginx.ssl.conf;
proxy_cache_path /ssd levels=1:2 keys_zone=ssd1:2000m
max_size=175000m inactive=1d loader_files=1000 use_temp_path=off;
proxy_cache_path /ssd2levels=1:2 keys_zone=ssd2:2000m
max_size=205000m inactive=1d loader_files=1000 use_temp_path=off;
split_clients $uri$is_args$args $disk {
56.3% 2;
* 1;
}

aio threads=pool_$disk;
proxy_cache ssd$disk;
server {
server_name 8.local.net;
listen  80  backlog=102400  default;
listen  443 backlog=102400 ssl http2 default;
root /etc/nginx/html;
access_log /var/log/nginx/access_basic.log stat;
location / {
try_files $uri @to_neighbor;
}
location = /error404.html {
return 404 "No such file";
}
location @to_neighbor {
internal;
access_log  /var/log/nginx/access_full.log stat;
proxy_pass  http://cache_$real_host;
error_page 400 /error404.html;
error_page 404 = @to_storage;
error_page 502 = @to_storage;
error_page 504 = @to_storage;
error_page 503 = @to_storage;
}
location @to_storage {
if ( $request_method = PURGE ) { return 200; }
internal;
access_log  /var/log/nginx/access_full.log stat;
access_log  /var/log/nginx/access_stat.log stat if=$do_log;
include logs.inc;
proxy_pass  http://all-storages;
error_page 400 /error404.html;
}
}
} # end of http




вт, 21 мая 2019 г. в 17:22, Maxim Dounin :

> Hello!
>
> On Tue, May 21, 2019 at 04:31:46PM +0300, kpoxa wrote:
>
> > Есть некоторые директивы, про которые не совсем понят

Немного про логику кеша

[kpoxa]

Добрый день.

Есть некоторые директивы, про которые не совсем понятно, как они работают
вместе, в частности у proxy_cache_path есть параметр inactive, который
задаёт время жизни файла в кеше, считая с последнего обращения. А еще есть
директива proxy_cache_valid, судя по описанию которой, которая тоже
отвечает за что-то подобное, обозванное временем кеширования.

И в связи с этим у меня вопрос:
как мне настроить кеш так, чтобы 302 редиректы кешировались на 15 секунд?
При настройках inactive=7d никакие варианты прописать proxy_cache_valid 302
15s не работают, в кеше куча вчерашних редиректов.
И второй вопрос - при каких условиях и как работает proxy_cache_valid ?
Пока что у меня не сходятся реальное поведение с документацией.

---
Рустам
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy_bind ipv6

[kpoxa]

Добрый день.

Действительно там ipv4 адрес,  в значении upstream, ошибку понял.
Можно ли как-то резолверу сказать, что надо работать только с ipv6 ?
У доменов, которые используются, есть и то у другое, а резолвер выдаёт
только ipv4.


чт, 4 апр. 2019 г. в 15:41, Maxim Dounin :

> Hello!
>
> On Thu, Apr 04, 2019 at 01:55:17PM +0300, kpoxa wrote:
>
> > Добрый день.
> >
> > При использовании
> >
> > proxy_bind   2a04:40:1000:8::3;
> >
> > Получаю ошибку 500 со следующим текстом в логе:
> >
> > 2019/04/04 13:50:37 [crit] 1780#1780: *1 bind(2a04:40:1000:8::3) failed
> > (97: Address family not supported by protocol) while connecting to
> > upstream, client: 18.5.7.10, server: localhost
> > , request: "GET / HTTP/1.1", upstream: "https://server:443/;, host: "
> > 178.218.213.241:443"
> >
> > В proxy_bind не поддерживается ipv6 ?
>
> Поддерживается.  Но если вы пытаетесь идти на IPv4-бэкенд, то
> счастья не будет.
>
> Ну отдельно отмечу, что если бы вы не отредактировали 'upstream:
> "https://server:443/;' в приведённой строке лога - проблема была
> бы очевидна.  Не надо так.
>
> --
> Maxim Dounin
> http://mdounin.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

proxy_bind ipv6

[kpoxa]

Добрый день.

При использовании

proxy_bind   2a04:40:1000:8::3;

Получаю ошибку 500 со следующим текстом в логе:

2019/04/04 13:50:37 [crit] 1780#1780: *1 bind(2a04:40:1000:8::3) failed
(97: Address family not supported by protocol) while connecting to
upstream, client: 18.5.7.10, server: localhost
, request: "GET / HTTP/1.1", upstream: "https://server:443/;, host: "
178.218.213.241:443"

В proxy_bind не поддерживается ipv6 ?

--
Рустам
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx-1.15.10

[kpoxa]

Добрый день.

Здорово, работает.

При задании 10 000 портов ругается, несмотря на выставление большого числа
открытых файлов

#sysctl fs.file-max
fs.file-max = 99

nginx.conf
...
worker_rlimit_nofile 100;
…
http{
server{
listen 1-11010;
}
}

error.log
2019/04/04 13:36:00 [emerg] 1243#1243: socket() 0.0.0.0:11016 failed (24:
Too many open files)

--
Рустам



чт, 4 апр. 2019 г. в 12:45, Maxim Konovalov :

> On 04/04/2019 12:42, kpoxa wrote:
> > Добрый день.
> >
> > В документации не нашел про
> >>   *) Добавление: диапазоны портов в директиве listen
> > Можно пример использования?
> >
> http://nginx.org/en/docs/stream/ngx_stream_core_module.html#listen
>
> --
> Maxim Konovalov
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx-1.15.10

[kpoxa]

Добрый день.

В документации не нашел про
>   *) Добавление: диапазоны портов в директиве listen
Можно пример использования?

вт, 26 мар. 2019 г. в 17:26, Maxim Dounin :

> Изменения в nginx 1.15.10
>  26.03.2019
>
> *) Изменение: теперь при использовании имени хоста в директиве listen
>nginx создаёт listen-сокеты для всех адресов, соответствующих этому
>имени (ранее использовался только первый адрес).
>
> *) Добавление: диапазоны портов в директиве listen.
>
> *) Добавление: возможность загрузки SSL-сертификатов и секретных ключей
>из переменных.
>
> *) Изменение: переменная $ssl_server_name могла быть пустой при
>использовании OpenSSL 1.1.1.
>
> *) Исправление: nginx/Windows не собирался с Visual Studio 2015 и
> новее;
>ошибка появилась в 1.15.9.
>
>
> --
> 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

Логгирование сессионных ключей ssl

[kpoxa]

Добрый день.

А кто-нибудь сталкивался с необходимостью логгирования сессионных ключей?
Есть примеры реализации?

--
Рустам
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Релиз Unit 1.8.0

[kpoxa]

Добрый день.

А поддержки opcache в php все еще нет?

--
> Валентин Бартенев
> ___
> 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: Пролагивание коннектов при проверке синтаксиса

[kpoxa]

Руками пересчитал количество bind в выводе strace, да, их стало меньше.
Да, этот вариант действительно не рабочий.
Пока что сделано через fake bind, загружаемый через LD_PRELOAD. Костыль,
конечно.

чт, 15 нояб. 2018 г. в 16:55, Maxim Dounin :

> Hello!
>
> On Thu, Nov 15, 2018 at 12:42:51PM +0300, kpoxa wrote:
>
> > Добрый день.
> >
> > Не помогает такой вариант:
> >
> > http {
> >  server {
> >   server_name bind_only;
> >   listen 80;
> >   listen 443 ssl;
> >   location / { return 200;}
> >  }
> >  server {
> >   listen ip10:443;
> >  }
> >  server {
> >   listen ip11:443;
> >  }
> > }
> > stream {
> >  server {
> >   listen ip1:443;
> >  }
> >  server {
> >   listen ip2:443;
> >  }
> >  server {
> >   listen ip3:443;
> >  }
> > }
> >
> > Всё равно nginx при проверке синтаксиса делает bind ко всем адресам,
> > которые указаны в listen;
>
> Как я уже писал ранее, если один и тот же порт пытаться
> использовать в разных модулях - будут проблемы.
>
> В приведённой конфигурации - в http-модуле будет создан
> listen-сокет на *:443, а в stream-модуле - сокеты на ip1:443,
> ip2:443, ip3:443.  Вероятно, именно попытки bind'а на ip1:443,
> ip2:443 и ip3:443 вы приняли за "делает bind ко всем адресам".  На
> самом деле не ко всем, а только к тем, что указаны в
> stream-модуле.
>
> Однако проблема не в этом, а в том, что на Линуксе такая
> конфигурация банально не заработает, так как открыть сокет на
> ip:443 при имеющемся открытом сокете на *:443 - на Линуксе
> нельзя.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Пролагивание коннектов при проверке синтаксиса

[kpoxa]

У меня на сервере 200 IP адресов, на части из 443 портов висят HTTP
сервера, на второй части 443 портов висят стримы.
Соответственно ведут каждый из серверов в разные места. В моем случае
нельзя сделать вилдкардный сервер в одном модуле, не пересекающийся с
другим модулем.
Перечитал ответ Максима, не увидел там противоречий описанному мною
конфигу. Конфиг даже работает. Просто это не приводит к тому, что nginx при
проверке не делал бы лишних bind.

В целом какая разница сколько раз в сутки вызывается проверка синтаксиса,
на мой взгляд даже ручной вызов проверки, приводящий к тормозам продовского
сервера это плохо.

чт, 15 нояб. 2018 г. в 16:05, Vadim A. Misbakh-Soloviov :

> В письме от четверг, 15 ноября 2018 г. 16:42:51 +07 пользователь kpoxa
> написал:
> > Добрый день.
> >
> > Не помогает такой вариант:
> >
> > http {
> ...
> >   listen 80;
> ...
> >  }
> > stream {
> > }
>
> А теперь, пожалуйста, вернитесь на пару писем назад по цепочке, и
> прочитайте
> ответ Максима.
> http и stream - разные модули.
> И вполне логично, что сокеты, объявленные в http{} не имеют отношения к
> сокетам, объявленным в stream{}. Как вы думаете?
> Вам, практически в явном виде, предлагалось создать вайлдкардный server{}
> в
> stream-модуле.
>
> И да, кстати,
> 1) можно указать `server_name _;` (нужен любой невалидный, а _ - самый
> короткий из них.
> 2) почему вы, всё же, не хотите в явном виде указать вайлдкард listen'у?
> ___
> 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: Пролагивание коннектов при проверке синтаксиса

[kpoxa]

Добрый день.

Не помогает такой вариант:

http {
 server {
  server_name bind_only;
  listen 80;
  listen 443 ssl;
  location / { return 200;}
 }
 server {
  listen ip10:443;
 }
 server {
  listen ip11:443;
 }
}
stream {
 server {
  listen ip1:443;
 }
 server {
  listen ip2:443;
 }
 server {
  listen ip3:443;
 }
}

Всё равно nginx при проверке синтаксиса делает bind ко всем адресам,
которые указаны в listen;

чт, 15 нояб. 2018 г. в 08:23, Vadim A. Misbakh-Soloviov :

> В письме от среда, 14 ноября 2018 г. 21:11:01 +07 пользователь kpoxa
> написал:
> > Я правильно понимаю, что можно сделать один listen 443 в специально
> > сделанном сайте,
> > который по другому никак не будет использоваться, а во всех остальных
> > местах,
> > и в HTTP и в стримах оставить listen ip:443 и все будет работать?
>
> Лучше, всё же в "дефолтном" `server {}`-блоке, который будет загружаться
> самым
> первым (т.е. либо дать ему такое имя, чтобы в алфавитном порядке при
> разыменовывании вайлдкарда оказался первым, либо в явном виде первым
> заинклудить.
>
> Плюс, лучше, всё же, в явном виде
> ```
> listen *:443
> listen [::]:443
> ```
> чтобы не надеяться на поведение "по умолчанию"
> ___
> 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: Пролагивание коннектов при проверке синтаксиса

[kpoxa]

Я правильно понимаю, что можно сделать один listen 443 в специально
сделанном сайте,
который по другому никак не будет использоваться, а во всех остальных
местах,
и в HTTP и в стримах оставить listen ip:443 и все будет работать?

ср, 14 нояб. 2018 г. в 15:59, Maxim Dounin :

> Hello!
>
> On Wed, Nov 14, 2018 at 11:45:03AM +0300, kpoxa wrote:
>
> > Сокеты в основном в stream, поэтому их агрегировать не получится, как я
> > понимаю, с  http то проблем нет.
>
> При наличии в конфиге listen-сокетов на wildcard-адресе и на
> конкретном ip-адресе - nginx будет использовать общий listen-сокет
> на wildcard-адресе, иначе на Linux'е просто нельзя работать.  Это
> работает как для http, так и для stream/mail.  Проблемы будут,
> только если один и тот же порт пытаться использовать в разных
> модулях.
>
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Пролагивание коннектов при проверке синтаксиса

[kpoxa]

Сокеты в основном в stream, поэтому их агрегировать не получится, как я
понимаю, с  http то проблем нет.

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

Основная проблема в долгом syscall bind, который долгий при определенных
обстоятельствах. И почему он долгий не понятно.
в strace видно время вызовов и видно, что для бинда по 443 порту оно в
сотни раз дольше, чем для других портов.

вт, 13 нояб. 2018 г. в 21:58, Maxim Dounin :

> Hello!
>
> On Tue, Nov 13, 2018 at 08:23:03PM +0300, kpoxa wrote:
>
> > Добрый день.
> >
> > Есть сервер (Dual Xeon E5620, средняя нагрузка проца в праймтайм 20%) с
> > nginx в главной и по сути единственной роли, задача которого
> проксирование
> > и больше ничего.
> >
> > В конфиге 101 listen на уникальные ip:port, nginx без сторонних модулей.
> > 1.15.4, но думаю что версия тут не при чем.
> > Debian Linux Jessy с ядром 3.16.
> >
> > В среднем одновременных коннектов открыто 150-200 тыс. 70% из них по 443
> > порту.
> > в логе собирается время отвремя апстрима и было замечено, то раз в 30
> > секунд оно пролагивает у части коннектов на лишнюю секунду, т.е. обычно
> > 0.01, а тут 1.01 сек.
> > Выяснилось что раз в 30 секунд срабатывает проверка конфига заббиксом,
> т.е.
> > вызывается
> > nginx -t
> >
> > Ручной вызов nginx -t привел к появлению в логах лагающих  запросов в это
> > время, выключение аббикс агента такие запросы убирает вообще.
> > команда
> > time nginx -t
> > nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> > nginx: configuration file /etc/nginx/nginx.conf test is successful
> > real0m0.601s
> > user0m0.044s
> > sys 0m0.432s
> > показывает 0.4 с лишним секунды в режиме ядра.
> > а попытка разобраться чем же занято ядра выдало ниже следующее
> >
> > strace -Ttt nginx -t 2>&1 | grep bind
> >
> > т.е. bind на 443 порты занимает 15 тысячных секунды, против стотысячных
> > долей у прочих биндов.
> >
> > Есть ли идеи, как решить проблему пролагиваний при проверке конфига?
> > Вариант убрать её из заббикса считаю академически неправильным, просьба
> его
> > не рассматривать.
> >
> > reuseport не используется, может он помочь?
>
> Из общих соображений я бы скорее предположил, что reuseport в
> данной ситуации сделает хуже, а не лучше.  Потому что сокетов
> станет только больше, а bind() должен проверить конфликты с
> открытыми сокетами.
>
> Очевидное решение - добавить listen на *:443, тогда listen-сокет
> будет один, и проблема исчезнет.
>
> Впрочем, запускать "nginx -t" раз в 30 секунд - это, скажем так,
> очень странное решение, если не сказать грубее.  Особенно с учётом
> того, что только парсинг конфигурации вполне может занимать
> несколько минут.
>
> --
> Maxim Dounin
> http://mdounin.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

Пролагивание коннектов при проверке синтаксиса

[kpoxa]

Добрый день.

Есть сервер (Dual Xeon E5620, средняя нагрузка проца в праймтайм 20%) с
nginx в главной и по сути единственной роли, задача которого проксирование
и больше ничего.

В конфиге 101 listen на уникальные ip:port, nginx без сторонних модулей.
1.15.4, но думаю что версия тут не при чем.
Debian Linux Jessy с ядром 3.16.

В среднем одновременных коннектов открыто 150-200 тыс. 70% из них по 443
порту.
в логе собирается время отвремя апстрима и было замечено, то раз в 30
секунд оно пролагивает у части коннектов на лишнюю секунду, т.е. обычно
0.01, а тут 1.01 сек.
Выяснилось что раз в 30 секунд срабатывает проверка конфига заббиксом, т.е.
вызывается
nginx -t

Ручной вызов nginx -t привел к появлению в логах лагающих  запросов в это
время, выключение аббикс агента такие запросы убирает вообще.
команда
time nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
real0m0.601s
user0m0.044s
sys 0m0.432s
показывает 0.4 с лишним секунды в режиме ядра.
а попытка разобраться чем же занято ядра выдало ниже следующее

strace -Ttt nginx -t 2>&1 | grep bind

т.е. bind на 443 порты занимает 15 тысячных секунды, против стотысячных
долей у прочих биндов.

Есть ли идеи, как решить проблему пролагиваний при проверке конфига?
Вариант убрать её из заббикса считаю академически неправильным, просьба его
не рассматривать.

reuseport не используется, может он помочь?


20:06:08.293194 bind(57, {sa_family=AF_INET, sin_port=htons(515),
sin_addr=inet_addr("192.168.72.55")}, 16) = -1 EADDRINUSE (Address already
in use) <0.13>
20:06:08.293372 bind(57, {sa_family=AF_INET, sin_port=htons(8186),
sin_addr=inet_addr("192.168.72.149")}, 16) = -1 EADDRINUSE (Address already
in use) <0.12>
20:06:08.293560 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.208")}, 16) = -1 EADDRINUSE (Address already
in use) <0.016715>
20:06:08.310458 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.149")}, 16) = -1 EADDRINUSE (Address already
in use) <0.015673>
20:06:08.326346 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.148")}, 16) = -1 EADDRINUSE (Address already
in use) <0.015727>
20:06:08.342292 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.214")}, 16) = -1 EADDRINUSE (Address already
in use) <0.015751>
20:06:08.358260 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.235")}, 16) = -1 EADDRINUSE (Address already
in use) <0.015733>
20:06:08.374236 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.230")}, 16) = -1 EADDRINUSE (Address already
in use) <0.015803>
20:06:08.390575 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.217")}, 16) = -1 EADDRINUSE (Address already
in use) <0.016433>
20:06:08.407377 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.213")}, 16) = -1 EADDRINUSE (Address already
in use) <0.016389>
20:06:08.423989 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.229")}, 16) = -1 EADDRINUSE (Address already
in use) <0.015756>
20:06:08.440013 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.239")}, 16) = -1 EADDRINUSE (Address already
in use) <0.015815>
20:06:08.456204 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.219")}, 16) = -1 EADDRINUSE (Address already
in use) <0.014685>
20:06:08.471140 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.212")}, 16) = -1 EADDRINUSE (Address already
in use) <0.016018>
20:06:08.487397 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.228")}, 16) = -1 EADDRINUSE (Address already
in use) <0.014647>
20:06:08.502250 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.222")}, 16) = -1 EADDRINUSE (Address already
in use) <0.014635>
20:06:08.517105 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.238")}, 16) = -1 EADDRINUSE (Address already
in use) <0.014834>
20:06:08.532162 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.220")}, 16) = -1 EADDRINUSE (Address already
in use) <0.014635>
20:06:08.547049 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.236")}, 16) = -1 EADDRINUSE (Address already
in use) <0.014566>
20:06:08.561946 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.221")}, 16) = -1 EADDRINUSE (Address already
in use) <0.015155>
20:06:08.577406 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.237")}, 16) = -1 EADDRINUSE (Address already
in use) <0.014706>
20:06:08.592334 bind(57, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("192.168.72.210")}, 16) = -1 EADDRINUSE (Address already
in use) 

Re: nginx long-polling, мультиплексирование соединений в upstream

[kpoxa]

Добрый день.

Сделайте эти соединения на отдельный ip:port
пт, 28 сент. 2018 г. в 16:04, vadv :
>
> Здравствуйте, All!
>
> Есть http1 клиенты, которые подключены по long-polling, сейчас это
> реализовано на nginx-push-stream-module.
> В силу разных причин, появилась необходимость вынести функционал
> long-polling из nginx, чтобы nginx проксировал соединения в некий upstream.
> Но при этом не хочется умножать x2 кол-во соединений, который делает nginx
> (1 коннект от клиента, 1 коннект в upstream).
>
> Как, не переписывая клиентов, можно замультиплексировать "клиентские"
> соединения в upstream уменьшив их кол-во?
>
> Posted at Nginx Forum: 
> https://forum.nginx.org/read.php?21,281436,281436#msg-281436
>
> ___
> 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

url escape в логах без внешних модулей

[kpoxa]

Добрый день.

Существует ли способ заполучить в лог заэкспкейпленные uri и referrer ?
Вариант с escape-json не то, что требуется, к сожалению.

PS. Не планируется ли функционал из модуля (или сам модуль)
https://github.com/openresty/set-misc-nginx-module добавить в nginx ?

--
Рустам
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Документация на вложенные location

[kpoxa]

В документации написано, что в / вкладывать нельзя

17 августа 2018 г., 13:34 пользователь mrpsycho
 написал:
> прошу простить за некрофилию но, документация появилась?
> очень уж непонятно зачем нужна эта вложенность, если нельзя написать что-то
> типа такого:
>
> location / {
> uwsgi_pass api_wsgi_server;
> include /etc/nginx/uwsgi_params;
>
> location api/auth2/login {
>   limit_req zone=reqzoneone;
> }
> }
>
> Posted at Nginx Forum: 
> https://forum.nginx.org/read.php?21,216689,280903#msg-280903
>
> ___
> 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

location vs map по скорость

[kpoxa]

Добрый день.

А что будет по скорости быстрее работать, при ограничении доступа к
определенным расширениям файлов (2-3 десятка расширений):

location ~* \.(ext1|ext2|ext3)$ {
deny all;
}
location / {
//access granted
}

или

map $uri $error {
 ~".ext1$" 403;
 ~".ext2$" 403;
 ~".ext3$" 403;
}
location / {
 if ($error = 403) {
return 403;
 }
}
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Переменная с именем файла на диске (фича реквест)

[kpoxa]

Да, реально мой косяк, чуть другой кейс пробовал.

--
Рустам

23 июня 2018 г., 17:14 пользователь Maxim Dounin  написал:
> Hello!
>
> On Fri, Jun 22, 2018 at 12:47:24PM +0300, kpoxa wrote:
>
>> Добрый день.
>>
>> В nginx сейчас нет переменной, которая бы содержала имя файла на диске
>> для локальных файлов.
>>
>> $request_filename не подходит, т.к. содержит в себе и GET параметры.
>
> Переменная $request_filename - не содержит в себе GET-параметры.
> Она содержит ровно то имя файла, которое nginx будет использовать
> при возврате ответа с диска.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Переменная с именем файла на диске (фича реквест)

[kpoxa]

Добрый день.

То, что параметр используется для пробивания кешей.


22 июня 2018 г., 15:38 пользователь Alex Vorona  написал:
> Здравствуйте,
>
> 22.06.18 12:47, kpoxa wrote:
>>
>> Добрый день.
>
> [...]
>>
>> $request_filename не подходит, т.к. содержит в себе и GET параметры.
>
>
> А что мешает отрезать параметры через regexp map ?
>
> --
> Alex Vorona
> ___
> 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

Переменная с именем файла на диске (фича реквест)

[kpoxa]

Добрый день.

В nginx сейчас нет переменной, которая бы содержала имя файла на диске
для локальных файлов.

$request_filename не подходит, т.к. содержит в себе и GET параметры.

Переменная нужна для фильтрации доступов, например, её было бы хорошо
использовать в map.

Сейчас единственный способ зафильтровать по расширению имени файла это
сделать location, но иногда этот способ сильно не удобен, т.к. вместо

map $real_name $my_access {
  "~.js$" 404;
 default 0;
}

server {
  location /111/ {
if ($my access) {}
  }
}

надо делать вложенные локейшены что сильно нагромождает конфиг

--
Рустам
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Развитие nginx

[kpoxa]

Добрый день.

Искал в интернете информацию о том, куда развивается сейчас nginx и нашел
страничку

https://trac.nginx.org/nginx/roadmap

Исходя из которой не понятно, что такое TBF, просьба рассказать о чем речь,
поиск по аббревиатуре не сильно помогает, самое близкое по смыслу было про
планировщик очередей трафика, но это не точно.

Просьба прояснить, что такое TBF, да и в целом интересно, куда развивается
nginx

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

Будет ли что-то придумано для ситуаций, когда надо сделать один сайт с
десятком различных доменных имён и ssl сертификатов?

Понятно, что фантазия может быть безграничной :)

--
Рустам
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

proxy_bind ipv4 & server ipv6

[kpoxa]

Добрый день.

Комбинация proxy_bind на ipv4 адрес с апстримом с адресом ipv6 даёт ошибку

[crit] 14852#14852: *21 bind(10.0.0.10) failed (22: Invalid argument) while
connecting to upstream

Т.к. у адрес сервера резолвился динамически, то ушло полчаса на то, чтобы
понять где ошибка, возможно более человекопонятная надпись была бы более
уместна.


---
Рустам Нарманов.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Некорректная работа при выведении сервера из апстрима за timeout

[kpoxa]

Добрый день.

nginx version: nginx/1.12.2

Кслассическая схема:

nginx - apache (10 серверов) - mysql

В случае перегрузки базы данных апач отвечает медленно, что логично.
Перестаёт отвечать nginx'у.
И как следствие nginx выводит сервер с апачом из работы. Соответственно
сервер начинает то включаться в работу то выключаться.

Далее наблюдается следующая картина, которая у вызывает у меня вопрос, у
апачей куча детей в статусе R, т.е. reading request.

strace на процесс Апача примерно такой:

accept(

пришел syn пакет и апач его принял

read(

ждём HTTP запрос от nginx в течении 60+ секунд.




не знаю в какой момент, но nginx открывает соединения, возможно до вывода
сервера из работы, а далее не отправляет на него запросы, как следствие
дети Апача заняты ожиданием запросов и апач в итоге не отвечают нормально.


--
Рустам Нарманов.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблема с поддержкой старых протоколов после обновления

[kpoxa]

В debian проблемы нет. У меня не воспроизводится с указанными настройками
ssl. Проверял на 8 и на 9 релизах дебиана.

13 октября 2017 г., 13:50 пользователь Gena Makhomed 
написал:

> On 13.10.2017 13:07, Максим Баштовой wrote:
>
> почему-то NGINX упорно хочет работать исключительно по TLSv1.2 протоколу,
 отвергая остальные

>>>
> Если взять дистрибутив nginx с официального сайта
>>> http://nginx.org/en/linux_packages.html#mainline
>>> проблема воспроизводится?
>>>
>>
> Установил с официального репозитория
>>
>
> nginx version: nginx/1.13.6
>> built by gcc 6.3.0 20170516 (Debian 6.3.0-18)
>> built with OpenSSL 1.1.0f  25 May 2017
>>
>
> Конфиг тот же, опять только TLSv1.2
>>
>
> Ясно. Значит проблема в Debian,
>
> https://lists.debian.org/debian-devel-announce/2017/08/msg4.html
>
> рекомендую перейти на CentOS 7.4 - там такие глюки отсутствуют.
>
> Если же хочется "в гамаке и стоя", тогда придется пересобирать nginx
> из исходников, используя OpenSSL библиотеку с https://www.openssl.org/
>
> --
> 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

Re: Proxy_cache

[kpoxa]

Проще сделать цепочки
nginx1-nginx2-backend
nginx2-nginx1-backend
так будет вычисление одноразовое и контент сразу будет на обоих кешах.
Только надо не забыть сделать так, что если с nginx1 не доступен nginx2, то
пусть он сам перезапрашивает у backend.
+ любой из множества вариантов проверки на зацикливание.

7 октября 2017 г., 15:43 пользователь Andrey Kopeyko 
написал:

> demolitionman писал 2017-10-07 14:46:
>
>> Доброго дня комрады! С Ngnix знаком неделю, сроки горят. Настраиваю связку
>> nginx+gunicorn+memcached+postgresql+Django
>> Уперся в одну задачу, пол дня ковыряю ни как решение найти не могу.
>> Задача такая есть два сервера nginx1 nginx2, необходимо что бы первый
>> сервер
>> кэшировал объекты (медиафайлы, картинки) на втором, а второй сервер
>> кэшировал на первом.
>> Как создать локальный кэш я разобрался, а как заставить кэшировать на
>> другой
>> машине ни как понять не могу,
>>
>
> А зачем? какую проблемы вы хотите этим решить?
>
> Обычно нет беды в том, что каждый из серверов будет держать свою копию
> кеша - ну да, бэкенды будут вычислять эти запросы дважды.
>
> Если это двойное вычисление для вас всё-таки дорого - придётся кеш
> усложнить: сервера будут кешировать не у себя, а проксировать на третий
> "центральный" кеш. А на случай его падения - бэкапом иметь свой локальный
> кеш, синхронизируемый rsync-ом с центрального.
>
> Только стандартными средствами nginx эта конструкция не реализуется, тут
> надо допрограммировать. Постучитель в личку, расскажу подробнее как это у
> нас во вьетнамском поиске делалось.
>
> Есть идея просто при монтировать диру с другого сервера. Но почему то
>> кажется что в Ngnix это делается по другому. Подскажите личным примером
>> либо
>> статьей из гугла.
>>
>> Posted at Nginx Forum:
>> https://forum.nginx.org/read.php?21,276756,276756#msg-276756
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
> --
> Best regards,
> Andrey A. Kopeyko 
> ___
> 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: Рост количества подключений в состоянии writing

[kpoxa]

Есть одно подозрение, не знаю, может ли об этого зависеть, но статистика
получилась такая -  проблема началась синхронного на 3 полностью
независимых серверах примерно за 18 дней до окончания истечения ssl
сертификата, и решилась синхронно с его продлением.

25 июля 2017 г., 15:38 пользователь kpoxa <kp...@kpoxa.net> написал:

> буферизация включена.
> приложение - отдача статики с ссд, причем вся отдаваемая статика это 1гб,
> а на сервере 16гб, так что она всегда в кеше дисковом.
> деградации каналов не было.
> На одном канале таких серверов 3 (раунд-робин днс распределяет нагрузку),
> повышение количества writing коннектов не синхронное, возникает
> спорадически. Если бы были пробелемы на канале, то проблемы были бы
> синхронные
>
> 24 июля 2017 г., 18:28 пользователь Илья Шипицин <chipits...@gmail.com>
> написал:
>
>> буферизация включена? (по умолчанию - включена).
>> деградация каналов в сторону пользователей была? деградация приложения?
>>
>> 24 июля 2017 г., 19:41 пользователь kpoxa <kp...@kpoxa.net> написал:
>>
>>> Добрый день.
>>>
>>> Запросы в статусу writing спонтанно пришло и спонтанно ушли, пикаких
>>> пиковых нагрузок не было.
>>>
>>> [image: Встроенное изображение 1]
>>>
>>> 24 июля 2017 г., 14:51 пользователь kpoxa <kp...@kpoxa.net> написал:
>>>
>>>> Добрый день.
>>>>
>>>> Та же проблема:
>>>> Active connections: 9995
>>>> server accepts handled requests
>>>>  213171 213171 1185236
>>>> Reading: 0 Writing: 8835 Waiting: 8702
>>>>
>>>>
>>>> На сервере нагрузка не менялась, нагрузка на проц 2-3%, памяти свободно
>>>> 10гб из 16гб, диск не нагружен вообще. Сеть нагружена на 7-10%.
>>>> Абсолютно в непредсказуемые моменты бывает сильно вырастают "Writing"
>>>> коннекты и сервер начинает тупить.
>>>>
>>>> nginx version: nginx/1.13.3
>>>> debian jessy
>>>>
>>>> listen 443 default_server backlog=32768 rcvbuf=4194304
>>>> sndbuf=16777216 reuseport ssl;# http2;
>>>> пробовал и с http2 и без, в обоих случаях writing большой.
>>>>
>>>>
>>>> 2 апреля 2017 г., 8:41 пользователь DK <koha...@gmail.com> написал:
>>>>
>>>>> Добрый день,
>>>>>
>>>>> Касательно этой проблемы, в логах тишина
>>>>>
>>>>> есть только ошибки от роботов
>>>>>
>>>>> 2017/04/02 07:50:37 [error] 8434#8434: *76017536
>>>>> "/etc/nginx/html/PMA2012/index.html" is not found (2: No such file or
>>>>> directory), client: 131.103.139.131, server: , request: "HEAD
>>>>> http://x.x.x.x:80/PMA2012/ HTTP/1.1", host: "x.x.x.x"
>>>>> 2017/04/02 07:50:37 [error] 8434#8434: *76017536
>>>>> "/etc/nginx/html/pma2012/index.html" is not found (2: No such file or
>>>>> directory), client: 131.103.139.131, server: , request: "HEAD
>>>>> http://x.x.x.x:80/pma2012/ HTTP/1.1", host: "x.x.x.x"
>>>>> 2017/04/02 07:50:37 [error] 8434#8434: *76017536
>>>>> "/etc/nginx/html/PMA2011/index.html" is not found (2: No such file or
>>>>> directory), client: 131.103.139.131, server: , request: "HEAD
>>>>> http://x.x.x.x:80/PMA2011/ HTTP/1.1", host: "x.x.x.x"
>>>>>
>>>>>
>>>>> и иногда возникают ошибки, что нет возможности переименовать файл
>>>>> (использую proxy_store)
>>>>>
>>>>> 2017/04/02 11:24:27 [crit] 8433#8433: *76159901 rename()
>>>>> "/var/www/virtual/x.ru/temp/330774" to "/var/www/virtual/
>>>>> x.ru/images/250s/lh3.googleusercontent
>>>>> .com/vy9kyUGvT6j3KlUNO1IsJbaFEYrvDGf7pWIe_VLHGci8IQ1vYgtXrU3
>>>>> X2HvGhzZMzmjYL0615aPpnqqA4NTKTKiag_hGmK0yO4Em0NHwQqRikcM07uh
>>>>> 89KASsLLq9W2XFoOHyg9KsZYbjsAPmzSMUoem2VuI02bWwUF71sJn3v2uBnj
>>>>> -aRu843Fxh0E7iokVNXyoiEesIQfIlAGeN8Fe6nRtY5GFcpyjV1brXuTvW-7lpEd"
>>>>> failed (36: File name too long) while reading upstream, client:
>>>>> x.x.203.204, server: xxx,
>>>>>
>>>>>
>>>>> но обе эти ошибки были и на предыдущей версии nginx (точно не помню,
>>>>> но была версия в районе 0.9.8 ).
>>>>>
>>>>> Проблемная инсталяция работает как кеширующий сервер для раздачи

Re: Рост количества подключений в состоянии writing

[kpoxa]

буферизация включена.
приложение - отдача статики с ссд, причем вся отдаваемая статика это 1гб, а
на сервере 16гб, так что она всегда в кеше дисковом.
деградации каналов не было.
На одном канале таких серверов 3 (раунд-робин днс распределяет нагрузку),
повышение количества writing коннектов не синхронное, возникает
спорадически. Если бы были пробелемы на канале, то проблемы были бы
синхронные

24 июля 2017 г., 18:28 пользователь Илья Шипицин <chipits...@gmail.com>
написал:

> буферизация включена? (по умолчанию - включена).
> деградация каналов в сторону пользователей была? деградация приложения?
>
> 24 июля 2017 г., 19:41 пользователь kpoxa <kp...@kpoxa.net> написал:
>
>> Добрый день.
>>
>> Запросы в статусу writing спонтанно пришло и спонтанно ушли, пикаких
>> пиковых нагрузок не было.
>>
>> [image: Встроенное изображение 1]
>>
>> 24 июля 2017 г., 14:51 пользователь kpoxa <kp...@kpoxa.net> написал:
>>
>>> Добрый день.
>>>
>>> Та же проблема:
>>> Active connections: 9995
>>> server accepts handled requests
>>>  213171 213171 1185236
>>> Reading: 0 Writing: 8835 Waiting: 8702
>>>
>>>
>>> На сервере нагрузка не менялась, нагрузка на проц 2-3%, памяти свободно
>>> 10гб из 16гб, диск не нагружен вообще. Сеть нагружена на 7-10%.
>>> Абсолютно в непредсказуемые моменты бывает сильно вырастают "Writing"
>>> коннекты и сервер начинает тупить.
>>>
>>> nginx version: nginx/1.13.3
>>> debian jessy
>>>
>>> listen 443 default_server backlog=32768 rcvbuf=4194304
>>> sndbuf=16777216 reuseport ssl;# http2;
>>> пробовал и с http2 и без, в обоих случаях writing большой.
>>>
>>>
>>> 2 апреля 2017 г., 8:41 пользователь DK <koha...@gmail.com> написал:
>>>
>>>> Добрый день,
>>>>
>>>> Касательно этой проблемы, в логах тишина
>>>>
>>>> есть только ошибки от роботов
>>>>
>>>> 2017/04/02 07:50:37 [error] 8434#8434: *76017536
>>>> "/etc/nginx/html/PMA2012/index.html" is not found (2: No such file or
>>>> directory), client: 131.103.139.131, server: , request: "HEAD
>>>> http://x.x.x.x:80/PMA2012/ HTTP/1.1", host: "x.x.x.x"
>>>> 2017/04/02 07:50:37 [error] 8434#8434: *76017536
>>>> "/etc/nginx/html/pma2012/index.html" is not found (2: No such file or
>>>> directory), client: 131.103.139.131, server: , request: "HEAD
>>>> http://x.x.x.x:80/pma2012/ HTTP/1.1", host: "x.x.x.x"
>>>> 2017/04/02 07:50:37 [error] 8434#8434: *76017536
>>>> "/etc/nginx/html/PMA2011/index.html" is not found (2: No such file or
>>>> directory), client: 131.103.139.131, server: , request: "HEAD
>>>> http://x.x.x.x:80/PMA2011/ HTTP/1.1", host: "x.x.x.x"
>>>>
>>>>
>>>> и иногда возникают ошибки, что нет возможности переименовать файл
>>>> (использую proxy_store)
>>>>
>>>> 2017/04/02 11:24:27 [crit] 8433#8433: *76159901 rename()
>>>> "/var/www/virtual/x.ru/temp/330774" to "/var/www/virtual/
>>>> x.ru/images/250s/lh3.googleusercontent
>>>> .com/vy9kyUGvT6j3KlUNO1IsJbaFEYrvDGf7pWIe_VLHGci8IQ1vYgtXrU3
>>>> X2HvGhzZMzmjYL0615aPpnqqA4NTKTKiag_hGmK0yO4Em0NHwQqRikcM07uh
>>>> 89KASsLLq9W2XFoOHyg9KsZYbjsAPmzSMUoem2VuI02bWwUF71sJn3v2uBnj
>>>> -aRu843Fxh0E7iokVNXyoiEesIQfIlAGeN8Fe6nRtY5GFcpyjV1brXuTvW-7lpEd"
>>>> failed (36: File name too long) while reading upstream, client:
>>>> x.x.203.204, server: xxx,
>>>>
>>>>
>>>> но обе эти ошибки были и на предыдущей версии nginx (точно не помню, но
>>>> была версия в районе 0.9.8 ).
>>>>
>>>> Проблемная инсталяция работает как кеширующий сервер для раздачи
>>>> статики. При обращении к нему он смотрит есть такой файл или нет, если
>>>> файла нет то забирает файл с главного сервера и сохраняет его себе
>>>> (proxy_store).
>>>>
>>>> У инсталяции (на другом сервере) которая работает как обычный фронт-энд
>>>> перед апачем, такой проблемы нет. Версия ОС, настройки ОС и версии nginx
>>>> везде одинаковые.
>>>>
>>>>
>>>> PS: По глупости подписался в режиме дайджеста (уже изменил), поэтому
>>>> не могу ответить на индивидуальные письма, поэтому отвечаю сам себе
>>>

Re: Рост количества подключений в состоянии writing

[kpoxa]

Добрый день.

Запросы в статусу writing спонтанно пришло и спонтанно ушли, пикаких
пиковых нагрузок не было.

[image: Встроенное изображение 1]

24 июля 2017 г., 14:51 пользователь kpoxa <kp...@kpoxa.net> написал:

> Добрый день.
>
> Та же проблема:
> Active connections: 9995
> server accepts handled requests
>  213171 213171 1185236
> Reading: 0 Writing: 8835 Waiting: 8702
>
>
> На сервере нагрузка не менялась, нагрузка на проц 2-3%, памяти свободно
> 10гб из 16гб, диск не нагружен вообще. Сеть нагружена на 7-10%.
> Абсолютно в непредсказуемые моменты бывает сильно вырастают "Writing"
> коннекты и сервер начинает тупить.
>
> nginx version: nginx/1.13.3
> debian jessy
>
> listen 443 default_server backlog=32768 rcvbuf=4194304
> sndbuf=16777216 reuseport ssl;# http2;
> пробовал и с http2 и без, в обоих случаях writing большой.
>
>
> 2 апреля 2017 г., 8:41 пользователь DK <koha...@gmail.com> написал:
>
>> Добрый день,
>>
>> Касательно этой проблемы, в логах тишина
>>
>> есть только ошибки от роботов
>>
>> 2017/04/02 07:50:37 [error] 8434#8434: *76017536
>> "/etc/nginx/html/PMA2012/index.html" is not found (2: No such file or
>> directory), client: 131.103.139.131, server: , request: "HEAD
>> http://x.x.x.x:80/PMA2012/ HTTP/1.1", host: "x.x.x.x"
>> 2017/04/02 07:50:37 [error] 8434#8434: *76017536
>> "/etc/nginx/html/pma2012/index.html" is not found (2: No such file or
>> directory), client: 131.103.139.131, server: , request: "HEAD
>> http://x.x.x.x:80/pma2012/ HTTP/1.1", host: "x.x.x.x"
>> 2017/04/02 07:50:37 [error] 8434#8434: *76017536
>> "/etc/nginx/html/PMA2011/index.html" is not found (2: No such file or
>> directory), client: 131.103.139.131, server: , request: "HEAD
>> http://x.x.x.x:80/PMA2011/ HTTP/1.1", host: "x.x.x.x"
>>
>>
>> и иногда возникают ошибки, что нет возможности переименовать файл
>> (использую proxy_store)
>>
>> 2017/04/02 11:24:27 [crit] 8433#8433: *76159901 rename()
>> "/var/www/virtual/x.ru/temp/330774" to "/var/www/virtual/
>> x.ru/images/250s/lh3.googleusercontent.com/vy9kyUGvT6j3KlUNO1IsJbaFE
>> YrvDGf7pWIe_VLHGci8IQ1vYgtXrU3X2HvGhzZMzmjYL0615aPpnqqA4NTKT
>> Kiag_hGmK0yO4Em0NHwQqRikcM07uh89KASsLLq9W2XFoOHyg9KsZYbjsAPm
>> zSMUoem2VuI02bWwUF71sJn3v2uBnj-aRu843Fxh0E7iokVNXyoiEesIQfIl
>> AGeN8Fe6nRtY5GFcpyjV1brXuTvW-7lpEd" failed (36: File name too long)
>> while reading upstream, client: x.x.203.204, server: xxx,
>>
>>
>> но обе эти ошибки были и на предыдущей версии nginx (точно не помню, но
>> была версия в районе 0.9.8 ).
>>
>> Проблемная инсталяция работает как кеширующий сервер для раздачи статики.
>> При обращении к нему он смотрит есть такой файл или нет, если файла нет то
>> забирает файл с главного сервера и сохраняет его себе (proxy_store).
>>
>> У инсталяции (на другом сервере) которая работает как обычный фронт-энд
>> перед апачем, такой проблемы нет. Версия ОС, настройки ОС и версии nginx
>> везде одинаковые.
>>
>>
>> PS: По глупости подписался в режиме дайджеста (уже изменил), поэтому  не
>> могу ответить на индивидуальные письма, поэтому отвечаю сам себе
>>
>>
>>
>> 1 апреля 2017 г., 11:36 пользователь DK <koha...@gmail.com> написал:
>>
>>> Добрый день,
>>>
>>> В начале марта обновил nginx до версии nginx-1.11.10-1.el7.ngx.x86_64 и
>>> заметил, что постепенно растет количество подключений в состоянии writing
>>>
>>> http://take.ms/p541u
>>>
>>> Куда смотреть, чтобы найти причину такого роста?
>>>
>>> PS: Падение количества подключения - это последствия добавление второго
>>> сервера в качестве фронтенда и балансировки трафика через DNS.
>>>
>>
>>
>> ___
>> 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: Рост количества подключений в состоянии writing

[kpoxa]

Добрый день.

Та же проблема:
Active connections: 9995
server accepts handled requests
 213171 213171 1185236
Reading: 0 Writing: 8835 Waiting: 8702


На сервере нагрузка не менялась, нагрузка на проц 2-3%, памяти свободно
10гб из 16гб, диск не нагружен вообще. Сеть нагружена на 7-10%.
Абсолютно в непредсказуемые моменты бывает сильно вырастают "Writing"
коннекты и сервер начинает тупить.

nginx version: nginx/1.13.3
debian jessy

listen 443 default_server backlog=32768 rcvbuf=4194304
sndbuf=16777216 reuseport ssl;# http2;
пробовал и с http2 и без, в обоих случаях writing большой.


2 апреля 2017 г., 8:41 пользователь DK  написал:

> Добрый день,
>
> Касательно этой проблемы, в логах тишина
>
> есть только ошибки от роботов
>
> 2017/04/02 07:50:37 [error] 8434#8434: *76017536 
> "/etc/nginx/html/PMA2012/index.html"
> is not found (2: No such file or directory), client: 131.103.139.131,
> server: , request: "HEAD http://x.x.x.x:80/PMA2012/ HTTP/1.1", host:
> "x.x.x.x"
> 2017/04/02 07:50:37 [error] 8434#8434: *76017536 
> "/etc/nginx/html/pma2012/index.html"
> is not found (2: No such file or directory), client: 131.103.139.131,
> server: , request: "HEAD http://x.x.x.x:80/pma2012/ HTTP/1.1", host:
> "x.x.x.x"
> 2017/04/02 07:50:37 [error] 8434#8434: *76017536 
> "/etc/nginx/html/PMA2011/index.html"
> is not found (2: No such file or directory), client: 131.103.139.131,
> server: , request: "HEAD http://x.x.x.x:80/PMA2011/ HTTP/1.1", host:
> "x.x.x.x"
>
>
> и иногда возникают ошибки, что нет возможности переименовать файл
> (использую proxy_store)
>
> 2017/04/02 11:24:27 [crit] 8433#8433: *76159901 rename() "/var/www/virtual/
> x.ru/temp/330774" to "/var/www/virtual/x.ru/images/250s/lh3.
> googleusercontent.com/vy9kyUGvT6j3KlUNO1IsJbaFEYrvDGf7pWIe_
> VLHGci8IQ1vYgtXrU3X2HvGhzZMzmjYL0615aPpnqqA4NTKTKiag_
> hGmK0yO4Em0NHwQqRikcM07uh89KASsLLq9W2XFoOHyg9KsZYbjsAPmzSMUo
> em2VuI02bWwUF71sJn3v2uBnj-aRu843Fxh0E7iokVNXyoiEesIQfIlA
> GeN8Fe6nRtY5GFcpyjV1brXuTvW-7lpEd" failed (36: File name too long) while
> reading upstream, client: x.x.203.204, server: xxx,
>
>
> но обе эти ошибки были и на предыдущей версии nginx (точно не помню, но
> была версия в районе 0.9.8 ).
>
> Проблемная инсталяция работает как кеширующий сервер для раздачи статики.
> При обращении к нему он смотрит есть такой файл или нет, если файла нет то
> забирает файл с главного сервера и сохраняет его себе (proxy_store).
>
> У инсталяции (на другом сервере) которая работает как обычный фронт-энд
> перед апачем, такой проблемы нет. Версия ОС, настройки ОС и версии nginx
> везде одинаковые.
>
>
> PS: По глупости подписался в режиме дайджеста (уже изменил), поэтому  не
> могу ответить на индивидуальные письма, поэтому отвечаю сам себе
>
>
>
> 1 апреля 2017 г., 11:36 пользователь DK  написал:
>
>> Добрый день,
>>
>> В начале марта обновил nginx до версии nginx-1.11.10-1.el7.ngx.x86_64 и
>> заметил, что постепенно растет количество подключений в состоянии writing
>>
>> http://take.ms/p541u
>>
>> Куда смотреть, чтобы найти причину такого роста?
>>
>> PS: Падение количества подключения - это последствия добавление второго
>> сервера в качестве фронтенда и балансировки трафика через DNS.
>>
>
>
> ___
> 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: Не работает map c переменными $status и $upstream status

[kpoxa]

По умолчанию nginx кеширует только 200 301 и 302, при желании для 301 и 302
можно поставить время кеширования в 1 секунду, чем не вариант?

ср, 3 авг. 2016 г. в 12:08, YuriV :

> Dmitry Ivanov
>
> У Netscaler'a слабая сторона - кэширование. Да и лицухи нет у нас нет для
> этого. Чем nginx его легко уделывает - это возможностью легко и быстро
> закэшировать ответы без писанины страшных конструкций :). Но вот заподлянка
> с невозможностью кэшировать только определённый респонз на nginx убивает...
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,268696,268711#msg-268711
>
> ___
> 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: Несколько доменов с SSL

[kpoxa]

Часто это неудобно, хочется единым конфигом и без инклюдов.

ср, 25 мая 2016 г. в 18:00, Юрий <russj...@gmail.com>:

> каждый сайт - свой конфиг. Проверенная и рабочая годами схема - достаточно
> производительно.
>
> 25 мая 2016 г., 16:35 пользователь kpoxa <kp...@kpoxa.net> написал:
>
>> Добрый день.
>>
>> А как лучше описать несколько доменов с SSL для одного сервера?
>>
>> --
>> Рустам
>>
>> ___
>> 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

Несколько доменов с SSL

[kpoxa]

Добрый день.

А как лучше описать несколько доменов с SSL для одного сервера?

--
Рустам
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Зависание nginx из-за memcached

[kpoxa]

Нужные урлы пропустите через промежуточный nginx последней версии, который
уже будет коннектиться к мемкешу.

пн, 23 мая 2016 г. в 16:16, Vadim Osipov :

> А как провести без сторонних модулей ? :)
> Запустить на production, убрав нужные url-ы ?
>
> Если имеется в виду проводить эксперимент на тестовом стенде, то выходит,
> что достаточное кол-во подключений, запросов, машин, стендов, их параметры
> вряд ли получится достоверно воспроизвести, но возможно не это главное, а
> то, как воспроизвести segfault на memcached, чтобы он в свою очередь стал
> причиной для nginx. А на сколько мне известно, у memcached нету, как у
> redis, такой способности.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,267049,267058#msg-267058
>
> ___
> 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: переменные в map -> proxy_pass

[kpoxa]

Резолвер должен резольвить то, что не может nginx разрезольвить.


вт, 26 апр. 2016 г. в 9:39, Den Bozhok <undyin...@yandex.ru>:

> Жаль, без ответа.
>
> 11.04.2016, 19:15, "Den Bozhok" <undyin...@yandex.ru>:
> > Благодарю за ответ!
> > Однако, резолвер описан, и все-равно ошибка присутствует:
> >
> >> resolver 10.1.1.5 10.1.1.4  valid=10s;
> >> resolver_timeout 5s;
> >
> > 11.04.2016, 18:53, "kpoxa" <kp...@kpoxa.net>:
> >> В конфиге опишите резолвер.
> http://nginx.org/ru/docs/http/ngx_http_core_module.html#resolver
> >>
> >>  пн, 11 апр. 2016 г. в 18:04, Den Bozhok <undyin...@yandex.ru>:
> >>> Доброго дня!
> >>>
> >>> Попробовал использовать map для выбора бэкенда, что бы затем
> передавать ее в proxy_pass, но при передаче переменной в proxy_pass nginx
> не может ее разрезолвить в итоговое значение.
> >>>
> >>> конфигурация:
> >>>
> >>>> geo $backend1 {
> >>>> default "long-host-name1.com";
> >>>> }
> >>>> geo $backend2 {
> >>>> default "long-host-name2.com";
> >>>> }
> >>>>
> >>>> map $http_x_backend $backend {
> >>>> "host1" $backend1;
> >>>> "host2" $backend2;
> >>>> }
> >>>>
> >>>> server {
> >>>> listen 80;
> >>>>
> >>>> location / {
> >>>> proxy_pass http://$backend;
> >>>> }
> >>>> }
> >>>
> >>> При этом я получаю ошибку:
> >>> $backend could not be resolved (2: Server failure)
> >>>
> >>> Я что-то делаю не так или у nginx нет такой возможности?
> >>> Благодарю!
> >>>
> >>> nginx -V
> >>> nginx version: nginx/1.9.10
> >>> 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:
> >>> --with-ld-opt=-Wl,-rpath,/usr/local/lib
> >>> --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-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
> >>> --http-proxy-temp-path=/var/cache/nginx/proxy_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-stream_ssl_module
> >>> --with-http_realip_module
> >>> --with-http_addition_module
> >>> --with-http_gunzip_module
> >>> --with-http_gzip_static_module
> >>> --with-http_v2_module
> >>> --with-threads
> >>> --with-http_geoip_module
> >>> --with-ipv6
> >>> --with-http_stub_status_module
> >>> --add-module=/opt/ngx_devel_kit-0.2.19
> >>> --add-module=/opt/lua-nginx-module-0.10.0
> >>>
> >>> ___
> >>> 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

Re: переменные в map -> proxy_pass

[kpoxa]

В конфиге опишите резолвер.
http://nginx.org/ru/docs/http/ngx_http_core_module.html#resolver

пн, 11 апр. 2016 г. в 18:04, Den Bozhok :

> Доброго дня!
>
> Попробовал использовать map для выбора бэкенда, что бы затем передавать ее
> в proxy_pass, но при передаче переменной в proxy_pass nginx не может ее
> разрезолвить в итоговое значение.
>
> конфигурация:
>
>
> geo $backend1 {
> default "long-host-name1.com";
> }
> geo $backend2 {
> default "long-host-name2.com";
> }
>
> map $http_x_backend $backend {
> "host1" $backend1;
> "host2" $backend2;
> }
>
> server {
> listen 80;
>
> location / {
> proxy_pass http://$backend;
> }
> }
>
>
> При этом я получаю ошибку:
> $backend could not be resolved (2: Server failure)
>
> Я что-то делаю не так или у nginx нет такой возможности?
> Благодарю!
>
> nginx -V
> nginx version: nginx/1.9.10
> 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:
> --with-ld-opt=-Wl,-rpath,/usr/local/lib
> --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-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
> --http-proxy-temp-path=/var/cache/nginx/proxy_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-stream_ssl_module
> --with-http_realip_module
> --with-http_addition_module
> --with-http_gunzip_module
> --with-http_gzip_static_module
> --with-http_v2_module
> --with-threads
> --with-http_geoip_module
> --with-ipv6
> --with-http_stub_status_module
> --add-module=/opt/ngx_devel_kit-0.2.19
> --add-module=/opt/lua-nginx-module-0.10.0
>
> ___
> 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: reverse proxy + mysql + video

[kpoxa]

В целом оффтопик, вопрос не по nginx, давайте закругляться.

ср, 6 апр. 2016 г. в 12:15, Андрей Василишин :

> 02.04.2016 22:34, tepkuh пишет:
> > Под "убиванием файла" имелось ввиду пропадание сетевой файловой системы в
> > связи с сетевым лагом
> >
>
> А зачем вообще использовать сетевые ФС?
>
> ___
> 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: reverse proxy + mysql + video

[kpoxa]

Отдача с базы это
ос читает с диска в буфер, буфер копируется в процесс mysql, mysql
отправляет это в сеть, т.е. копирование в ОС, потом в сеть, потом в скрипт,
который далее по сети отдает данные в nginx, т.е. копирование в буфер, в
сетевой стэк, потом опять в буфер, потом в nginx который отдаёт данные по
сети клиенту ( не буду расписывать).
Отдача с диска это
ос читает с диска в буфер и отдает по сети клиенту, т.к. используется
sendfile и копирования в память nginx  не происходит.
по моему профит очевиден.
с учетом того, что видео это не мелкие картинки, то оверхед на чтение
файловой системы намного меньше в % соотношении к операциям чтения данных.

вт, 5 апр. 2016 г. в 11:50, Daniel Podolsky :

> > может я что то пропустил, но какой смысл хранить данные в реляционной БД,
> > если вы не будете использовать при этом SQL?
> ну какой-то язык/api использовать придется.
>
> а ответ на вопрос "какой смысл" прямо вытекает из ответ на "в чем разница"
> ___
> 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.9.10

[kpoxa]

Добрый день.

Поясните алгоритм работы worker_cpu_affinity auto, привязываются процессы
по порядку по одному на ядро?

26 января 2016 г., 19:31 пользователь Maxim Dounin 
написал:

> Изменения в nginx 1.9.10
> 26.01.2016
>
> *) Безопасность: при использовании директивы resolver во время
> обработки
>ответов DNS-сервера могло происходить разыменование некорректного
>адреса, что позволяло атакующему, имеющему возможность подделывать
>UDP-пакеты от DNS-сервера, вызвать segmentation fault в рабочем
>процессе (CVE-2016-0742).
>
> *) Безопасность: при использовании директивы resolver во время
> обработки
>CNAME-записей могло произойти обращение к ранее освобождённой
> памяти,
>что позволяло атакующему, имеющему возможность инициировать
>преобразование произвольных имён в адреса, вызвать segmentation
> fault
>в рабочем процессе, а также потенциально могло иметь другие
>последствия (CVE-2016-0746).
>
> *) Безопасность: при использовании директивы resolver во время
> обработки
>CNAME-записей не во всех случаях проверялось ограничение на
>максимальное количество записей в цепочке, что позволяло атакующему,
>имеющему возможность инициировать преобразование произвольных имён в
>адреса, вызвать чрезмерное потребление ресурсов рабочими процессами
>(CVE-2016-0747).
>
> *) Добавление: параметр auto директивы worker_cpu_affinity.
>
> *) Исправление: параметр proxy_protocol директивы listen не работал с
>IPv6 listen-сокетами.
>
> *) Исправление: при использовании директивы keepalive соединения к
>бэкендам могли кэшироваться некорректно.
>
> *) Исправление: после перенаправления запроса с помощью
> X-Accel-Redirect
>при проксировании использовался HTTP-метод оригинального запроса.
>
>
> --
> 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

Follow redirect

[kpoxa]

Добрый день.

Яндексовский эллиптик с проксей в виде backrunner  не умеет обрабатывать
range реквесты самостоятельно и для этого рекомендуют использовать метод
redirect и модуль к nginx (подробнее вот тут
http://doc.reverbrain.com/elliptics:streaming-tutorial#configuration )

В итоге делается proxy_pass на backrunner который возвращает 301 редирект
который транслируется клиенту, а надо бы, в данном случае, обработать
полученный URL как X-Accell-Redirect
что-то мне не пришло в голову, как это лучше сделать, подскажите вариант.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: auth request контроль числа прошедих авторизацию

[kpoxa]

Добрый день.

С точки зрения nginx вы ему передаете или код 200, или 401 и всё, больше ни
о чем nginx не знает, как вы сами сделаете авторизацию в сервисе, так и
будет. Можете запоминать IP адрес, ставить куку, ставить срок жизни в 5
минут и все что душе угодно.

20 ноября 2015 г., 0:37 пользователь Magikanin 
написал:

> Максим, благодарю за ответ.
>
> Авторизационный сервис мне доступен.
> Сейчас у меня сервер авторизации выглядит как apache+mod_php.
> И на нем только один скрипт (для тестов):
>  if (!isset($_SERVER['PHP_AUTH_USER'])) {
> header('WWW-Authenticate: Basic realm="My Realm"');
> header('HTTP/1.0 401 Unauthorized');
> } else {
> header('HTTP/1.0 200 Ok');
> }
> ?>
> с п.1 я понял, что это будет проверять сервер авторизации (в некой базе
> ставить пометку о том, что пользователь залогинился), но как снимать
> пометку, когда пользователь закрыл браузер? каким механизмом nginx узнает
> об
> этом?
> а как авторизованного пользователя сбросить если он не закрыл браузер?
> ведь  /auth уже вернул код 200. и дальше работа идет с backend. Или /auth
> возвращает 200 при каждом запросе к nginx от данного пользователя (просто
> после 1 ввода ответ гдето кешируется на сервере авторизации)?
> Если можно, расскажите подробне про возможный механизм взаимодействия
> сервера авторизации с nginx в моей задаче.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,262954,262975#msg-262975
>
> ___
> 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

proxy_bind, макросы и др

[kpoxa]

Добрый день.

proxy_bind в модуле stream не поддерживает работу с переменными, как и
proxy_pass, что хотелось бы иметь использовать, например для ав тестов,
определить переменную и через нее определять или куда отправлять коннект,
или с какого адреса, иногда для тестов этого хватает.

В конфигах nginx часто приходится повторять одинаковые куски конфига,
например выбор апстрима по локейшену, с настройках пропускаемых заголовков,
что порождает большие конфиги или такого вида:

location /one/ {
 proxy_pass http://one;
 proxy_set_header ...
 
 
 access_log one.log;
}

location /two/ {
 proxy_pass http://one;
 proxy_set_header ...
 
 
 access_log one.log;
}

или такого
location /one/ {
  include one.conf;
}
location /two/ {
  include one.conf;
}

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


у меня есть два предложения, как можно синтаксически это реализовать по
другому, первый вариант это директива
location_list (
  /one/
  /two/
) {
 proxy_pass http://one;
 proxy_set_header ...
 
 
 access_log one.log;

}

второй это явная возможность вызова именованных локейшенов, например
location @one {
 proxy_pass http://one;
 proxy_set_header ...
 
 
 access_log one.log;
}
location /one/ {
  go @one;
}

location /two/ {
  go @one;
}


буду рад комментам и разумной критике :)
---
Рустам Нарманов.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблемы с бэкэндом на http2

[kpoxa]

Добрый день.

Решение о не поддержке http2 мне кажется логичным, ведь по всем
исследованиям spdy и http2 выигрыш тем больше, чем выше rtt, а в локалке
он, как правило, очень низкий, кроме того я не совсем представляю, как в
http2 проксировать соединения разных внешних клиентов, например у каждого
будут свои авторизационные данные.

19 октября 2015 г., 15:56 пользователь Pavel Odintsov <
pavel.odint...@gmail.com> написал:

> Приветствую!
>
> Спасибо за ответ!
>
> Но проблема несколько шире. Уже много фреймфорков написанных чисто на
> http 2.0 (gRPC - и это только начало), которые не содержат большого
> количества ненужного кода для поддержки http 1.1 просто потому что он
> не нужен и смысла в нем минимум.
>
> Отсутствие поддержки http2 со стороны бэкэнда в среде, где с клиентам
> уже можно общаться по http2 будет тормомзом прогресса, потому что мы
> не можем использовать везде http2 и исключительно из-за прихоти
> реверс-прокси должны тыщить http2.
>
> Я за унификацию :) Скорее вижу подход, где между бэкэндом и реверс
> прокси бегает http2, а также во всей внутренней инфраструктуре и
> силами реверс прокси это дело понижается до особо не продвинутых
> внешних клиентов.
>
> Но схему наоборот - http2 до публичного клиента и древний http 1.1 в
> бэнбоне не вяжется, не нравится мне это.
>
>
>
> 2015-10-19 15:50 GMT+03:00 Maxim Dounin :
> > Hello!
> >
> > On Sun, Oct 18, 2015 at 09:58:20PM +0300, Pavel Odintsov wrote:
> >
> >> Всем привет!
> >>
> >> Имеется сервер gRPC на С++, который работает только поверх
> >> шифрованного HTTP2. Имеется желание его проксировать силами Nginx для
> >> повышения надежности и реверс-проксирования.
> >>
> >> Суть в том, что Nginx должен общаться с gRPC бэкэндом только по
> >> HTTP2/TLS, иначе оно не работает.
> >>
> >> Но Nginx не может подключиться к http2 бэкэнду вот с такой ошибкой:
> >> 2015/10/18 20:54:07 [error] 2954#2954: *3 peer closed connection in
> >> SSL handshake while SSL handshaking to upstream, client: 127.0.0.1,
> >> server: api.fastnetmon.io, request: "POST
> >> /fastmitigation.Fastnetmon/GetBanlist HTTP/2.0", upstream:
> >> "https://127.0.0.1:10777/fastmitigation.Fastnetmon/GetBanlist;, host:
> >> "api.fastnetmon.io:443"
> >
> > [...]
> >
> > Just for the record:
> >
> > Разгадка в том, что поддержки HTTP/2 в proxy - нет и не
> > планируется.
> >
> > Основное преимущество SPDY и HTTP/2 перед HTTP - это больший
> > параллелизм при меньших затратах на установление соединений (одно
> > соединение, в нём много запросов одновременно). При работе с
> > бекендом - с тем же успехом можно поддерживать нужное количество
> > HTTP-соединений, разницы по latency - не будет, по throughput -
> > обычный HTTP будет лучше, выигрыш HTTP/2 - только по ресурсам на
> > уровне ядра (меньше сокетов).  И чтобы этот выигрыш получить -
> > надо переписать работу с upstream'ами чуть менее, чем полностью,
> > добавив поддержку мультиплексирования нескольких запросов в одном
> > соединении.  Смысла тратить на это силы и время - очень мало.
> >
> > --
> > Maxim Dounin
> > http://nginx.org/
> >
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
> --
> Sincerely yours, Pavel Odintsov
> ___
> 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: Проблемы с бэкэндом на http2

[kpoxa]

Кстати да, как это так, анти-ддос между фронтом и бэкэндом?

19 октября 2015 г., 19:18 пользователь denis 
написал:

> 19.10.2015 17:25, Evgeniy Berdnikov пишет:
>
>> Это имеет смысл лишь
>>   для клиентов с большим rtt до сервера. В локалке, между фронтэндом
>>   и бэкендом при малых rtt, даёт лишь бессмысленные накладные расходы,
>>   в том числе на шифрование, если оно есть.
>>
> У топикстартера речь шла о случаях, когда rtt модет быть большим, в
> частности когда сам бэкенд находится далеко и бегает через всякие анти-ддосы
>
> ___
> 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: Ограничение на число исходящих соединений

[kpoxa]

Добрый день.

Возможно есть какие-то другие параметры.

15 октября 2015 г., 11:54 пользователь Evgeniy Berdnikov <b...@protva.ru>
написал:

> On Thu, Oct 15, 2015 at 11:41:10AM +0300, kpoxa wrote:
> > все это можно сделать, но решение костыльное, использовать опцию
> reuseport
> > или  reuseaddr при коннекте к такому бэкэнду логичнее.
>
>  Эти опции не имеют отношения к обсуждаемой проблеме. Они относятся к
>  деталям того, как процессы делят адресное пространство прослушивающих
>  сокетов. А слушающие tcp-сокеты занимают часть с dst_ip=0.0.0.0 и
>  dst_port=0, эта часть не пересекается с подпространством параметров
>  сконнекченных сокетов.
> --
>  Eugene Berdnikov
>
> ___
> 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: Ограничение на число исходящих соединений

[kpoxa]

все это можно сделать, но решение костыльное, использовать опцию reuseport
или  reuseaddr при коннекте к такому бэкэнду логичнее.

15 октября 2015 г., 11:05 пользователь Evgeniy Berdnikov <b...@protva.ru>
написал:

> On Thu, Oct 15, 2015 at 09:30:09AM +0300, kpoxa wrote:
> > Да, я не прав, однако не всегда есть возможность убедить бэкэнд слушать
> два
> > или более портов.
>
>  Вряд ли бэкенд, которому нужно более 65 тысяч коннектов одновременно,
>  представляет собой чёрный ящик, к которому не дают админского доступа.
>  А раз так, то помимо настройки юзерспейсного софта есть варианты решения
>  задачи иными средствами. Например, можно поднять несколько ip-адресов
>  на бэкенде, задав несколько upstream-серверов в конфиге nginx'a, или
>  ядерным nat'ом размножить порты.
> --
>  Eugene Berdnikov
>
> ___
> 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: Ограничение на число исходящих соединений

[kpoxa]

Добрый день.

Да, я не прав, однако не всегда есть возможность убедить бэкэнд слушать два
или более портов.

14 октября 2015 г., 18:59 пользователь Валентин Бартенев <vb...@nginx.com>
написал:

> On Wednesday 14 October 2015 18:01:28 kpoxa wrote:
> > Для исходящего соединения используется незанятая пара ip:port, порт
> берется
> > свободный из диапазона доступных для этого портов, а ip берется первый,
> из
> > ближней к целевому хосту сетевой карточки, если явно не задано иное,
> таким
> > образом с одного ip адреса может быть всего 65000 коннектов во вне на
> любые
> > разные ip и порты/
> >
> [..]
>
> Вы заблуждаетесь.  Нет проблемы с использованием одной и той же комбинации
> ip-порт для соединения с разными ip или разными портами на одном ip.
>
> --
> Валентин Бартенев
> ___
> 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: Ограничение на число исходящих соединений

[kpoxa]

При чем тут где бэкэнд? Коннекты к любому количестве внешних портов будут
идти всё равно он одного адреса, вопрос с исходящими соединениями на
севрере с nginx, а не с входящими где бэкэнд, первые ограничиваются числом
портов у используемого адреса, а вторые этого ограничения не имеют.

14 октября 2015 г., 17:33 пользователь Evgeniy Berdnikov <b...@protva.ru>
написал:

> On Wed, Oct 14, 2015 at 05:14:55PM +0300, kpoxa wrote:
> > коннекты на 127.0.0.1 тоже конечны, разве что применять unix socket в
> этом
> > месте.
> > Вот если бы можно было сделать
> > upstream ws {
> >   server 10.17.17.38:5003 bind 10.17.17. <http://10.17.17.38:5003/>100;
> >   server 10.17.17.38:5003 bind 10.17.17. <http://10.17.17.38:5003/>101;
> >   server 10.17.17.38:5003 bind 10.17.17. <http://10.17.17.38:5003/>102;
> > }
> > но тут нужно внедрять это в код nginx.
>
>  А что мешает поднять бэкенд на разных портах: 10.17.17.38:5003,
>  10.17.17.38:5004, ..:5005, и т.д.? Или на разных ip-адресах.
> --
>  Eugene Berdnikov
>
> ___
> 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: Ограничение на число исходящих соединений

[kpoxa]

Для исходящего соединения используется незанятая пара ip:port, порт берется
свободный из диапазона доступных для этого портов, а ip берется первый, из
ближней к целевому хосту сетевой карточки, если явно не задано иное, таким
образом с одного ip адреса может быть всего 65000 коннектов во вне на любые
разные ip и порты/

14 октября 2015 г., 17:47 пользователь Сергей Пузырёв <spuzi...@gmail.com>
написал:

> Мне кажется, вы недопонимаете свою проблему.
>
> Нельзя иметь более 65000 соединений к одному удаленному порту одного
> удаленного IP-адреса с одного локального IP-адреса.
> Можно иметь 65000 соединений к одному удаленному порту одного удаленного
> IP-адреса с одного локального IP-адреса и еще 65000 соединений к другому
> удаленному порту этого же удаленного IP-адреса с того же локального
> IP-адреса.
>
> 14 октября 2015 г., 17:38 пользователь kpoxa <kp...@kpoxa.net> написал:
>
>> При чем тут где бэкэнд? Коннекты к любому количестве внешних портов будут
>> идти всё равно он одного адреса, вопрос с исходящими соединениями на
>> севрере с nginx, а не с входящими где бэкэнд, первые ограничиваются числом
>> портов у используемого адреса, а вторые этого ограничения не имеют.
>>
>> 14 октября 2015 г., 17:33 пользователь Evgeniy Berdnikov <b...@protva.ru>
>> написал:
>>
>> On Wed, Oct 14, 2015 at 05:14:55PM +0300, kpoxa wrote:
>>> > коннекты на 127.0.0.1 тоже конечны, разве что применять unix socket в
>>> этом
>>> > месте.
>>> > Вот если бы можно было сделать
>>> > upstream ws {
>>> >   server 10.17.17.38:5003 bind 10.17.17. <http://10.17.17.38:5003/
>>> >100;
>>> >   server 10.17.17.38:5003 bind 10.17.17. <http://10.17.17.38:5003/
>>> >101;
>>> >   server 10.17.17.38:5003 bind 10.17.17. <http://10.17.17.38:5003/
>>> >102;
>>> > }
>>> > но тут нужно внедрять это в код nginx.
>>>
>>>  А что мешает поднять бэкенд на разных портах: 10.17.17.38:5003,
>>>  10.17.17.38:5004, ..:5005, и т.д.? Или на разных ip-адресах.
>>> --
>>>  Eugene Berdnikov
>>>
>>> ___
>>> 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
>>
>
>
>
> --
> С уважением,
> Сергей Пузырёв
> тел.: +7-916-980-70-45
>
> ___
> 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

Ограничение на число исходящих соединений

[kpoxa]

Добрый день.

Использую stream для проброса соединений из вне + ssl прокси в дмз.

Столкнулся со стандартным ограничением на число исходящих соединений на
сервере в число доступных портов, в результате получаю ошибки вида:

2015/10/14 14:11:13 [crit] 11309#0: *28092735 connect() to
10.13.179.38:50003 failed (99: Cannot assign requested address) while
connecting to upstream, client: 15.15.72.69, server: 15.15.72.198:443,
upstream: " 10.13.179.38:50003", bytes from/to client:0/0, bytes from/to
upstream:0/0

В документации не нашел каких-либо способов обойти данное ограничение
средствами nginx, например использовать пул адресов для коннектов к
бэкэндам.

--
Рустам.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Ограничение на число исходящих соединений

[kpoxa]

Проблемы с настройками ОС нет, я ж написал, уперся в лимит портов, грубо
говоря в 64 000 +-, а надо 200 тыс. Пробовал и с указанными вами
переменными играться, и, например, наличие нескольких IP из одной подсети,
исходящие соединяются не распределяются по IP самостоятельно, для этого
надо делать какие-то телодвижения в коже, коих сейчас, видимо, нет. Поэтому
у меня и вопрос - может быть они есть и я что-то упустил в доках? А если
нет, то не планируются ли? Какой-нибудь downstream { out_ip ip1; out_ip
ip2; } :)

2015-10-14 15:59 GMT+03:00 Alex Vorona :

> Похоже проблемы с настройками ОС
> http://nginx.org/en/docs/freebsd_tuning.html
> net.inet.ip.portrange.randomized=0
> net.inet.ip.portrange.first=1024
> net.inet.ip.portrange.last=65535
>
> Для Linux  sysctl net.ipv4.ip_local_port_range
>
> ___
> 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: Ограничение на число исходящих соединений

[kpoxa]

Добрый день.

Спасибо за попытку помочь, к сожалению proxy_bind в варианте с stream
сервером можно использовать только один раз, т.к. в данном случае нет
location как таковых, есть только очень длинные соединения с commet
сервером, которые могут длиться днями, и это их нормальное поведение.
Конфиг простой:
stream {
upstream ws {
server  10.17.17.38:5003;
}

server {
listen  15.15.72.198:443 ssl;
#ssl params skipped;
proxy_connect_timeout   30s;
proxy_timeout   3600s;
proxy_pass  ws;
error_log /var/log/nginx/websocket-ssl.log info;
}
}

14 октября 2015 г., 16:43 пользователь Сергей Пузырёв <spuzi...@gmail.com>
написал:

> Можно использовать директиву proxy_bind
> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_bind и
> наваять грязный хак наподобие:
>
> split_clients $connection $downstream {
>   50% 1;
>   50% 2;
> }
>
> upstream backend {
>   server A;
>   server B;
> }
>
> server {
>   location /bla {
> rewrite /down$downstream$request_uri;
>   }
>   location /down1 {
> rewrite /down1(.*)$ $1 break;
> proxy_pass http://backend;
> proxy_bind 1.1.1.1;
>   }
>   location /down2 {
> rewrite /down2(.*)$ $1 break;
> proxy_pass http://backend;
> proxy_bind 2.2.2.2;
>   }
> }
>
> 14 октября 2015 г., 16:36 пользователь kpoxa <kp...@kpoxa.net> написал:
>
>> Проблемы с настройками ОС нет, я ж написал, уперся в лимит портов, грубо
>> говоря в 64 000 +-, а надо 200 тыс. Пробовал и с указанными вами
>> переменными играться, и, например, наличие нескольких IP из одной подсети,
>> исходящие соединяются не распределяются по IP самостоятельно, для этого
>> надо делать какие-то телодвижения в коже, коих сейчас, видимо, нет. Поэтому
>> у меня и вопрос - может быть они есть и я что-то упустил в доках? А если
>> нет, то не планируются ли? Какой-нибудь downstream { out_ip ip1; out_ip
>> ip2; } :)
>>
>> 2015-10-14 15:59 GMT+03:00 Alex Vorona <vo...@amhost.net>:
>>
>>> Похоже проблемы с настройками ОС
>>> http://nginx.org/en/docs/freebsd_tuning.html
>>> net.inet.ip.portrange.randomized=0
>>> net.inet.ip.portrange.first=1024
>>> net.inet.ip.portrange.last=65535
>>>
>>> Для Linux  sysctl net.ipv4.ip_local_port_range
>>>
>>> ___
>>> 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
>>
>
>
>
> --
> С уважением,
> Сергей Пузырёв
> тел.: +7-916-980-70-45
>
> ___
> 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: Ограничение на число исходящих соединений

[kpoxa]

коннекты на 127.0.0.1 тоже конечны, разве что применять unix socket в этом
месте.
Вот если бы можно было сделать
upstream ws {
  server 10.17.17.38:5003 bind 10.17.17. <http://10.17.17.38:5003/>100;
  server 10.17.17.38:5003 bind 10.17.17. <http://10.17.17.38:5003/>101;
  server 10.17.17.38:5003 bind 10.17.17. <http://10.17.17.38:5003/>102;
}
но тут нужно внедрять это в код nginx.

14 октября 2015 г., 17:11 пользователь Сергей Пузырёв <spuzi...@gmail.com>
написал:

> Можно сделать ещё намного более извращенную схему с перепроксированием по
> петле:
>
> upstream ws {
>   server 10.17.17.38.5003;
> }
>
> upstream internal-ws {
>   server 127.0.0.1:5001;
>   server 127.0.0.2:5001;
>   server 127.0.0.3:5001;
> }
>
> server {
>   listen 15.15.72.198:443 ssl;
>   proxy_connect_timeout 30s;
>   proxy_timeout 3600s;
>   proxy_pass internal-ws;
>   error_log /var/log/nginx/websocket-ssl.log info;
> }
>
> server {
>   listen 127.0.0.1:5001
>   proxy_pass ws;
>   proxy_bind 1.1.1.1;
> }
>
> server {
>   listen 127.0.0.2:5001;
>   proxy_pass ws;
>   proxy_bind 2.2.2.2;
> }
>
> server {
>   listen 127.0.0.3:5001;
>   proxy_pass ws;
>   proxy_bind 3.3.3.3;
> }
>
> 14 октября 2015 г., 17:00 пользователь kpoxa <kp...@kpoxa.net> написал:
>
>> Добрый день.
>>
>> Спасибо за попытку помочь, к сожалению proxy_bind в варианте с stream
>> сервером можно использовать только один раз, т.к. в данном случае нет
>> location как таковых, есть только очень длинные соединения с commet
>> сервером, которые могут длиться днями, и это их нормальное поведение.
>> Конфиг простой:
>> stream {
>> upstream ws {
>> server  10.17.17.38:5003;
>> }
>>
>> server {
>> listen  15.15.72.198:443 ssl;
>> #ssl params skipped;
>> proxy_connect_timeout   30s;
>> proxy_timeout   3600s;
>> proxy_pass  ws;
>> error_log /var/log/nginx/websocket-ssl.log info;
>> }
>> }
>>
>> 14 октября 2015 г., 16:43 пользователь Сергей Пузырёв <spuzi...@gmail.com
>> > написал:
>>
>> Можно использовать директиву proxy_bind
>>> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_bind и
>>> наваять грязный хак наподобие:
>>>
>>> split_clients $connection $downstream {
>>>   50% 1;
>>>   50% 2;
>>> }
>>>
>>> upstream backend {
>>>   server A;
>>>   server B;
>>> }
>>>
>>> server {
>>>   location /bla {
>>> rewrite /down$downstream$request_uri;
>>>   }
>>>   location /down1 {
>>> rewrite /down1(.*)$ $1 break;
>>> proxy_pass http://backend;
>>> proxy_bind 1.1.1.1;
>>>   }
>>>   location /down2 {
>>> rewrite /down2(.*)$ $1 break;
>>> proxy_pass http://backend;
>>> proxy_bind 2.2.2.2;
>>>   }
>>> }
>>>
>>> 14 октября 2015 г., 16:36 пользователь kpoxa <kp...@kpoxa.net> написал:
>>>
>>>> Проблемы с настройками ОС нет, я ж написал, уперся в лимит портов,
>>>> грубо говоря в 64 000 +-, а надо 200 тыс. Пробовал и с указанными вами
>>>> переменными играться, и, например, наличие нескольких IP из одной подсети,
>>>> исходящие соединяются не распределяются по IP самостоятельно, для этого
>>>> надо делать какие-то телодвижения в коже, коих сейчас, видимо, нет. Поэтому
>>>> у меня и вопрос - может быть они есть и я что-то упустил в доках? А если
>>>> нет, то не планируются ли? Какой-нибудь downstream { out_ip ip1; out_ip
>>>> ip2; } :)
>>>>
>>>> 2015-10-14 15:59 GMT+03:00 Alex Vorona <vo...@amhost.net>:
>>>>
>>>>> Похоже проблемы с настройками ОС
>>>>> http://nginx.org/en/docs/freebsd_tuning.html
>>>>> net.inet.ip.portrange.randomized=0
>>>>> net.inet.ip.portrange.first=1024
>>>>> net.inet.ip.portrange.last=65535
>>>>>
>>>>> Для Linux  sysctl net.ipv4.ip_local_port_range
>>>>>
>>>>> ___
>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> С уважением,
>>> Сергей Пузырёв
>>> тел.: +7-916-980-70-45
>>>
>>> ___
>>> 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
>>
>
>
>
> --
> С уважением,
> Сергей Пузырёв
> тел.: +7-916-980-70-45
>
> ___
> 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: Хочу написать патч

[kpoxa]

В вашем случае будет несколько процессов nginx под разными пользователями,
но как.. как вы будете коннекту приказывать подключиться к тому или иному
процессу, если на этапе коннекта вы не знаете к какому сайту будет запрос?

26 августа 2015 г., 12:00 пользователь paperroot nginx-fo...@nginx.us
написал:

 Konstantin Tokarev Wrote:
 ---
  25.08.2015, 17:37, paperroot nginx-fo...@nginx.us:
   Здравствуйте.
  
   Хочу написать патч, который будет отдавать контент предварительно
   setuid'ившись в системного пользователя указанного в конфиге
  virtual_host'a,
   для того чтобы обезопасить большое кол-во независимых проектов от
  разных
   пользователей, работающих на одном мощном сервере.
  
   Сделал правку в файле src/http/modules/ngx_http_static_module.c в
  функции
   ngx_http_static_handler.
   Суть правки: делается clone на участок кода:
  
   setgit(vh_gid);
   setuid(vh_uid);
   ngx_open_cached_file(clcf-open_file_cache, path, of, r-pool);
  
   данная правка работает, но имеются проблемы со сторонними модулями,
  например
   pagespeed.
  
   Подскажите пожалуйста, где идеалогически правильнее делать такую
  правку,
   чтобы она дружила с другими модулями, или хотябы с модулем
  pagespeed.
 
  Мне кажется, что единственный идеологически верный путь - запускать по
  отдельной
  копии nginx для каждого виртуального хоста под соответствующим
  пользователем, и
  проксировать на них запросы с главного Nginx
 
  
   Спасибо.
  
   Posted at Nginx Forum:
  http://forum.nginx.org/read.php?21,261237,261237#msg-261237
  
   ___
   nginx-ru mailing list
   nginx-ru@nginx.org
   http://mailman.nginx.org/mailman/listinfo/nginx-ru
 
  --
  Regards,
  Konstantin
 
  ___
  nginx-ru mailing list
  nginx-ru@nginx.org
  http://mailman.nginx.org/mailman/listinfo/nginx-ru

 Да такой вариант тоже рассматривался, но он к сожалению довольно затратен
 по
 вычислительным ресурсам и слишком сложный для управления и сопровождения.

 Я лишь прошу подсказать точку входа для правки, т.к. чтение кода nginx и
 дебагинг с gdb не дали мне ответа на этот вопрос. Гугление тоже ничего не
 дало, нету описания архитектуры или схемы обработки сетевого подключения.

 Поэтому и решил задать вопрос здесь.

 Posted at Nginx Forum:
 http://forum.nginx.org/read.php?21,261237,261255#msg-261255

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




-- 
Kpoxa
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Хочу написать патч

[kpoxa]

Кстати, а опишите задачу полностью, наверняка решается без подобного
кодоблудия.

25 августа 2015 г., 17:37 пользователь paperroot nginx-fo...@nginx.us
написал:

 Здравствуйте.

 Хочу написать патч, который будет отдавать контент предварительно
 setuid'ившись в системного пользователя указанного в конфиге
 virtual_host'a,
 для того чтобы обезопасить большое кол-во независимых проектов от разных
 пользователей, работающих на одном мощном сервере.

 Сделал правку в файле src/http/modules/ngx_http_static_module.c в функции
 ngx_http_static_handler.
 Суть правки: делается clone на участок кода:

 setgit(vh_gid);
 setuid(vh_uid);
 ngx_open_cached_file(clcf-open_file_cache, path, of, r-pool);

 данная правка работает, но имеются проблемы со сторонними модулями,
 например
 pagespeed.

 Подскажите пожалуйста, где идеалогически правильнее делать такую правку,
 чтобы она дружила с другими модулями, или хотябы с модулем pagespeed.

 Спасибо.

 Posted at Nginx Forum:
 http://forum.nginx.org/read.php?21,261237,261237#msg-261237

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




-- 
Kpoxa
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Иногда кеш растет сверх лимита

[kpoxa]

Добрый день.

Спасло тем, что при загрузке после процедуры обновления или просто restart
вызывают очистку диска, который становится загружен на 100% и на другие
запросы отвечает с гигантскими задержками, если бы очиска диска шла с
удалением loader_files файлов за loader_sleep  секунд, то тормозов в это
время (у меня это минут 10-15) не было бы.
Я понимаю, что разобраться с причиной блокировок важно и поставил на 20
серверов nginx с патчем, как будут результаты непременно поделюсь.

24 августа 2015 г., 19:13 пользователь Maxim Dounin mdou...@mdounin.ru
написал:

 Hello!

 On Wed, Aug 19, 2015 at 05:06:53PM +0300, kpoxa wrote:

 [...]

  Максим, давно уже с вами обсуждали, что было бы хорошо применять политики
  для cache loader к cache manager, чтобы последний не вешал систему
  удалением очень большого числа файлов из кеша, сейчас это меня бы спасло,
  может быть запланируете? Есть и другие кейсы, когда это полезно, например
  при уменьшении размера кеша или уменьшении inactive в конфиге.

 Спасло - чем?  Решить конкретную проблему с неочисткой старых
 элементов из кеша проще всего с помощью процедуры обновления
 nginx'а - кеш будет загружен заново, заблокированные ранее
 элементы будут разблокированы.  Вопрос именно в том, почему
 элементы оказались заблокированы.

 --
 Maxim Dounin
 http://nginx.org/

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




-- 
Kpoxa
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Иногда кеш растет сверх лимита

[kpoxa]

Добрый день.

Патченный nginx установлен на 10 сервреов, ждем результатов.

Максим, давно уже с вами обсуждали, что было бы хорошо применять политики
для cache loader к cache manager, чтобы последний не вешал систему
удалением очень большого числа файлов из кеша, сейчас это меня бы спасло,
может быть запланируете? Есть и другие кейсы, когда это полезно, например
при уменьшении размера кеша или уменьшении inactive в конфиге.

17 августа 2015 г., 14:57 пользователь Maxim Dounin mdou...@mdounin.ru
написал:

 Hello!

 On Fri, Aug 14, 2015 at 02:28:45PM +0300, kpoxa wrote:

  Добрый день.
 
  Просто так никто никаких сигналов не отправлял. Судя по логам процессы не
  умирали.
  На сервере debian, обновление конфига делается через -HUP мастер процессу
  (это в инит скрипте reload делает).
  И раз в сутки ротация логов с  kill -USR1 `cat /var/run/nginx.pid`

 Наиболее неприятный из известных мне нюансов состоит в том, что
 неразблокированные элементы кеша остаются, если какому-либо из
 рабочих процессов сказать TERM.  Например, такое иногда практикуют
 для принудительного завершения старых рабочих процессов, плавное
 завершение которых занимает слишком много времени.

  Что можно для диагностики сделать в случае если замечу, что кеш
  переполняется?

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

 http://mailman.nginx.org/pipermail/nginx-ru/2015-May/055936.html
 http://mailman.nginx.org/pipermail/nginx-ru/2015-May/055937.html

 --
 Maxim Dounin
 http://nginx.org/

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




-- 
Kpoxa
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Иногда кеш растет сверх лимита

[kpoxa]

Добрый день.

Просто так никто никаких сигналов не отправлял. Судя по логам процессы не
умирали.
На сервере debian, обновление конфига делается через -HUP мастер процессу
(это в инит скрипте reload делает).
И раз в сутки ротация логов с  kill -USR1 `cat /var/run/nginx.pid`
Что можно для диагностики сделать в случае если замечу, что кеш
переполняется?

13 августа 2015 г., 21:19 пользователь Maxim Dounin mdou...@mdounin.ru
написал:

 Hello!

 On Thu, Aug 13, 2015 at 06:41:44PM +0300, kpoxa wrote:

  Добрый день.
 
  Есть сервер с 2 SSD под кеш
 
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/sdb1   210G  167G   44G  80% /ssd2
  /dev/sda3   200G  157G   44G  79% /ssd
 
   и следующий конфиг:
 
  proxy_cache_path /ssd levels=1:2 keys_zone=ssd1:2000m
  max_size=16m inactive=7d loader_files=1000 use_temp_path=off;
  proxy_cache_path /ssd2levels=1:2 keys_zone=ssd2:2000m
  max_size=17m inactive=7d loader_files=1000 use_temp_path=off;
  split_clients $uri$is_args$args $disk {
  56.3% 2;
  * 1;
  }
 
  server {
  ...
   location / {
  proxy_cache ssd$disk;
 
   }
  }
 
  Периодически кеш разрастается выше лимита, пока не занимает весь диск.
  При рестарте nginx место очищается до максимально разрешенного

 Что при этом в логах?  Падения рабочих процессов, администраторы с
 шаловливыми руками и правом отсылки сигналов nginx'у?  Проще всего
 на такое наступить, если рабочий процесс упал и/или был
 принудительно завершён, и не смог разблокировать элементы кеша.

 Ну и я просто оставлю эти ссылки тут, на всякий случай:

 http://mailman.nginx.org/pipermail/nginx-ru/2015-May/055936.html
 http://mailman.nginx.org/pipermail/nginx-ru/2015-May/055937.html

 --
 Maxim Dounin
 http://nginx.org/

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




-- 
Kpoxa
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Иногда кеш растет сверх лимита

[kpoxa]

Добрый день.

Вот сейчас воспроизвелась проблема, если сделать strace на cache manager,
то видно, что есть удаления файлов с одного из двух кешей, со второго нет,
иногда бывают
futex(0x7fec52473070, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
...
futex(0x7fec52473070, FUTEX_WAKE, 1)= 0
...
futex(0x7fec52473070, FUTEX_WAKE, 1)= 1

-HUP не помогает, несмотря на смену всех процессов, кроме рутового.



14 августа 2015 г., 14:28 пользователь kpoxa kp...@kpoxa.net написал:

 Добрый день.

 Просто так никто никаких сигналов не отправлял. Судя по логам процессы не
 умирали.
 На сервере debian, обновление конфига делается через -HUP мастер процессу
 (это в инит скрипте reload делает).
 И раз в сутки ротация логов с  kill -USR1 `cat /var/run/nginx.pid`
 Что можно для диагностики сделать в случае если замечу, что кеш
 переполняется?

 13 августа 2015 г., 21:19 пользователь Maxim Dounin mdou...@mdounin.ru
 написал:

 Hello!

 On Thu, Aug 13, 2015 at 06:41:44PM +0300, kpoxa wrote:

  Добрый день.
 
  Есть сервер с 2 SSD под кеш
 
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/sdb1   210G  167G   44G  80% /ssd2
  /dev/sda3   200G  157G   44G  79% /ssd
 
   и следующий конфиг:
 
  proxy_cache_path /ssd levels=1:2 keys_zone=ssd1:2000m
  max_size=16m inactive=7d loader_files=1000 use_temp_path=off;
  proxy_cache_path /ssd2levels=1:2 keys_zone=ssd2:2000m
  max_size=17m inactive=7d loader_files=1000 use_temp_path=off;
  split_clients $uri$is_args$args $disk {
  56.3% 2;
  * 1;
  }
 
  server {
  ...
   location / {
  proxy_cache ssd$disk;
 
   }
  }
 
  Периодически кеш разрастается выше лимита, пока не занимает весь диск.
  При рестарте nginx место очищается до максимально разрешенного

 Что при этом в логах?  Падения рабочих процессов, администраторы с
 шаловливыми руками и правом отсылки сигналов nginx'у?  Проще всего
 на такое наступить, если рабочий процесс упал и/или был
 принудительно завершён, и не смог разблокировать элементы кеша.

 Ну и я просто оставлю эти ссылки тут, на всякий случай:

 http://mailman.nginx.org/pipermail/nginx-ru/2015-May/055936.html
 http://mailman.nginx.org/pipermail/nginx-ru/2015-May/055937.html

 --
 Maxim Dounin
 http://nginx.org/

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




 --
 Kpoxa




-- 
Kpoxa
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Иногда кеш растет сверх лимита

[kpoxa]

Добрый день.

Есть сервер с 2 SSD под кеш

Filesystem  Size  Used Avail Use% Mounted on
/dev/sdb1   210G  167G   44G  80% /ssd2
/dev/sda3   200G  157G   44G  79% /ssd

 и следующий конфиг:

proxy_cache_path /ssd levels=1:2 keys_zone=ssd1:2000m
max_size=16m inactive=7d loader_files=1000 use_temp_path=off;
proxy_cache_path /ssd2levels=1:2 keys_zone=ssd2:2000m
max_size=17m inactive=7d loader_files=1000 use_temp_path=off;
split_clients $uri$is_args$args $disk {
56.3% 2;
* 1;
}

server {
...
 location / {
proxy_cache ssd$disk;

 }
}

Периодически кеш разрастается выше лимита, пока не занимает весь диск.
При рестарте nginx место очищается до максимально разрешенного

nginx -V
nginx version: nginx/1.9.3
built by gcc 4.9.2 (Debian 4.9.2-10)
built with OpenSSL 1.0.2d 9 Jul 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-threads --with-stream
--with-stream_ssl_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' --with-ld-opt=-Wl,-z,relro --with-ipv6
--with-http_image_filter_module --with-openssl=/usr/src/openssl-1.0.2d
-- 
Рустам
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: как уменьшить размер кеша nginx?

[kpoxa]

Добрый день.

Размер кеша задается в настройках nginx и если в кеш будет добавлено что-то
и кеш станет больше, то в течении нескольких секунд nginx удалит из кеша
наиболее довно не использовавшиеся элементы, сомневаюсь, что у вас
постоянно запрашиваются все 1млн страниц, возможно 10% наиболее популярных
в кеше размеров 6гб достаточно, чтобы сохранить наиболее важные страницы.
Возможно стоит пременит min_use чтобы страницы, рапрошенные однократно, в
кеш не попадали и не вымывали из кеша что-то, более важное.

31 июля 2015 г., 15:22 пользователь VovansystemS vovansyst...@gmail.com
написал:

 Добрый день,

 есть старый, но довольно большой https legacy-сайт на php и у
 владельцев нет ресурсов его переделывать. сайт состоит из нескольких
 миллионов страниц в районе 60 кб каждая (14 кб после gzip на nginx).

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

 для обеспечения хотя бы минимальной отказоустойчивости, есть идея
 кешировать ответы backend'а, чтобы в случае его падения (задумчивости)
 была возможность отдать хоть что-то через fastcgi_cache_use_stale. но
 размер кеша всех целевых страниц сайта превысит все разумные пределы
 (60кб х 1 000 000 страниц ≈ 58 гб)

 каким образом можно сжимать кеш nginx, кроме доработки приложения,
 так, чтобы оно сразу отдавало сжатый ответ?

 ( здесь я читал:
 http://forum.nginx.org/read.php?21,256725,256739#msg-256739 )

 как один из вариантов вижу использование какой-нибудь файловой
 системы, которая умеет сжимать файлы на лету, но тут много вопросов к
 скорости работы fuse (по крайней мере раньше она работала медленно,
 изменилась ли ситуация?)

 в принципе, cloudflare мог бы решить задачу, если купить бизнес план и
 закачать туда свои сертификаты, но интересно рассмотреть вариант с
 nginx, потому как у cloudflare есть ещё косяки с доступностью для
 некоторых клиентов и роботов.

 может быть у кого-либо есть похожий опыт?
 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Kpoxa
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

ERR_SPDY_PROTOCOL_ERROR nginx 1.9.3

[kpoxa]

Добрый день.

nginx version: nginx/1.9.3
built by gcc 4.7.2 (Debian 4.7.2-5)
built with OpenSSL 1.0.1e 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --with-cc-opt='-I /usr/include'
--with-ld-opt='-L /usr/lib' --conf-path=/etc/nginx/nginx.conf
--sbin-path=/usr/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log --user=www --group=www
--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
--with-http_stub_status_module --with-pcre --with-http_ssl_module
--with-http_realip_module --add-module=/home/admin/ngx_devel_kit
--add-module=/home/admin/form-input-nginx-module --without-http-cache
--with-http_gzip_static_module --with-http_sub_module
--with-http_spdy_module --with-debug

linux debian 7

Периодически ловлю ошибку ERR_SPDY_PROTOCOL_ERROR

Сессия из  chrome://net-internals/ ниже. Какие еще данные и как собрать,
чтобы помочь разобраться в проблеме?



t=2381 [st= 0] +REQUEST_ALIVE  [dt=11]
t=2381 [st= 0]URL_REQUEST_DELEGATE  [dt=0]
t=2381 [st= 0]URL_REQUEST_START_JOB  [dt=0]
  -- load_flags = 676098 (BYPASS_CACHE |
BYPASS_DATA_REDUCTION_PROXY | MAIN_FRAME | MAYBE_USER_GESTURE |
REPORT_RAW_HEADERS | VERIFY_EV_CERT)
  -- method = GET
  -- priority = HIGHEST
  -- url = https://domain.ru/news/20907365/event/;
t=2381 [st= 0]   +URL_REQUEST_START_JOB  [dt=10]
  -- load_flags = 676098 (BYPASS_CACHE |
BYPASS_DATA_REDUCTION_PROXY | MAIN_FRAME | MAYBE_USER_GESTURE |
REPORT_RAW_HEADERS | VERIFY_EV_CERT)
  -- method = GET
  -- priority = HIGHEST
  -- url = https://domain.ru/news/20907365/event/;
t=2382 [st= 1]  URL_REQUEST_DELEGATE  [dt=0]
t=2382 [st= 1]  HTTP_CACHE_GET_BACKEND  [dt=0]
t=2382 [st= 1]  HTTP_CACHE_DOOM_ENTRY  [dt=1]
-- net_error = -2 (ERR_FAILED)
t=2383 [st= 2]  HTTP_CACHE_CREATE_ENTRY  [dt=0]
t=2383 [st= 2]  HTTP_CACHE_ADD_TO_ENTRY  [dt=0]
t=2383 [st= 2]  URL_REQUEST_DELEGATE  [dt=0]
t=2383 [st= 2] +HTTP_STREAM_REQUEST  [dt=0]
t=2383 [st= 2]HTTP_STREAM_REQUEST_BOUND_TO_JOB
  -- source_dependency = 215341 (HTTP_STREAM_JOB)
t=2383 [st= 2] -HTTP_STREAM_REQUEST
t=2383 [st= 2] +HTTP_TRANSACTION_SEND_REQUEST  [dt=1]
t=2383 [st= 2]HTTP_TRANSACTION_HTTP2_SEND_REQUEST_HEADERS
  -- :host: domain.ru
  :method: GET
  :path: /news/20907365/event/
  :scheme: https
  :version: HTTP/1.1
  accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
  accept-encoding: gzip, deflate, sdch
  accept-language:
ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
  cache-control: no-cache
  cookie: [1296 bytes were stripped]
  https: 1
  pragma: no-cache
  referer: https://domain.ru/newss/meetings/
  user-agent: Mozilla/5.0 (Windows NT 6.1; WOW64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36
t=2384 [st= 3] -HTTP_TRANSACTION_SEND_REQUEST
t=2384 [st= 3] +HTTP_TRANSACTION_READ_HEADERS  [dt=7]
t=2391 [st=10]HTTP2_STREAM_ERROR
  -- description = SPDY stream closed with status: 1
  -- status = -337
  -- stream_id = 53
t=2391 [st=10] -HTTP_TRANSACTION_READ_HEADERS
-- net_error = -337 (ERR_SPDY_PROTOCOL_ERROR)
t=2391 [st=10]   -URL_REQUEST_START_JOB
  -- net_error = -337 (ERR_SPDY_PROTOCOL_ERROR)
t=2391 [st=10]URL_REQUEST_DELEGATE  [dt=0]
t=2392 [st=11] -REQUEST_ALIVE
-- net_error = -337 (ERR_SPDY_PROTOCOL_ERROR)

-- 
Rustam Narmanov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: ERR_SPDY_PROTOCOL_ERROR nginx 1.9.3

[kpoxa]

Добрый день.

К сожалению не поймать в дебаг логе, ошибка не стабильная, просто reload
для включения трейса и всё, больше она не воспроизводится, по крайней мере
уже несколько часов.

2015-07-28 12:52 GMT+03:00 Sergey Kandaurov pluk...@nginx.com:

 On Jul 28, 2015, at 11:50 AM, kpoxa kp...@kpoxa.net wrote:
  Добрый день.
 
  nginx version: nginx/1.9.3
  built by gcc 4.7.2 (Debian 4.7.2-5)
  built with OpenSSL 1.0.1e 11 Feb 2013
  TLS SNI support enabled
  configure arguments: --prefix=/etc/nginx --with-cc-opt='-I /usr/include'
 --with-ld-opt='-L /usr/lib' --conf-path=/etc/nginx/nginx.conf
 --sbin-path=/usr/sbin/nginx --pid-path=/var/run/nginx.pid
 --error-log-path=/var/log/nginx/error.log
 --http-log-path=/var/log/nginx/access.log --user=www --group=www
 --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
 --with-http_stub_status_module --with-pcre --with-http_ssl_module
 --with-http_realip_module --add-module=/home/admin/ngx_devel_kit
 --add-module=/home/admin/form-input-nginx-module --without-http-cache
 --with-http_gzip_static_module --with-http_sub_module
 --with-http_spdy_module --with-debug
 
  linux debian 7
 
  Периодически ловлю ошибку ERR_SPDY_PROTOCOL_ERROR
 
  Сессия из  chrome://net-internals/ ниже.  Какие еще данные и как
 собрать, чтобы помочь разобраться в проблеме?
 

 Как минимум, понадобится debug log соответствующего соединения.

 http://nginx.org/en/docs/debugging_log.html

 --
 Sergey Kandaurov

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




-- 
Kpoxa
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

2 апстрима по очереди, или 2 именованых локейшена в try_files - как решить задачку

[kpoxa]

Добрый день, коллеги.

Есть задача сделать так:
 1. проверить есть ли файл локально.
 2. если нет, то проверить апстрим горячий кеш, нет ли там файла.
 3. Если в горячем кеше нет, то проверить следующий апстрим.

Вариант с
try_files $url @hot_cache @slow_cache
не работает, т.к. 2 именованных локейшена нельзя использовать.

Вариант объединить все в один апстрим не очень хорош, т.к. надо проверить
сначала все горячие кеши, потом только холодные.

Остаётся вариант с error_page 404 = @slow_cache в локейшене горячего кеша.

Это единственный/лучший вариант решения подобной задачи?
Почему нельзя в try_files сделать возможность использования нескольких
именованых локешенов?

-- 
Рустам
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 2 апстрима по очереди, или 2 именованых локейшена в try_files - как решить задачку

[kpoxa]

При переборе серверов в апстриме просто их перебирать
через proxy_next_upstream   http_404 error timeout invalid_header;
А тут придется делать это менее интересным способом, через множественные
директивы
error_page 404
error_page 502
error_page 503
и я не уверен, что все варианты из proxy_next_upstream покрываются таким
способом.

30 июня 2015 г., 17:00 пользователь Panfilov Konstantin 
error...@error500.ru написал:


 Вообще error_page единственно правильное решение
 try_files для тех кому быстренько WP поднять надо

 только не забудьте включить *recursive_error_pages* on

 30.06.2015 16:27, kpoxa пишет:

  Добрый день, коллеги.

 Есть задача сделать так:
  1. проверить есть ли файл локально.
  2. если нет, то проверить апстрим горячий кеш, нет ли там файла.
  3. Если в горячем кеше нет, то проверить следующий апстрим.

 Вариант с
 try_files $url @hot_cache @slow_cache
 не работает, т.к. 2 именованных локейшена нельзя использовать.

 Вариант объединить все в один апстрим не очень хорош, т.к. надо проверить
 сначала все горячие кеши, потом только холодные.

 Остаётся вариант с error_page 404 = @slow_cache в локейшене горячего кеша.

 Это единственный/лучший вариант решения подобной задачи?
 Почему нельзя в try_files сделать возможность использования нескольких
 именованых локешенов?

  --
 Рустам


 ___
 nginx-ru mailing 
 listnginx-ru@nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx-ru



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




-- 
Kpoxa
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Подскажите как лучше сделать try_files + proxy_cache

[kpoxa]

Добрый день.



Надо сделать 2 кеша на 2 дисках для 2 разных локейшенов, но с try_files
локальных файлов.


Вариант

server {
server_name server80;
listen  80;
root /etc/nginx/html;
try_files $uri @local;
location @local {
internal;
proxy_pass http://localhost80:800;
}
}
server {
  server_name local800;
  listen 127.0.0.1:800;
  location /1/ {
   proxy_cache1;
   proxy_pass http://server1;
  }
  location /2/ {
   proxy_cache2;
   proxy_pass http://server2;
  }
}

Гоняет трафик через лупбэк почем зря.
А в @локейшен вложенные локейшены делать нельзя.


-- 
Рустам
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Поддержка ICP - Internet Cache Protocol

[kpoxa]

Добрый день.

Планируется ли в nginx поддержка Internet Cache Protocol ?

Есть задача в работе группы кешей (на 5-6 серверов) так, чтобы надо было
опросить соседей, нет ли у них нужного контента, и обратиться к бэканду,
только если ни в одном из кешей нужного контента нет. Городить
последовательный опрос серверов не так красиво и удобно, как использование
подобного протокола.

Возможно кто-то знает решение с уже имеющимися возможностями?

-- 
Рустам
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Поддержка ICP - Internet Cache Protocol

[kpoxa]

Так задача не решается, т.к. мне надо иметь 5 проксей-кешей с идентичным
контентом, чтобы любой мог выпасть в любой момент времени и контент,
который в нем хранился, не надо было бы запрашивать полностью у бэкенда, а
можно было большую часть запросов прогнать через соседей по группе.

28 ноября 2014 г., 15:22 пользователь Maxim Dounin mdou...@mdounin.ru
написал:

 Hello!

 On Fri, Nov 28, 2014 at 03:33:54PM +0400, kpoxa wrote:

  Планируется ли в nginx поддержка Internet Cache Protocol ?

 Нет.

  Есть задача в работе группы кешей (на 5-6 серверов) так, чтобы надо было
  опросить соседей, нет ли у них нужного контента, и обратиться к бэканду,
  только если ни в одном из кешей нужного контента нет. Городить
  последовательный опрос серверов не так красиво и удобно, как
 использование
  подобного протокола.
 
  Возможно кто-то знает решение с уже имеющимися возможностями?

 Консистентный hash по URI должен хорошо решать такой класс задач,
 см. http://nginx.org/r/hash/ru.

 --
 Maxim Dounin
 http://nginx.org/

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




-- 
Kpoxa
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

bug auth_request + form_input

[kpoxa]

Добрый день.

Наблюдаю баг следующего вида:

При одновременно используемом auth_request и set_form_input nginx делает
подзапрос нужному бэкэнду для авторизации, ему приходит валидный ответ, а
дальше запрос не отрабатывает, клиент получает таймаут. Есть еще одно
условие - это POST запрос, на который реагирует set_form_input.

Воспроизводится на версиях 1.5.8 и 1.7.3


-- 
Рустам Нарманов
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru