upstream sent too big header while reading response header from upstream

[Илья Шипицин]

чт, 6 мар. 2025 г. в 17:55, Hennadii Makhomed <gmm на csdoc.com>:

> On 06.03.2025 11:54, Илья Шипицин wrote:
>
>  >> upstream sent too big header
>  >> while reading response header from upstream
>
>  > в данном случае имеется в виду весь header,
>  > не какой-то конкретный заголовок
>
> директива fastcgi_buffer_size задает размер буфера для чтения
> заголовка ответа от апстрима, а директива fastcgi_buffers задает
> число и размер буферов которые потом уже используются для чтения
> тела ответа от апстрима. соответственно, чтобы убрать 502 ошибку
> достаточно будет просто увеличивать fastcgi_buffer_size на размер
> еще одной страницы памяти, для x86_64 - это ровно 4096 байт.
>
> по умолчанию, этого буфера размер равен 4K, если есть 502 ошибки -
> увеличиваем 4, 8, 12, 16, 20, 24, 28, 32, 36, 40,... до тех пор,
> пока 502 ошибки полностью не пропадут. и все, - проблема решена!
>
> а размер каждого буфера в fastcgi_buffers - увеличивать не надо,
> и лучше оставить равным размеру страницы, чтобы не было впустую
> расходования памяти, вместо этого лучше увеличить их количество,
> они же выделяются не все сразу, а только по мере необходиомости.
>
> зачем же тогда в интернете такое большое количество рекомендаций
> делать большой размер одного буфера в директиве fastcgi_buffers?
>
>  > увеличение размера буферов --> увеличение расхода памяти.
>  > если она есть в достатке, почему бы и нет.
>
> вне зависимости от того, сколько там есть памяти, все равно,
> убрать эту 502 ошибку можно только увеличивая размер буфера
> с помощою директивы fastcgi_buffer_size - и других вариантов
> тут нет, если backend должен вернуть именно такие заголовки.
>
> пока что остановился на таком наборе директив:
>
>      fastcgi_buffer_size         8k;
>      fastcgi_busy_buffers_size  16k;
>      fastcgi_buffers          16 4k;
>
>      proxy_buffer_size           8k;
>      proxy_busy_buffers_size    16k;
>      proxy_buffers            16 4k;
>
> Илья, спасибо, что помогли мне лучше разобраться с этим вопросом.
>
> P.S.
>
> freenginx уже не развивается, последнее обновление там было 2024-09-03.
>
> из живых форков nginx остались только nginx, OpenResty, Tengine и Angie.
>
> осталось только 4 варианта nginx, если не считать коммерческие версии.
>
> >>> у всех ли стоит задача максимально разгрузить бекенд ?
> >>
> >> а разве нет?
> >
> > сильно зависит от бекенда. если бекенд вполне современный
> > и не имеет проблем с c10k, то дополнительная буферизация не нужна.
> > мы перед asp.net выключали буферизацию. отлично работало.
> >
> > какой смысл ? терминация ssl, высокая плотность хостинга на белых
> адресах,
> > L7 маршрутизация по локейшенам.
>
> для такого набора задач - разве не будет лучше использовать haproxy ?
>

одинаково хороши, что nginx, что haproxy.
вопрос в усилиях на миграцию, если что-то уже внедрено.


>
> https://en.wikipedia.org/wiki/HAProxy
>
> HAProxy was written in 2000 by Willy Tarreau,
> a core contributor to the Linux kernel,
> who still maintains the project.
>
> тут это оффтопик наверное, но в open source версии haproxy, как я понял
> из документации, есть такие возможности настроки очередей и приоритетов,
> каких нет даже в коммерческой версии nginx и тем более в open source
> версии nginx, так что для терминации TLS, маршрутизации и приоретизации
> запросов - наверное haproxy еще лучше подходит? В том числе и уровень
> защиты от  DDoS можно значительно повысить, разбив все клиентские
> подключения на классы, и в первую очередь обслуживая запросы от
> целевой аудитории, а те страны из которых приходят как правило
> только DDoS-запросы - обслуживать в самом конце списка приоритетов,
> только если будут свободными ресурсы сервера и не будет более
> приоритетных и более важных запросов от целевой аудитории
> и ботов поисковых систем. Такой алгоритм haproxy, как я понял
> из их документации, позволяет сделать. это же очень хорошие
> возможности, позволяют сделать сайт гораздо более защищенным
> от DDoS-атак и это позволит "максимально разгрузить бекенд".
>

нет, к сожалению, в части "быстро вычитать терабайт с бекенда, сложить его
временно на диск" haproxy не поможет.
on disk буферов не умеет.



>
> очереди есть только в платной версии nginx, а приоритетов -
> нет даже и в платной версии nginx, насколько я помню из доки.
>
> и Максим Дунин сказал, что не надо надеяться на то, что очереди
> из платной версии nginx когда-либо появятся в бесплатной версии.
>
>
> --
> Best regards,
>   Gena
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20250306/6086750b/attachment-0001.htm>