Re: [warn] a client request body is buffered to a temporary file
On Wed, Jul 13, 2022, 2:01 AM Gena Makhomed wrote: > On 12.07.2022 22:27, Илья Шипицин wrote: > > >> Директива proxy_max_temp_file_size 0; на nginx frontend у меня прописана > >> Но она влияет только на буферизацию проксируемых от backend`ов ответов. > >> > >> Полностью отключить использование диска nginx frontend > >> для проксирования и запросов и ответов можно > >> с помощью такого набора директив: > >> > >> proxy_http_version 1.1; > >> proxy_request_buffering off; > >> proxy_max_temp_file_size 0; > > > не совсем верно. если не трогать proxy_buffering, то ответы буферизуются > (в > > памяти, но не на диске) > > proxy_buffering почти всегда лучше оставлять включенным, потому что > nginx работает более эффективно, если буферизация в памяти включена > подробности здесь: https://marc.info/?l=nginx&m=131739590508332&w=2 > > >> Однако это имеет смысл только в том случае, если nginx frontend > >> проксирует запросы на nginx backend, на котором включена буферизация > > > если у бекенда форк-модель, и дорогое подключение, которое желательно > > максимально быстро освободить, даже ценой буферизации на диск, то да. > > > для многих современных бекендов, включач php-fpm, поддержание 10к > > одновременных подключений не является проблемой, кажется, что буферизация > > на диск скорее избыточна, и по факту не решает никаких проблем, но может > их > > создать > > У бэкенда php-fpm ведь форк-модель, и количество воркеров ограничено. > Мне почему-то помнится, что количество запущенных php-fpm процессов была константа и они не росли от нагрузки. Но, возможно fork модель, при случае проверю То есть, другими словами, php-fpm - это то же самое что и httpd apache, > только используется fastcgi протокол вместо http для подключения, > вот и вся существенная разница между ними. Подробнее об этом написано > в файле /etc/php-fpm.d/www.conf в описании директивы pm.max_children > > Для php-fpm, поддержание 10к одновременных подключений является > огромной проблемой - если каждый воркер использует, например, > 128 мегабайт оперативной памяти, то для 10_000 одновременных > подключений необходимо будет на сервере примерно 1.2 терабайта > оперативной памяти выделить только для одного лишь php-fpm. > > Если клиент будет медленно-медленно забирать ответ от веб-сервера, > при выключенной буферизации на диск воркер php-fpm будет оставаться > занятым и таким образом сервер будет легко уязвим к простой DoS-атаке. > https://en.wikipedia.org/wiki/Denial-of-service_attack#Slow_Read_attack > > -- > Best regards, > Gena > ___ > nginx-ru mailing list -- nginx-ru@nginx.org > To unsubscribe send an email to nginx-ru-le...@nginx.org > ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: [warn] a client request body is buffered to a temporary file
On 12.07.2022 23:37, Maxim Dounin wrote: Историческая справка, не имеющая отношения к обсуждаемому вопросу: эскейпинг специальных символов в access-логах делался как раз для удобного автоматического парсинга tab separated логов. Hint: кавычки вокруг произвольных строковых полей использовать не нужно, так как табы экранируются. Понял, спасибо! Процитирую ещё раз написанное в прошлом письме: В смысле - что в log_format? Следом за $status обычно идёт $body_bytes_sent, и это размер тела ответа, имеющий приблизительно никакого отношения к размеру тела запроса. Из приведённой строки лога мы не знаем размер тела запроса, он может быть любой. Видимое значение 41 - это размер ответа, и он не имеет к телу запроса примерно никакого отношения. Судя по тому, что тело запроса в буфер не помещается - оно больше 16 килобайт. Да, Вы правы, размер тела запроса был больше 16 килобайт, поэтому он и буферизировался на диск. Теперь понял, спасибо! Прописал в конфиге nginx frontend такие директивы: proxy_http_version 1.1; proxy_request_buffering off; proxy_max_temp_file_size 0; И теперь у меня в логах nginx frontend вообще нет варнингов о том, что a client request body is buffered to a temporary file. Теперь на том сервере - в логах все 100% сообщений про ошибки - это "ошибки" access forbidden by rule -- Best regards, Gena ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: [warn] a client request body is buffered to a temporary file
On 12.07.2022 22:27, Илья Шипицин wrote: Директива proxy_max_temp_file_size 0; на nginx frontend у меня прописана Но она влияет только на буферизацию проксируемых от backend`ов ответов. Полностью отключить использование диска nginx frontend для проксирования и запросов и ответов можно с помощью такого набора директив: proxy_http_version 1.1; proxy_request_buffering off; proxy_max_temp_file_size 0; не совсем верно. если не трогать proxy_buffering, то ответы буферизуются (в памяти, но не на диске) proxy_buffering почти всегда лучше оставлять включенным, потому что nginx работает более эффективно, если буферизация в памяти включена подробности здесь: https://marc.info/?l=nginx&m=131739590508332&w=2 Однако это имеет смысл только в том случае, если nginx frontend проксирует запросы на nginx backend, на котором включена буферизация если у бекенда форк-модель, и дорогое подключение, которое желательно максимально быстро освободить, даже ценой буферизации на диск, то да. для многих современных бекендов, включач php-fpm, поддержание 10к одновременных подключений не является проблемой, кажется, что буферизация на диск скорее избыточна, и по факту не решает никаких проблем, но может их создать У бэкенда php-fpm ведь форк-модель, и количество воркеров ограничено. То есть, другими словами, php-fpm - это то же самое что и httpd apache, только используется fastcgi протокол вместо http для подключения, вот и вся существенная разница между ними. Подробнее об этом написано в файле /etc/php-fpm.d/www.conf в описании директивы pm.max_children Для php-fpm, поддержание 10к одновременных подключений является огромной проблемой - если каждый воркер использует, например, 128 мегабайт оперативной памяти, то для 10_000 одновременных подключений необходимо будет на сервере примерно 1.2 терабайта оперативной памяти выделить только для одного лишь php-fpm. Если клиент будет медленно-медленно забирать ответ от веб-сервера, при выключенной буферизации на диск воркер php-fpm будет оставаться занятым и таким образом сервер будет легко уязвим к простой DoS-атаке. https://en.wikipedia.org/wiki/Denial-of-service_attack#Slow_Read_attack -- Best regards, Gena ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: [warn] a client request body is buffered to a temporary file
Hello! On Tue, Jul 12, 2022 at 08:55:35PM +0300, Gena Makhomed wrote: > On 12.07.2022 18:40, Maxim Dounin wrote: > > > А что у вас по осям? (c) > > > > В смысле - что в log_format? Следом за $status обычно идёт > > $body_bytes_sent, и это размер тела ответа, имеющий приблизительно > > никакого отношения к размеру тела запроса. > > На том сервере log_format такой: > > log_format frontend '$time_iso8601\t$geoip_country_code\t$remote_addr\t' > '$scheme\t$host\t$request_method\t"$request_uri"\t' > '$status\t$body_bytes_sent\t"$http_referer"\t' > '"$http_user_agent"\t$request_time\t' > '$upstream_response_time'; > > Очень удобно использовать символ табуляции в качестве разделителя, > логи тогда без проблем читаются в mc и с помощью grep | less -S Историческая справка, не имеющая отношения к обсуждаемому вопросу: эскейпинг специальных символов в access-логах делался как раз для удобного автоматического парсинга tab separated логов. Hint: кавычки вокруг произвольных строковых полей использовать не нужно, так как табы экранируются. [...] > Вот еще раз все проверил только что: > > # nginx -q -T | grep client_body_buffer_size > client_body_buffer_size 16k; > > error.log: > > 2022/07/12 20:23:26 [warn] 2479#2479: *63684 a client request body is > buffered to a temporary file /var/cache/nginx/client_temp/000290, > client: 111.222.33.44, server: sentry.example.com, request: "POST > /api/8/envelope/?sentry_key=xx&sentry_version=7 HTTP/2.0", host: > "sentry.example.com", referrer: "https://example.com/"; > > access.log: > > 2022-07-12T20:23:26+03:00 XX 111.222.33.44 https > sentry.example.comPOST > "/api/8/envelope/?sentry_key=xx&sentry_version=7" 200 41 >"https://example.com/"; "Mozilla/5.0 (Windows NT 10.0; Win64; x64) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36" >0.037 0.002 > > Размер контента - всего 41 байт, что гораздо меньше чем 16 килобайт, > и тем не менее, контент все равно пишется на диск зачем-то. > Как такое может быть? Процитирую ещё раз написанное в прошлом письме: > > В смысле - что в log_format? Следом за $status обычно идёт > > $body_bytes_sent, и это размер тела ответа, имеющий приблизительно > > никакого отношения к размеру тела запроса. Из приведённой строки лога мы не знаем размер тела запроса, он может быть любой. Видимое значение 41 - это размер ответа, и он не имеет к телу запроса примерно никакого отношения. Судя по тому, что тело запроса в буфер не помещается - оно больше 16 килобайт. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: [warn] a client request body is buffered to a temporary file
вт, 12 июл. 2022 г. в 22:56, Gena Makhomed :
> On 12.07.2022 18:40, Maxim Dounin wrote:
>
> > А что у вас по осям? (c)
> >
> > В смысле - что в log_format? Следом за $status обычно идёт
> > $body_bytes_sent, и это размер тела ответа, имеющий приблизительно
> > никакого отношения к размеру тела запроса.
>
> На том сервере log_format такой:
>
> log_format frontend '$time_iso8601\t$geoip_country_code\t$remote_addr\t'
> '$scheme\t$host\t$request_method\t"$request_uri"\t'
> '$status\t$body_bytes_sent\t"$http_referer"\t'
> '"$http_user_agent"\t$request_time\t'
> '$upstream_response_time';
>
если рассматривать с точки зрения эффективного использования диска, то поля
$scheme, $host являются практически константами, можно не логировать их на
каждую строчку лога (а, например, разнести разные host-ы по разным логам).
и, если поля разделяются табуляцией, то кавычки избыточны
в качестве ориентира удобно брать число байт в 1 строке лога
>
> Очень удобно использовать символ табуляции в качестве разделителя,
> логи тогда без проблем читаются в mc и с помощью grep | less -S
>
и еще в Microsoft LogParser, Clickhouse, awk,
>
> Софтом лог с разделителем в виде символа табуляции парсить удобно:
> time, geoip_country_code, remote_addr, ... = line.split('\t')
>
> Применяю этот метод в https://github.com/makhomed/autofilter
> потому что NGINX App Protect Denial of Service слишком дорого.
>
> Вот еще раз все проверил только что:
>
> # nginx -q -T | grep client_body_buffer_size
> client_body_buffer_size 16k;
>
> error.log:
>
> 2022/07/12 20:23:26 [warn] 2479#2479: *63684 a client request body is
> buffered to a temporary file /var/cache/nginx/client_temp/000290,
> client: 111.222.33.44, server: sentry.example.com, request: "POST
> /api/8/envelope/?sentry_key=xx&sentry_version=7 HTTP/2.0", host:
> "sentry.example.com", referrer: "https://example.com/";
>
> access.log:
>
> 2022-07-12T20:23:26+03:00 XX 111.222.33.44 https
> sentry.example.comPOST
> "/api/8/envelope/?sentry_key=xx&sentry_version=7" 200 41
>"https://example.com/"; "Mozilla/5.0 (Windows NT 10.0; Win64; x64)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36"
>0.037 0.002
>
> Размер контента - всего 41 байт, что гораздо меньше чем 16 килобайт,
> и тем не менее, контент все равно пишется на диск зачем-то.
> Как такое может быть?
>
> --
> Best regards,
> Gena
> ___
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-le...@nginx.org
>
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: [warn] a client request body is buffered to a temporary file
ср, 13 июл. 2022 г. в 00:16, Gena Makhomed : > On 12.07.2022 20:12, Илья Шипицин wrote: > > >> и еще примерно 20% - это "предупреждения" о том, что > >> a client request body is buffered to a temporary file > > > это же можно выключить через proxy_request_buffering ? > > Да, в моем случае - это вполне подходит, спасибо. > > proxy_http_version 1.1; > proxy_request_buffering off; > > Потому что у меня у каждого nginx frontend > есть всего один nginx backend для каждого сайта: > nginx frontend <=> nginx backend <=> php-fpm > > Самое главное - не забыть включить директиву proxy_http_version 1.1; > на nginx frontend, иначе будут проблемы из-за использования HTTP/1.0 > > > https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_request_buffering > > When HTTP/1.1 chunked transfer encoding is used to send the original > request body, the request body will be buffered regardless of the > directive value unless HTTP/1.1 is enabled for proxying. > HTTP/1.1 обычно включаю, но до этого места в документации про chunked не дочитал )) > > >> Еще - было бы очень хорошо, чтобы nginx умел писать логи на диск > >> не до тех пор, пока там останется 0 байт свободного места, а хотя > >> бы оставлял 1 гигабайт для файлов в /var/cache/nginx/client_temp > > > буферизация на диск имеет кучу побочных эффектов. > > можно через Модуль ngx_http_proxy_module (nginx.org) > > < > https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size > > > > выключить дисковую часть (оставив буферизацию в памяти) > > Директива proxy_max_temp_file_size 0; на nginx frontend у меня прописана > Но она влияет только на буферизацию проксируемых от backend`ов ответов. > > Полностью отключить использование диска nginx frontend > для проксирования и запросов и ответов можно > с помощью такого набора директив: > > proxy_http_version 1.1; > proxy_request_buffering off; > proxy_max_temp_file_size 0; > не совсем верно. если не трогать proxy_buffering, то ответы буферизуются (в памяти, но не на диске) > > Однако это имеет смысл только в том случае, если nginx frontend > проксирует запросы на nginx backend, на котором включена буферизация если у бекенда форк-модель, и дорогое подключение, которое желательно максимально быстро освободить, даже ценой буферизации на диск, то да. для многих современных бекендов, включач php-fpm, поддержание 10к одновременных подключений не является проблемой, кажется, что буферизация на диск скорее избыточна, и по факту не решает никаких проблем, но может их создать > > запросов и ответов на диск. Если в качестве backend`а используется > httpd apache - использование диска для буферизации > наверное лучше будет не выключать. > верно > > -- > Best regards, > Gena > ___ > nginx-ru mailing list -- nginx-ru@nginx.org > To unsubscribe send an email to nginx-ru-le...@nginx.org > ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
[warn] a client request body is buffered to a temporary file
On 12.07.2022 20:12, Илья Шипицин wrote: и еще примерно 20% - это "предупреждения" о том, что a client request body is buffered to a temporary file это же можно выключить через proxy_request_buffering ? Да, в моем случае - это вполне подходит, спасибо. proxy_http_version 1.1; proxy_request_buffering off; Потому что у меня у каждого nginx frontend есть всего один nginx backend для каждого сайта: nginx frontend <=> nginx backend <=> php-fpm Самое главное - не забыть включить директиву proxy_http_version 1.1; на nginx frontend, иначе будут проблемы из-за использования HTTP/1.0 https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_request_buffering When HTTP/1.1 chunked transfer encoding is used to send the original request body, the request body will be buffered regardless of the directive value unless HTTP/1.1 is enabled for proxying. Еще - было бы очень хорошо, чтобы nginx умел писать логи на диск не до тех пор, пока там останется 0 байт свободного места, а хотя бы оставлял 1 гигабайт для файлов в /var/cache/nginx/client_temp буферизация на диск имеет кучу побочных эффектов. можно через Модуль ngx_http_proxy_module (nginx.org) <https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size> выключить дисковую часть (оставив буферизацию в памяти) Директива proxy_max_temp_file_size 0; на nginx frontend у меня прописана Но она влияет только на буферизацию проксируемых от backend`ов ответов. Полностью отключить использование диска nginx frontend для проксирования и запросов и ответов можно с помощью такого набора директив: proxy_http_version 1.1; proxy_request_buffering off; proxy_max_temp_file_size 0; Однако это имеет смысл только в том случае, если nginx frontend проксирует запросы на nginx backend, на котором включена буферизация запросов и ответов на диск. Если в качестве backend`а используется httpd apache - использование диска для буферизации наверное лучше будет не выключать. -- Best regards, Gena ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: [warn] a client request body is buffered to a temporary file
On 12.07.2022 18:40, Maxim Dounin wrote:
А что у вас по осям? (c)
В смысле - что в log_format? Следом за $status обычно идёт
$body_bytes_sent, и это размер тела ответа, имеющий приблизительно
никакого отношения к размеру тела запроса.
На том сервере log_format такой:
log_format frontend '$time_iso8601\t$geoip_country_code\t$remote_addr\t'
'$scheme\t$host\t$request_method\t"$request_uri"\t'
'$status\t$body_bytes_sent\t"$http_referer"\t'
'"$http_user_agent"\t$request_time\t'
'$upstream_response_time';
Очень удобно использовать символ табуляции в качестве разделителя,
логи тогда без проблем читаются в mc и с помощью grep | less -S
Софтом лог с разделителем в виде символа табуляции парсить удобно:
time, geoip_country_code, remote_addr, ... = line.split('\t')
Применяю этот метод в https://github.com/makhomed/autofilter
потому что NGINX App Protect Denial of Service слишком дорого.
Вот еще раз все проверил только что:
# nginx -q -T | grep client_body_buffer_size
client_body_buffer_size 16k;
error.log:
2022/07/12 20:23:26 [warn] 2479#2479: *63684 a client request body is
buffered to a temporary file /var/cache/nginx/client_temp/000290,
client: 111.222.33.44, server: sentry.example.com, request: "POST
/api/8/envelope/?sentry_key=xx&sentry_version=7 HTTP/2.0", host:
"sentry.example.com", referrer: "https://example.com/";
access.log:
2022-07-12T20:23:26+03:00 XX 111.222.33.44 https
sentry.example.comPOST
"/api/8/envelope/?sentry_key=xx&sentry_version=7" 200 41
"https://example.com/"; "Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36"
0.037 0.002
Размер контента - всего 41 байт, что гораздо меньше чем 16 килобайт,
и тем не менее, контент все равно пишется на диск зачем-то.
Как такое может быть?
--
Best regards,
Gena
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: [warn] a client request body is buffered to a temporary file
Hello! On Tue, Jul 12, 2022 at 02:42:44PM +0300, Gena Makhomed wrote: > Здравствуйте, All! > > nginx/1.23.0 из официального репозитория nginx.org > > В логах есть такой варнинг: > > 2022/07/12 13:56:37 [warn] 14352#14352: *183 a client request body is > buffered to a temporary file /var/cache/nginx/client_temp/11, > client: 10.23.154.207, server: sentry.example.com, request: "POST > /api/22/envelope/ HTTP/2.0", host: "sentry.example.com" > > Судя по информации из access-лога - размер контента - 41 байт: > > # grep /api/22/envelope/ access.log | grep 13:56:37 | less > 2022-07-12T13:56:37+03:00 GB 10.23.154.207 https > sentry.example.comPOST"/api/22/envelope/" 200 41 >"-" "sentry.php.laravel/2.9.0" 0.010 0.002 > > Если прописать в nginx.conf директиву client_body_buffer_size 32k; > - тогда варнинг из error.log пропадает, но если вернуть дефолтовое > значение client_body_buffer_size 16k; - варнинг снова появляется логах. > > Размер контента - всего 41 байт. Как такое может быть? А что у вас по осям? (c) В смысле - что в log_format? Следом за $status обычно идёт $body_bytes_sent, и это размер тела ответа, имеющий приблизительно никакого отношения к размеру тела запроса. > client_body_buffer_size - эта переменная задает только статический > размер буфера, и в nginx сейчас нельзя сделать динамическое выделение > буфера по необходимости, как это сделано в директиве proxy_buffers ? > > Возможно было бы логичним, для экономии памяти сделать возможность > задавать client_body_buffer_size по аналогии с proxy_buffers, > например так: > > client_body_buffer_size 8k; > client_body_buffers 32 8k; Возможно так когда-нибудь будет, но пока так нельзя. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
[warn] a client request body is buffered to a temporary file
Здравствуйте, All! nginx/1.23.0 из официального репозитория nginx.org В логах есть такой варнинг: 2022/07/12 13:56:37 [warn] 14352#14352: *183 a client request body is buffered to a temporary file /var/cache/nginx/client_temp/11, client: 10.23.154.207, server: sentry.example.com, request: "POST /api/22/envelope/ HTTP/2.0", host: "sentry.example.com" Судя по информации из access-лога - размер контента - 41 байт: # grep /api/22/envelope/ access.log | grep 13:56:37 | less 2022-07-12T13:56:37+03:00 GB 10.23.154.207 https sentry.example.comPOST"/api/22/envelope/" 200 41 "-" "sentry.php.laravel/2.9.0" 0.010 0.002 Если прописать в nginx.conf директиву client_body_buffer_size 32k; - тогда варнинг из error.log пропадает, но если вернуть дефолтовое значение client_body_buffer_size 16k; - варнинг снова появляется логах. Размер контента - всего 41 байт. Как такое может быть? client_body_buffer_size - эта переменная задает только статический размер буфера, и в nginx сейчас нельзя сделать динамическое выделение буфера по необходимости, как это сделано в директиве proxy_buffers ? Возможно было бы логичним, для экономии памяти сделать возможность задавать client_body_buffer_size по аналогии с proxy_buffers, например так: client_body_buffer_size 8k; client_body_buffers 32 8k; -- Best regards, Gena ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: a client request body is buffered to a temporary file
Hello! On Thu, Jul 26, 2018 at 08:57:17AM +0300, Vladimir Sopot wrote: > Спасибо, настроили $content_length. Стало ещё страннее. При настройках > > client_max_body_size 100m; > client_body_buffer_size 100m; > client_body_in_file_only off; > > клиенты делает POST c $content_length=61554, 566069 и тд > (немного, совсем мало) и в логе та же самая ошибка. Между этими > двумя $content_length=6849049 прошёл без ошибок Для начала - смотреть внимательно на то, 1) где обрабатывается запрос и действительно ли в соответствующем контексте, где происходит чтения тела запроса, указано "client_body_buffer_size 100m", а тело запроса при этом меньше; 2) что именно написано в сообщении. Про "buffered to a temporary file" много похожих сообщений - в частности, оно может быть про тело ответа. Если не прояснится - попробовать воспроизвести как минимум без "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди отваживаются использовать эту поделку, она при любых внутренних изменениях в nginx'е разносит всё же), а лучше - вообще без сторонних модулей. Если воспроизведётся - приносите подробности (конфиг и способ вызвать warning, либо debug log полученного warning'а). Интересует именно ситуация, когда warning выдаётся для случая размера запроса меньше client_body_buffer_size, такого быть не должно. > Бонус: время у событий в access_log-е на секунду больше, чем в > error_log-е, запросы отловлен точно, они достаточно редкие. Это нормально, warning логгируется в момент первой записи во временный файл, в access log же запрос попадает после его окончания. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: a client request body is buffered to a temporary file
Спасибо, настроили $content_length. Стало ещё страннее. При настройках client_max_body_size 100m; client_body_buffer_size 100m; client_body_in_file_only off; клиенты делает POST c $content_length=61554, 566069 и тд (немного, совсем мало) и в логе та же самая ошибка. Между этими двумя $content_length=6849049 прошёл без ошибок Бонус: время у событий в access_log-е на секунду больше, чем в error_log-е, запросы отловлен точно, они достаточно редкие. # /usr/local/nginx/sbin/nginx -V nginx version: nginx/1.15.0 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC) built with OpenSSL 1.0.2k-fips 26 Jan 2017 TLS SNI support enabled configure arguments: --without-http_uwsgi_module --without-http_scgi_module --with-http_ssl_module --with-http_stub_status_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-file-aio --with-http_image_filter_module --with-http_realip_module --add-module=../ngx_cache_purge-2.3 --add-module=../ngx_http_geoip2_module > On 17 Jul 2018, at 15:29, Maxim Dounin wrote: > > Hello! > > On Tue, Jul 17, 2018 at 01:16:14PM +0300, Vladimir Sopot wrote: > >> Хотел бы предложить добавить размер сохраняемого тела в notice >> "a client request body is buffered to a temporary file >> /wwwroot/tmp/nginx/client_body_temp/0004405740”, типа “a client >> request body (100Mb) is buffered to a temporary file >> /wwwroot/tmp/nginx/client_body_temp/0004405740”. Просто, чтобы >> понять, то ли пользователи пихают невпихуемое (и насколько) , то >> ли client_body_buffer_size закручен неправильно. > > В общем случае размер тела запроса в момент логгирования сообщения > про "client request body is buffered to a temporary file" - > неизвестен. Так что по большому счёту информацию о размере тела > запроса всё равно можно получить только из access-лога, настроив > логгирование $content_length. Само сообщение стоит рассматривать > скорее как напоминание о том, что это может иметь смысл сделать, > если использование дисковой подсистемы для тел запросов не > ожидается. > > Что до "пихают невпихуемое", то для этого есть директива > client_max_body_size, по умолчанию 1 мегабайт. > > -- > 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: a client request body is buffered to a temporary file
Hello! On Tue, Jul 17, 2018 at 01:16:14PM +0300, Vladimir Sopot wrote: > Хотел бы предложить добавить размер сохраняемого тела в notice > "a client request body is buffered to a temporary file > /wwwroot/tmp/nginx/client_body_temp/0004405740”, типа “a client > request body (100Mb) is buffered to a temporary file > /wwwroot/tmp/nginx/client_body_temp/0004405740”. Просто, чтобы > понять, то ли пользователи пихают невпихуемое (и насколько) , то > ли client_body_buffer_size закручен неправильно. В общем случае размер тела запроса в момент логгирования сообщения про "client request body is buffered to a temporary file" - неизвестен. Так что по большому счёту информацию о размере тела запроса всё равно можно получить только из access-лога, настроив логгирование $content_length. Само сообщение стоит рассматривать скорее как напоминание о том, что это может иметь смысл сделать, если использование дисковой подсистемы для тел запросов не ожидается. Что до "пихают невпихуемое", то для этого есть директива client_max_body_size, по умолчанию 1 мегабайт. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
a client request body is buffered to a temporary file
Привет! Хотел бы предложить добавить размер сохраняемого тела в notice "a client request body is buffered to a temporary file /wwwroot/tmp/nginx/client_body_temp/0004405740”, типа “a client request body (100Mb) is buffered to a temporary file /wwwroot/tmp/nginx/client_body_temp/0004405740”. Просто, чтобы понять, то ли пользователи пихают невпихуемое (и насколько) , то ли client_body_buffer_size закручен неправильно. Спасибо. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
