Enabling both gzip & brotli

Hello. Can I enable both brotli & gzip? brotli on; gzip on; with the idea to support both newer & older clients, but still not do any kind of double compression. Thanks. Posted at Nginx Forum: https://forum.nginx.org/read.php?2,277282,277282#msg-277282

Re: massive deleted open files in proxy cache

Have you been able to solve the issue? We're having the same problem after upgrading 1.12.2 to 1.14 Posted at Nginx Forum: https://forum.nginx.org/read.php?2,272519,280189#msg-280189 ___ nginx mailing list nginx@nginx.org

Re: nginx mainline vs nginx stable

> Наверное есть смысл перейти на использование ветки mainline 1.15.х > Она не менее стабильная, чем stable, и на основании ветки mainline > создается коммерческая версия "NGINX Plus". Спасибо за детальный обзор, но пора энтузиазма давно прошла )) Сейчас важно чтобы штука стабильно работала, чтобы

Re: Открытые файлы растут после обновления до 1.14

Dmytro Lavryk Wrote: --- > Точно. Там люди ходят. Не самые посещаемые сайты, но все же... > > curl -H 'Accept-Encoding: br' -I https://site.address/ > ... > content-encoding: br Вы используете brotli on? Контент ложится в кэш br, или в сыром

Re: Открытые файлы растут после обновления до 1.14

Вот на данный момент через 1 час 20 минут после последнего SIGHUP: $ sudo lsof +L1 | grep -w ^nginx | wc -l 39903 $ sysctl kern.openfiles kern.openfiles: 64706 (разницу можно игнорировать, там и postgres есть, я sysctl привел просто чтобы показать что они оба растут). Posted at Nginx Forum:

Re: Открытые файлы растут после обновления до 1.14

Dmytro Lavryk Wrote: --- > BROTLI off > > cache: > fastcgi_cache_path /var/tmp/nginx/fastcgi_cache levels=1:2 keys_zone= > ССС:100m inactive=240m; > > lsof +L1 | grep -w ^nginx | wc -l > 20 > > sysctl kern.openfiles > kern.openfiles: 3481 > >

Re: Открытые файлы растут после обновления до 1.14

Илья Шипицин Wrote: --- > OPTIONS_FILE_SET+=BROTLI > > это недефолтная настройка ? Недефолтная. > > у нас примерно такой набор модулей. есть инсталяции на freebsd. > но кешем не пользуемся > > спецэффекта не наблюдаем > Потому что кешем

Re: Открытые файлы растут после обновления до 1.14

Gena Makhomed Wrote: --- > On 20.06.2018 22:05, rihad wrote: > > > Brotli убрать к сожалению не вариант > > Довольно странное занятие для сервера - вытаскивать несжатые страницы > из кеша и потом тратить время и процессор

Открытые файлы растут после обновления до 1.14

После обновления nginx с 1.12 до 1.14 на FreeBSD 10 открытые удаленные файлы (lsof +L1) стремительно растут для nginx. В обеих версиях один конфиг, и одни опции постройки. OPTIONS_FILE_SET+=DSO OPTIONS_FILE_SET+=FILE_AIO OPTIONS_FILE_SET+=THREADS OPTIONS_FILE_SET+=HTTP

Re: Открытые файлы растут после обновления до 1.14

Отлключение компрессии brotli на лету решило проблему утечки FD: brotli off; Теперь осталось понять почему оно глючит. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280210#msg-280210 ___ nginx-ru mailing list nginx-ru@nginx.org

Re: Открытые файлы растут после обновления до 1.14

Dmytro Lavryk Wrote: --- > Собрал, включил, перезапустил. > Работает часа 3. Описаного эффекта не наблюдается - все работает. Точно зажимает? Попробуйте плиз на своем ресурсе запросить что-то по https. curl -H 'Accept-Encoding: br' -I

Re: Открытые файлы растут после обновления до 1.14

Спасибо, отписал майнтейнеру порта www/nginx joneum@ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280225#msg-280225 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Открытые файлы растут после обновления до 1.14

Jochen Neumeister наконец ответил: i work on it :-) joneum Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280313#msg-280313 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Открытые файлы растут после обновления до 1.14

Отлично, проверил - проблема решилась. Всем спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280336#msg-280336 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru

proxy_next_upstream & HTTP 502

У нас стоит: proxy_next_upstream error timeout http_500 http_502 http_503 http_504; Иногда в случае если один из апстримов в дауне в access.log появляются подобные строчки: 10.10.10.10 - S387DE34EI-1557637722 [12/May/2019:05:08:42 +] "GET /blah/blah HTTP/1.1" 502 12001 "-" "-

nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/path/to/example.com/fullchain.cer"

Эти варны возникли при чтении конфига после обновления до nginx с 1.14.2 до 1.16.0 (ОС: FreeBSD 11.2). Даунгрейд до 1.14.2 убирает сообщения.. Используем сертфикаты Let's Encrypt и клиент acme.sh Конфиг SSL Stapling: ssl_stapling on; ssl_stapling_verify on; Типичный конфиг домена (коих много):

Re: nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/path/to/example.com/fullchain.cer"

-BEGIN CERTIFICATE- MIIFsjCCBJqgAwIBAgISA1J3jfFIPKXDLBQ8ihTsBqlrMA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xOTA0MDkxODIyNDFaFw0x OTA3MDgxODIyNDFaMCcxJTAjBgNVBAMTHHR1cmJvYXotMTM5NTEwNjc0LmF6c3Rh

Re: nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/path/to/example.com/fullchain.cer"

Вот эта сборка с LibreSSL проблемная. Без нее (если убрать DEFAULT_VERSIONS+=ssl=libressl из /etc/make.conf или просто поставить пакет) нет ворнингов. [rihad@master /usr/local/etc/nginx]$ nginx -V nginx version: nginx/1.16.0 built with LibreSSL 2.9.1 TLS SNI support enabled configure arguments

Re: nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/path/to/example.com/fullchain.cer"

Нашел причину. Дело в том, что нам нужен модуль brotli, а его в дефолтном пакете nginx на FreeBSD нет, поэтому строим сами www/nginx из порта, и она строится с LibreSSL. Вот с ней эти SSL stapling ворнинги бывают. Не уверен кому адресовать ) [rihad@master /usr/local/etc/nginx]$ nginx -V nginx

Актуальна ли proxy cache path inactive=NNN между рестартами?

У нас на некоторых серверах inactive стоит 90 дней, что будет если nginx перезагрузить до этого времени, сохранится ли время последнего запроса к кешированному ресурсу? Я попытался сам разобраться по коду но там сложно. file->accessed = now; в ./src/core/ngx_open_file_cache.c И потом в

Re: signer certificate not found после обновления

Не знаете есть ли обновления? Сейчас в nginx вышла дырка в http2 и пришлось обновляться с 1.16.0 до 1.16.1, но ворнинги от ssl_stapling вернулись. Дело в том что сайтов много, релоад в рамках общей задачи мы делаем довольно часто и это видит каждый пользователь, это засоряет экран и неизбежно

Re: signer certificate not found после обновления

Я избавился от ворнингов временно просто перестроив с openssl :( Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284203,285298#msg-285298 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: signer certificate not found после обновления

А можно вообще вернуться на родную openssl из фришки 11.х? Как она, стабильна? Вопросы лицензии и разного уровня "свободы" между "open" и "libre" мне безразличны. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284203,285300#msg-285300 ___

Re: signer certificate not found после обновления

В портах фришки есть еще libressl-devel, там версия 3.0.0, пересобрал nginx с ней - то же самое. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284203,285299#msg-285299 ___ nginx-ru mailing list nginx-ru@nginx.org

Re: Проксирование, буфер, лаги

Меня вот это немного смутило: "When buffering is disabled, the response is passed to a client synchronously, immediately as it is received. nginx will not try to read the whole response from the proxied server. " http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering

Проксирование, буфер, лаги

Допустим если включено кеширование через proxy_cache, а также включено proxy_buffering (по умолчанию). Что происходит когда клиент запрашивает ресурс которого нет в кеше? Он сначала полностью скачивается из апстрима, кешируется, и только потом начинает отдаваться клиенту? И если таких уровней

Re: Проксирование, буфер, лаги

Просто эта цитата в доках на английском говорит, что такое бывает при выключенном буферинге. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285149,285153#msg-285153 ___ nginx-ru mailing list nginx-ru@nginx.org

Re: Проксирование, буфер, лаги

Спасибо за ответ. Буферизация конечно включена, мне просто показалось что желаемое поведение (одновременный прием от апстрима и отправка клиенту) происходит только при выключенной буферизации. Размер буфера в несколько десятков кб роли не играет, это почти одновременно. У нас в основном картинки

could not allocate node in cache keys zone "xxx"

Когда cache loader читает эакешированные файлы при запуске nginx, если proxy_cache_path max_size недостаточно велика, вот такие ошибки начинают сыпаться под конец. Насколько это плохо? Может это повлиять на невозможность кэшировать новые файлы, и в целом на нормальную работу? Можно чтобы это

Re: SSL сертификаты

> Если загрузка кэша не завершена - nginx при обращении к элементу > кэша, которого ещё нет в памяти, явно проверяет, есть ли > соответствующий файл на диске. То есть к лишним обращениям на > бэкенд это не приводит. Глядя на объемы памяти RSS, а также на текущий обрабатываемый каталог из вывода

SSL сертификаты

Можно как-то обойтись без reload (SIGHUP) nginx для того чтобы он перечитал с диска сертификаты (ssl_certificate)? Без этого он не бывает в курсе что они были обновлены. Но у релоад есть плохая штука что он наверняка забывает такие вещи как inactive=nnn в директиве proxy_cache_path, и если reload

Re: SSL сертификаты

Спасибо! Да, проверил, если не меняется ничего, то cache loader при релоаде не запускается. Я просто релоадил когда что-то менял, поэтому подумал что всегда так ) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284950,284952#msg-284952 ___

Re: SSL сертификаты

И еще параллельно такой вопрос возник: у нас крутящиеся диски на одном из серверов, и proxy_cache_path levels=1:2 все это приводит к тому, что в каждой директории где-то 3-4 тысячи файлов (я так понимаю поменять на 2:2 + reload уже нельзя?). cache_loader при старте работает довольно долго, но не

Re: SSL сертификаты

Спасибо огромное за инфу! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284950,284955#msg-284955 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru

cache file has too long header

Эта ошибка часто в логе для разных файлов. В гугле нашел что это решается увеличением proxy_buffer_size, но он и так у нас 8k. Подскажите как решить. Версия 1.16.1, OS FreeBSD 11.3. Из-за этой ошибки кеш игнорируется и ресурс запрашивается из апстрима, а это дорогой контент (google maps). Проблема

Re: cache file has too long header

Спасибо, а чего оно за полтора года не перекочевало из devel в mainline? У нас кеш 3 уровней, поддерживать патч на каждом из них как-то не то. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285681#msg-285681 ___ nginx-ru mailing

Re: cache file has too long header

Пропатчил, построил, перезапустил через роллинг апгрейд (USR+QUIT). Я так понимаю изменение для новых файлов будет актуально т.к. хедер поменялся. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285690#msg-285690 ___ nginx-ru mailing

Re: cache file has too long header

Что любопытно после релоада нет ни одной ошибки, хотя раньше хотя бы раз в минуту было. Наверное пока cache loader запущен этих ситуаций не возникает. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285691#msg-285691 ___ nginx-ru

Re: cache file has too long header

cache loader давно вышел, новых записей "too long header" в логе пока нет. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285692#msg-285692 ___ nginx-ru mailing list nginx-ru@nginx.org

Re: cache file has too long header

А это не повлияет на другие ресурсы, кроме maps? Например если будет закеширован контент, отличающийся по языку, он правильно будет отдан? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285686#msg-285686 ___ nginx-ru mailing list

Non-idempotent requests vs. upstream failover

В случае если proxy апстрим не доступен на уровне сокета (ECONNREFUSED, а не просто вернулось HTTP 5хх), будет ли nginx ретраить POST запрос на следующих апстримах? По идее должен т.к. запрос никем не был принят и обработан. Posted at Nginx Forum:

Re: Non-idempotent requests vs. upstream failover

Спасибо, а логируется ли в таких случаях в error log? Или только если все апстримы фейлнули? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285751,285753#msg-285753 ___ nginx-ru mailing list nginx-ru@nginx.org

Re: cache file has too long header

Может лучше будет создать тикет здесь, чтобы не затерялось? https://trac.nginx.org/nginx/report/1 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,286008#msg-286008 ___ nginx-ru mailing list nginx-ru@nginx.org

Re: cache file has too long header

Ни одной записи за сутки! Вот вам фидбяк ) Спасибо. Надеюсь патч появится в релизах. Для его проявления не нужно каких-то крупных деплоев, если я правильно понял, а только чтобы апстрим возвращал нгинксу Vary для кешируемого ресурса. Posted at Nginx Forum: