Re: nginx полностью загружает весь процессор при reload'e
Добрый день, спасибо за ответ. On 02/09/2019 22:11, Maxim Dounin wrote: Just in case, для работы такая конфигурация смысла не имеет - если тикеты выключены, то ключ для их шифрования не нужен. Ключ имеет смысл задавать, если тикеты включены. С точки зрения влияния на reload - внешний ключ позволит сохранить тикеты при reload'ах, а выключение тикетов - уведёт всё в кэш сессий. Ну выключать тикеты - это, безусловно, плохой путь. Тикеты - способ переложить хранение сессий на клиентов, и отказываться от этого - очевидно недальновидно с точки зрения нагрузки на сервер. Да, я неверно понял доки. Отмечу также, что даже в наиболее экстремальных случаях из представленных на графике - рост потребления процессора с ~200% до ~300% не выглядит сколько-нибудь фатальным. Какой-то рост потребления процессора при релоадах - нормален, здесь же наблюдается рост всего в 1.5 раза. Если это проблема - то стоит задуматься о добавлении мощностей и/или заняться оптимизацией Да, сейчас это для меня просто представляет интерес, после перехода на openssl 1.0.2g и включение http2, проблем это особых не вызывает. А вот то, что средняя нагрузка без тикетов заметно выше - это немного странно. Само хранение сессий - должно бы стоить очень недорого с точки зрения процессора, а в остальном разница не принципиальна. Но, возможно, тут дело в том, что размер кэша SSL-сессий просто мал для имеющегося количества клиентов, и поэтому при выключении тикетов handshake'и начинают происходить чаще, что и приводит к росту потребления процессора. Возможно. Это немного не то, но мне было интересно как увеличение кэша ssl сессий повлияет на нагрузку при reload'e: http://dl4.joxi.net/drive/2019/09/03/0030/2608/1985072/72/8608b87db7.jpg Числами отметил разное количество ssl_session_cache от 20m до 256m. Вроде никак не влияет. Сегодня тестил при 8K rps (вчера 5-6K). Поэтому нагрузка скачет чуть выше. А вот тикеты помогли вообще круто. Нагрузка поднимается всего-лишь на 5%-10%: http://dl3.joxi.net/drive/2019/09/03/0030/2608/1985072/72/ac00a4d2d0.jpg Здесь 1 - это без ssl_session_ticket_key, а 2,3,4 - c включенными тикетами и указанными постояным ключем ssl_session_ticket_key. Итого: Сущесвтенно решить проблему помогло следующее: 1) переход на http2 (openssl 1.02.g) - понизилась нагрузка в целом, и при reload'e нагрузка конечно возрастала, но не надолго (5-20 секунд, а раньше от 30-40 секунд, до 5 минут). 2) И вообще убрать хоть какое-то сущесвтенное повышение нагрзуки помогло включение ssl_session_tickets(по умолчанию включено) с установелнным ssl_session_ticket_key (по умолчанию генерируется заново при каждом reload'e, его лучше указать чтобы этого не происходило). Оставил такие параметры: ssl_session_cache shared:SSL:20m; ssl_session_timeout 30m; ssl_session_tickets on; ssl_session_ticket_key /etc/nginx/ssl/ticket.key; # ticket.key - файл с рандомными 80 или 48 байт Кэш ssl сессий оставил, хоть в моем случае он вроде как сильно не влияет (по крайней мере я этого не заметил). Спасибо Вам большое, Ваши советы помогли полностью избавиться от этого эффекта. Надеюсь кому-то тоже будет полезна эта переписка. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
Спасибо большое за ответ. Потестил с параметрами: ssl_session_tickets off; ssl_session_ticket_key /etc/nginx/ssl/ticket.key; И довольно интересно получилось: http://joxi.net/krD6q0jTKkV9R2.jpg На картинке числами отмечены reload'ы 1,2,6,7,10 - без настроек tickets (по умоланию включен) 3,4,5,8,9 - с отключенным tickets и файлом ssl_session_ticket_key. При этом всегда был включен кэш сессий: ssl_session_cache shared:SSL:20m; ssl_session_timeout 30m; Пока сделал вывод, что с отключенным ssl_session_tickets средняя нагрузка выше, но при этом при reload'e нагрузка не так сильно возрастает по отношению к средней. Тесты не совсем чистые, постараюсь сделать более чистый эксперимент. On 02/09/2019 16:55, Maxim Dounin wrote: Hello! On Sat, Aug 31, 2019 at 12:54:06PM +0500, Dmitry Sergeev wrote: Добрый день! Спасибо за ответ. Конфиг полный, просто сократил количетсво виртуальных хостов, так как они одинаковые. В конфиге значилось: include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; Так что понять по нему, полный он, или нет - не представляется возможным, отсюда и вопросы. ssl_session_cache - действительно не настроено. ssl_dhparam - аналогично. сертификат один общий для всех, сгенерировал его для wildcard домена от let's encrypt (Signature Algorithm: sha256WithRSAEncryption, Public-Key: rsaEncryption (2048 bit)). Пытался оптимизировать ssl и посмотреть влияние его настроек на эту проблему. В частности пробовал глобально добавлять опции: *ssl_session_cache shared:SSL:20m;* *ssl_session_timeout 30m; *вроде никак не влияло, но я проверю еще раз конечно, и более чательно. Если большая часть клиентов использует тикеты - то может и не повлиять. Для теста можно попробовать отключить тикеты (ssl_session_tickets) и/или настроить внешний ключ (ssl_session_ticket_key), так как автоматически сгенерированные ключи при reload'е обновляются. Про ssl_dhparam не понял, с точки зрения производительности - его лучше добавлять но с небольшой битностью (2048 и меньше) или лучше совсем не использовать? Лучше - не использовать. Даже 2048 для классического Диффи-Хеллмана - это очень медленно. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
Добрый день! Спасибо за ответ. Конфиг полный, просто сократил количетсво виртуальных хостов, так как они одинаковые. ssl_session_cache - действительно не настроено. ssl_dhparam - аналогично. сертификат один общий для всех, сгенерировал его для wildcard домена от let's encrypt (Signature Algorithm: sha256WithRSAEncryption, Public-Key: rsaEncryption (2048 bit)). Пытался оптимизировать ssl и посмотреть влияние его настроек на эту проблему. В частности пробовал глобально добавлять опции: *ssl_session_cache shared:SSL:20m;* *ssl_session_timeout 30m; *вроде никак не влияло, но я проверю еще раз конечно, и более чательно. Про ssl_dhparam не понял, с точки зрения производительности - его лучше добавлять но с небольшой битностью (2048 и меньше) или лучше совсем не использовать? Большое спасибо за советы. ** On 30/08/2019 17:49, Maxim Dounin wrote: Hello! On Wed, Aug 28, 2019 at 09:18:44PM +0500, Dmitry Sergeev wrote: Вообще мне это конечно помогло, но не полностью. На версии 1.0.2g во время reload'а проц грузит полностью около 5-10 секунд (вместо 40-300 секунд на 1.0.1u), теперь просто оно особо проблем не вызывает у клиентов. Но в целом проблема осталась, просто теперь она не так сильно беспокоит. Сейчас задача замедлилась, но в итоге буду поднимать тестовый стенд с нагрузкой, и смотреть можно ли как-то повлиять на это. Если конечно тут не подскажут, что еще можно подкрутить. Судя по perf top, проблема в том, что клиенты после reload'а переустанавливают соединения, и это выливается в полный SSL handshake - что и приводит к потреблению CPU. Посмотреть стоит на: - ssl_session_cache - в конфиге его, судя по всему, нет (или соответствующие части конфига не показаны); - сертификаты, в частности - их битность (just in case, RSA более 2048 использовать не надо, это тупо очень дорого с точки зрения процессора) и тип (лучше использовать ECDSA, но тут уже может встать вопрос совместимости; при желании можно использовать и RSA и ECDSA одновременно); - используемые шифры, особенно - шифры с классическим DH для обмена ключами (по умолчанию эти шифры не используются начиная с nginx 1.11.0, но некоторые любят указывать ssl_dhparam в конфиге, да ещё и с параметрами большой битности; не надо так); Насчет старых клиентов, точно не могу сказать, но есть такой кейс http://mailman.nginx.org/pipermail/nginx-ru/2019-April/062014.html. Я хорошо не изучал этот вопрос, но факт остается, на старой версии openssl ошибок у клиентов в 3-4 раза было меньше. В итоге решили что это клиенты с очень старым ssl. Как уже говорилось в треде по ссылке, использование OpenSSL 1.0.1u автоматически означет, что HTTP/2 с большинством клиентов работать не будет. С учётом "listen ... http2" в конфиге - обновление до 1.0.2 могло "помочь" просто за счёт того, что HTTP/2 заработал, и количество устанавливаемых соединений соответственно уменьшилось. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
Вообще мне это конечно помогло, но не полностью. На версии 1.0.2g во время reload'а проц грузит полностью около 5-10 секунд (вместо 40-300 секунд на 1.0.1u), теперь просто оно особо проблем не вызывает у клиентов. Но в целом проблема осталась, просто теперь она не так сильно беспокоит. Сейчас задача замедлилась, но в итоге буду поднимать тестовый стенд с нагрузкой, и смотреть можно ли как-то повлиять на это. Если конечно тут не подскажут, что еще можно подкрутить. Насчет старых клиентов, точно не могу сказать, но есть такой кейс http://mailman.nginx.org/pipermail/nginx-ru/2019-April/062014.html. Я хорошо не изучал этот вопрос, но факт остается, на старой версии openssl ошибок у клиентов в 3-4 раза было меньше. В итоге решили что это клиенты с очень старым ssl. On 27/08/2019 23:25, ngnx8810773a83 wrote: А с какими старыми клиентами не совместим 1.0.2g, который сам тоже не слишком свеж ? В мае был релиз 1.0.2s а g, это гдето в марте 16 года было. Если Вы про sslv2 то оно там есть.у меня специально для этих целей живет нгинкс собранный с 1.0.2m. если кастомный openssl собиратете через сборку nginx с --with-openssl , то ему можно пихнуть кастомные параметры в configure через --with-openssl-opt для всяких оптимизаций. если совсем какито раритеты, то пихните туда enable-weak-ssl-ciphers enable-ssl2.. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285412,285421#msg-285421 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
Нашел причину, проблема была в старом ssl - openssl 1.0.1u. perf top показывал: http://dl3.joxi.net/drive/2019/08/27/0030/2608/1985072/72/88257baf85.jpg Попробвал обычную версию 1.0.2g и проблемы ушли. Осталось уговорить менеджеров забить на 1% старых ssl клиентов. On 27/08/2019 18:08, Dmitry Sergeev wrote: Затестил. Без модуля vts тоже самое поведение. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
Затестил. Без модуля vts тоже самое поведение. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
Еще нюанс забыл указать. nginx компилировал с модулем vts. Возможно с ним проблема. Проверю это. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
ue_client_ip","HEADER_ACCEPT":"$http_accept","HEADER_ACCEPT_LANGUAGE":"$http_accept_language","HEADER_CONTENT_LANGUAGE":"$http_content_language","HEADER_CONTENT_TYPE":"$http_content_type","BODY":"$request_body"}';
server
{
listen [::]:80;
listen 80;
listen [::]:443 ssl http2;
listen 443 ssl http2;
ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/privkey.pem;
server_name php_domain;
root /var/www/php_domain/docroot;
access_log /var/log/nginx/php_domain_access.log file_php_domain
if=$status_error;
error_log /var/log/nginx/php_domain_error.log;
location = /robots.txt
{
set $location "robots";
return 200 "User-agent: *\nDisallow: /\n";
}
location = /https:/php_domain
{
set $location "ssl_checker";
return 200 "for ssl checker\n";
}
location ~ /\.(git|svn|hg)
{
deny all;
}
location ~* ^/.*\.php$
{
try_files /DsHs5OrKH8nAkZAYQVbWqwWN1kQmRC9rISzowfDiHPOJqJT3
@backend;
}
location /
{
index index.html index.php;
set $location "default";
}
location ~* ^/.*\.html$
{
set $location "html";
add_header P3P 'policyref="../../../common/site/p3p.xml",
CP="NOI CURa ADMa DEVa TAIa"';
expires epoch;
}
location ~*
^/.*\.(eot|webp|plist|png|jpg|jpeg|ttf|otf|woff|woff2|mp3|ogg|swf|js|json|atlas)$
{
set $location "static";
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Expose-Headers "Date";
expires max;
}
location ~* ^/.*\.(css|gif|ico|mpeg|mpg|mp4|svg)$
{
set $location "static";
expires max;
}
location @backend
{
set $location "php";
fastcgi_pass php_backend;
include fastcgi_params;
fastcgi_index index.php;
fastcgi_connect_timeout 10s;
fastcgi_read_timeout 10s;
fastcgi_send_timeout 10s;
fastcgi_param X_HOST $remote_addr;
fastcgi_param SCRIPT_FILENAME /docroot$fastcgi_script_name;
}
location = /main/site/index.html
{
set $location "index";
add_header P3P 'policyref="../../../common/site/p3p.xml",
CP="NOI CURa ADMa DEVa TAIa"';
expires epoch;
}
location /.well-known
{
set $location "well-known";
root /usr/share/nginx/html;
}
}
Остальные виртуальные хосты либо похожие либо чуть отличаются.
On 27/08/2019 16:17, Maxim Dounin wrote:
Hello!
On Tue, Aug 27, 2019 at 04:10:31PM +0500, Dmitry Sergeev wrote:
Добрый день. Спасибо за ответ!
Пожалуйста. Не надо отвечать мне лично, от этого карма портится.
Спасибо.
На сервере всего 64GB памяти, nginx кушает обычно около 2GB при релоадет
не сильно больше - 2-3GB, swap не задействуется. Свободно памяти обычно
больше 60GB.
Сейчас протестил. При релоаде съедает весь проц ровно 35-40 секунд.
Провел около 10 тестов, время всегда примерно такое.
Значит проблема не в памяти, а в чём-то ещё. Что в конфиге?
--
Kind regards
Dmitry Sergeev
Tel: +7 (951) 129-75-72
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginx полностью загружает весь процессор при reload'e
Версия: 1.14.2 ОС: ubuntu 16.04 Процессор: Intel Core i7-6700 CPU 3.40GHz Средняя нагрузка: 5 000 rps, пиковые значения 12 000 rps. Статики практически нет, все запросы проксируются либо на бэкенды с nodejs через proxy_pass либо на php-fpm через fastcgi_pass. Виртуальных хостов 16, несколько из них имеют среднюю нагрузку 2K rps, остальные 500 rps. С бэкендами nodejs включен keepalive, с php отключен. Кроме nginx на сервере ничего нет. Проблема в том, что при reload'e конфигурации, несколько минут nginx начинает жрать весь процессор, все ядра под 100%, и запросы начинают обрабатываться медленно либо совсем сбрасываются, отсюда куча ошибок у клиентов. Такая проблема наблюдается только на серверах, где много виртуальных хостов (15-30). На серверах с аналогичной нагрузкой, но например 1-3 виртуальными хостами. Таких проблем не наблюдаю. Может быть кто-нибудь подскажет, как можно это оптимизировать, что-то подкрутить. Может можно как-то плавнее релоадить, чтобы медленее, но при этом нагрузка на CPU как-то плавнее распределялась. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Домены 3-го уровня - best practices
Но зачем? Чем варианты предложенные раннее вас не устроили?
On 26/05/2019 02:47, vitcool wrote:
А что то типа такого можно сделать? Кол-во сабдоменов не будет расти. Т.е.
есть готовый список, который готов обработать бекенд, все остальное он сам
отредиректит на www. на специальный урл
map $host $subdomain_map {
hostnames;
default www;
a000.example.com a000;
a001.example.com a001;
a010.example.com a010;
a011.example.com a011;
a100.example.com a100;
a101.example.com a101;
a110.example.com a110;
a111.example.com a111;
...
}
server {
listen 443 ssl;
server_name $subdomain_map;
location / {
proxy_set_header Host "www.example.com";
proxy_set_header X-Host-Subdomain $subdomain_map;
proxy_pass http://upstream;
}
...
}
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,284307,284317#msg-284317
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Kind regards
Dmitry Sergeev
Tel: +7 (951) 129-75-72
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Влияние на производительность проверок на существоание файла (-f) в rewrite модуле
Спасибо за ответ. К сожалению на выкатку без простоя я повлиять не могу. Флаг тех. работ во время деплоя всех устраивает, а вот поддержка в коде двух структур данных в бд (до миграции и после) не очень устраивает. Поэтому так живем. Также в редких случаях, при авариях, требуется закрывать сервис на тех. работы. В целом, много вызовов stat не очень страшно, но только ради редких тех. работ так делать все таки не буду. Еще раз спасибо. On 23/05/2019 17:43, Maxim Dounin wrote: Hello! On Thu, May 23, 2019 at 03:10:28PM +0500, Dmitry Sergeev wrote: При такой конфигурации на каждый запрос[*] будет делаться системный вызов stat(). Скорее всего необходимые данные будут в кэше операционной системы, и этот системный вызов будет быстрым, так что на производительности это скажется минимально. Так что если речь не идёт о борьбе за каждый процент - про производительность подобной конструкции можно не переживать. Другой вопрос, что сама по себе конструкция не очень, выкатку нужно уметь делать без перерывов в обслуживании. [*] Вообще-то в можно ещё и настроить кэширование внутри nginx'а, чтобы сэкономить системные вызовы (http://nginx.org/r/open_file_cache). Но практика показывает, что на производительность это влияет минимально, а вот выстрелить себе в ногу неатомарным изменением файлов станет легко. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Влияние на производительность проверок на существоание файла (-f) в rewrite модуле
Всем привет. Не поделится ли кто-нибудь опытом, сильно ли может повлиять
на произовдительность конструкция:
location / {
if (-f /var/www/maintenance_on.html) {
return 503;
}
...
}
# Error pages.
error_page 503 /maintenance_on.html;
location = /maintenance_on.html {
root /var/www;
}
Например 7-10 location с такими проверками на хосте 4K запросов в секунду?
На каждый запрос он будет проверять существование файла? Или как-то это
делает по таймауту, который можно настроить?
--
Kind regards
Dmitry Sergeev
Tel: +7 (951) 129-75-72
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: proxy_next_upstream & HTTP 502
Насколько nginx логирует запрос только если попробовал все апстримы, или после каждого? Здесь больше похоже на второе. Можно ли как-то настроить чтобы логировался только результат последнего попробованного апстрима? Он и будет результатом запроса. http://nginx.org/ru/docs/http/ngx_http_upstream_module.html - здесь указано, что запрос передается в случае неудачи следующему серверу апстрима, и в случае неуспеха, будет возвращен результат последнего. А так как в access_log возвращается фактический код ответа клиенту, то на один запрос от клиента должна быть одна запись в access_log. Если бы на один запрос, было бы несколько записей - то это очень странное поведение. Я вроде эксперементировал на этот счет, в случае трех серверов в апстриме, в access_log попадает одна запись с фактическим кодом ответа клиенту, в error_log попадает три записи, о том что неудалось соединиться с каждым серверов из апрстрима. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Количество клиенстких ошибок выросло после обновления до новой nginx(1.14.2) c новым openssl (1.0.2g)
Количество ошибок на уровне HTTP - может быть нерелевантно происходящему, и, скажем, означать, что больше проблемных клиентов теперь могут пройти через SSL handshake. Ну и смотреть надо не на абсолютные цифры, а на проценты от трафика. Если речь про доли процента - наблюдаемое изменение может быть следствием того, что проблемы возникают у каких-либо малораспространённых клинтов, и совершенно не факт, что на это надо обращать внимание. Например, из OpenSSL 1.0.2 могли убрать какие-то workaround'ы для ошибочного поведения, или же из-за изменения списка шифров теперь используются другие шифры, которые, наоборот, вызывают проблемы в этих клиентах. Ну не знаю, количество ошибок, которое возросло в 3-4 раза, как по мне стоит того, чтобы обратить внимание. Доля трафика конечно небольшая, я думаю примерно в пределах одного процента, а точнее: 0.24% запросов это ошибки (499,408,400). Но обычно эта доля составляет 0.05%, что и расстраивает. Надо конечно это считать не по количеству запросов, а по количеству пользователей, которых это затрагивает, но все же. Если же хочется таки разобраться - то имеет смысл смотреть подробную информацию по ошибкам, в частности - что при этом пишет nginx в логи (если есть подробности - они скорее всего на уровне info), и что известно про этих клиентов - User-Agent, используемые протоколы, шифры и так далее. Да, спасибо. Буду исследовать дальше. В первую очередь - в OpenSSL 1.0.1 нет ALPN, то есть HTTP/2 в современных браузерах работать не будет. Если в конфиге включён HTTP/2 - переход на OpenSSL 1.0.2 будет сильным изменением поведения в любом случае. Так что имеет смысл HTTP/2 выключить и сравнивать строго без HTTP/2. Важно при этом выключить везде, потому как http2 - это опция сокета, и если она останется в любом из блоков server, то HTTP/2 продолжит работать. Тестил как с http2 так и без него, результат один и тот же. Про то что отключать его нужно во всех блоках server знаю, после выключения непосредственно проверял вручную, выключился ли он действительно. Если вдруг используются множественные сертификаты в одном блоке server - переход с OpenSSL 1.0.1 на 1.0.2 потребует изменения цепочек в ssl_certificate, т.к. в случае OpenSSL 1.0.1 цепочка только одна и общаяя для всех сертификатов, а в случае 1.0.2 - у каждого сертификата своя. Я к сожалению не очень разбираюсь в этом, я использую wildcard сертификаты от letsencrypt. То что сгенирировал certbot то и даю nginx. Как писал раннее, тестил версии openssl: 1.0.1u, 1.0.2g, 1.1.1b. Данная проблема воспроизводится успешно на 1.0.2g и 1.1.1b. Спасибо за наводки, понял, что проблема скорее всего на клиентской стороне с поддержкой алгоритмов ssl или еще какие-то, буду исследовать дальше. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Количество клиенстких ошибок выросло после обновления до новой nginx(1.14.2) c новым openssl (1.0.2g)
Добрый день. ОС: Ubuntu 16.04 Nginx версия с которой проблемы: nginx version: nginx/1.14.2 built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11) built with OpenSSL 1.0.2g 1 Mar 2016 TLS SNI support enabled Обновились до последней стабильной сборки nginx. Количество ошибок 4xx значительно повышается: А именно 499 в два раза, 400 в 20 раз, 408 в 14 раз, в целом всего 4xx ошибок становится в 3-4 раза больше. Раннее мы работали на nginx 1.12.1 собственной сборки с openssl 1.0.1u, когда-то я собирали эту версию по тем же причинам (сборка nginx 1.12.1 из репозитория себя вела точно также - куча ошибок). Поэтому сейчас снова пришлось собрать уже новую версию nginx (1.14.2) но со старым openssl 1.0.1u. Привожу скрин для наглядности: http://joxi.net/n2YQdVZSbozM02.jpg Здесь статистка по ошибкам из двух одинаковых серверов за 30 минутный интервал времени. Где lb21 имеет nginx 1.14.2 + openssl 1.0.1u, а lb21-2 nginx 1.14.2 + openssl 1.0.2g Вот так выглядет процесс отката до nginx 1.14.2 + openssl 1.0.1u c точки зрения количества ошибок: http://joxi.net/EA4RKZXHowQDQm.jpg (здесь каждый столбик это количество за минуту). Конфигурации одинаковые, количество трафика одинаковое. Пробовал менять местами версии nginx между этими серверами, сразу видно как начинает расти количество ошибок на том сервере где используется nginx 1.14.2 + openssl 1.0.2g. Тенденция роста количества 499, 400, 408 ошибок видна моментально после обновления версии. Пробовал разные версии openssl (ветки 1.0.2, 1.1.1). Все что выше 1.0.1u дает такой результат. Пробовал отключать/включать http2 никак не влияет. Конфиугация ssl в nginx стоит по умолчанию (то есть только указаны диррективы ssl_certificate, ssl_certificate_key). Вроде все уже давно юзают и http2 и новую ssl и не жалуются, а я каждые два года собираю nginx со старой ssl и не понимаю в чем может быть дело =(. Может у кого-то похожие проблемы? -- Kind regards Dmitry Sergeev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
499 c нулевым $request_time
Всем привет. В логах nginx, 499 статус ответа означает отмену запроса на стороне клиента. Также в лог ведется запись переменной $request_time. При любых тестах локально, даже если моментально отменять запрос, какое-то значение, хоть и малеьнкое, в переменной $request_time есть. Но на продакшене, если например взять сервер где 303 264 000 запросов в день(около 3400/сек. в среднем), из них 183 278 запросов имеют статус 499 со значением 0.000 в переменной $request_time. Небольшое уточнение: Все запросы динамические (то есть проксируются на бэкенд), статика у нас раздается CDN серверами отдельно. Посдкажите пожаулйста, в каких случаях при 499 статучc $request_time может быть 0? Может кто знает. Или это нормальная ситуация, и у всех в 0.06% случаев запросы отменяются на стороне клиентов. Может быть это происходит в случае долгого коннекта с клиентом? -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
