Проверил:
nginx -T | grep listen -- только TCP-порты
nginx -T | grep unix: -- только fastcgi_pass
ss -nlp | grep -w nginx -- только TCP-порты
nginx -T | grep access_log -- только стандартный и combined
Единственный сторонний модуль - nchan
Возможно, дело действительно в нём, потому что пустой re
Дано: nginx 1.18.0-0ubuntu1.2 и access_log по умолчанию.
Проблема: некоторые записи в access.log содержат пустой IP клиента.
Примеры (обе строки начинаются с пробела, фактические запросы заменил на
"..."):
- - [25/Jan/2022:07:56:46 +0300] "GET /... HTTP/1.1" 410 198 "-"
"Mozilla/5.0 (Windows NT
Имеется nginx 1.19.2 со следующей настройкой:
server {
location / {
if ($http_user_agent ~ "TestAgent") { }
try_files $uri $uri/ /index.html;
}
}
Проверяю:
1) curl http://127.0.0.1/unknown -- правильно возвращает index.html
2) curl http://127.0.0.1
Имеется Nginx:
nginx version: nginx/1.17.8
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC)
built with OpenSSL 1.1.0 (compatible; BoringSSL) (running with
BoringSSL)
TLS SNI support enabled
В настройках указано:
add_header X-SSLEarly $ssl_early_data always;
ad
Есть Nginx 1.17.8, собран со свежей BoringSSL stable.
Запущен на Linux kernel 5.4.10:
nginx version: nginx/1.17.8
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC)
built with OpenSSL 1.1.0 (compatible; BoringSSL) (running with BoringSSL)
TLS SNI support enabled
configure arguments:
--prefix=/e
Nginx 1.15.11
Система - CentOS 7 с ядром 4.18
/data живёт на Cepf.
Обнаружено преждевременное удаление файлов из кэша Nginx.
Кэш настроен так:
proxy_cache_path /data/user123/nginx_cache keys_zone=user123:3000m
max_size=2g inactive=30d levels=1:2 use_temp_path=off;
В /data/user123/nginx_c
Имеется Nginx 1.15.6, sendfile включен.
Смотрю "strace -p$NGINX_WORKER_PID -e sendfile" и вижу что-то вроде:
sendfile(1072, 1130, [737360], 281171) = -1 EAGAIN (Resource temporarily
unavailable)
sendfile(1072, 1130, [737360] => [932840], 281171) = 195480
sendfile(1072, 1130, [932840], 85691) =
> Вытаскивать миллисекунды в error log - мы в своё время думали, но,
кажется, проблем от этого больше,
> чем пользы. Особенно с учётом того, что время nginx в норме обновляет один
раз за итерацию
> event loop'а, и все сообщения между уходами в ядро будут использовать одно
и то же время.
Если милли
Вижу "timer delta: %M" в выводе "strings nginx-debug", но не вижу ни одной
строки с ним в error_log.
Упоминания про таймер только такие:
2019/02/05 09:38:23 [debug] 18108#18108: *5453 event timer add: 15:
75000:435707458
2019/02/05 09:38:23 [debug] 18108#18108: *5453 event timer del: 15:
43570745
Пытаюсь отладить тормоза на одном из серверов Nginx.
Включил "error_log ... debug"
Проблема в том, что записи туда пишутся с секундной точностью.
Есть ли возможность обеспечить миллисекундную?
Написал патч, но ещё не проверил:
https://gist.github.com/ilyaevseev/ca636314e1ba2a7889c7efca5d85f594
Po
Intel и Alibaba создали свои ветки Nginx'a, которые используют для SSL
асинхронный режим и аппаратную акселерацию QAT.
Было ли обсуждение презентации Интела на NginxConf?
Планируется принимать их наработки в Nginx?
Или асинхронный режим не имеет смысла без аппаратной акселерации, а
аппаратная аксе
А парсинг конфига - это операция по определению однопоточная?
Её никак не распараллелить?
Пользователи меняют настройки своих сайтов довольно часто, при этом
автоматически перестраивается конфиг nginx'a и вызывается nginx -t && nginx
-s reload.
Пока https был не в моде, это происходило мгновенно.
К
Имеется конфигурация с ~500-600 сайтов, из них примерно 10% с поддержкой
https, в остальных только http.
wildcard-ключ с сертификатом указан в блоке "http".
Обратил внимание, что "nginx -t" и "nginx -s reload" стали отрабатывать
секунд по 10.
Профайлер говорит, что 90% времени уходит на ngx_http_
Обычно RPM появляется сразу, но 1.14 вышел 10 дней назад, а RPM до сих пор
нет.
Когда ориентировочно он появится?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,279622,279622#msg-279622
___
nginx-ru mailing list
nginx-ru@nginx.org
http://m
Есть Nginx-frontend, он может вернуть Error 502 "Bad Gateway", если backend
недоступен.
Есть Nginx-backend, он тоже может вернуть Error 502.
Как научить Nginx-frontend возвращать в случае недоступности backend'a не
502, а 523 "Origin is unreachable"?
Posted at Nginx Forum:
https://forum.nginx.or
Дано: nginx 1.13.5 под CentOS 7.3
В perf top:
Children, Self Command, Shared Object,
Symbol
- 27,63% 0,00% nginx[unknown] [.]
- 0
24,87% ngx_resolver_lookup_name.isra.1
- 2,76% __libc_writev
Д
Когда ошибка случается, h->body_start почему-то всегда больше c->body_start
ровно на один байт:
$ perl -ne 'print "$1 $2\n" if /has too long header \(actual = (\d+),
required = (\d+)\)/' /var/log/nginx/error.log
730 729
734 733
732 731
724 723
734 733
737 736
722 721
729 728
729 728
750 749
750 74
У нас уже включено:
proxy_cache_use_stale updating error timeout invalid_header http_500
http_502 http_503 http_504;
proxy_cache_lock on;
proxy_cache_lock_age 1m;
proxy_cache_lock_timeout 1m;
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,276273,276304#msg-276304
___
Патч вылечил ошибку с подвисанием. Но как быть с "too long header"?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,276273,276301#msg-276301
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Написал патч для более подробной диагностики:
https://gist.github.com/ilyaevseev/f2c57519db829329f8e9f9aff5d51789
Попутно нашел ошибку в Nginx:
1) wget http://nginx-frontend/cached-upstream-file
2) ищем на nginx-сервере файл в кэше, удаляем всё, начиная от пары последних
строк заголовка HTTP-ответ
nginx/1.13.4 64bit под CentOS7.
Редко, но регулярно выдаёт ошибку "cache file ... has too long header"
Прочёл всё, что написано по данному поводу:
1) https://forum.nginx.org/read.php?21,243579,243589#msg-243589
2)
http://nginx.2469901.n2.nabble.com/cache-file-has-too-long-header-bug-td7594976.html
То есть получается, что лучше всего использовать только net.ipv4.tcp_wmem
и вообще никогда не указывать "listen ... sndbuf=..." в nginx.conf,
чтобы он не вызвал setsockopt и не отключал автонастройку в ядре?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,274966,274996#msg-274996
>
> В данном случае хороший ответ на этот вопрос не прослеживается,
> так как автотюнинг буферов сейчас во всех популярных операционных
> системах есть, в том числе на линуксе.
>
Автотюнинг буферов - это что именно?
Есть sysctl net.ipv4.tcp_wmem с тремя значениями:
минимально разрешенное, по умол
Написал небольшой патч, который автоматически увеличивает размер буфера
отправки, если sendfile вернул EAGAIN.
Вызывается из
https://trac.nginx.org/nginx/browser/nginx/src/os/unix/ngx_linux_sendfile_chain.c#L265
Вопросы:
1) имеет смысл доводить патч до такого вида, который примут в nginx? или
та
Имеется плагин, который через fork запускает NGX_PROCESS_HELPER для
выполнения долгой операции. Фоновый процесс иногда не реагирует на "nginx -s
reopen" и продолжает держать открытыми все log-файлы.
Это мешает их ротации и парсингу.
Поэтому в качестве временного решения хотелось бы закрывать log-ф
25 matches
Mail list logo