<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">чт, 6 мар. 2025 г. в 17:55, Hennadii Makhomed <<a href="mailto:gmm@csdoc.com">gmm@csdoc.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 06.03.2025 11:54, Илья Шипицин wrote:<br>
<br>
>> upstream sent too big header<br>
>> while reading response header from upstream<br>
<br>
> в данном случае имеется в виду весь header,<br>
> не какой-то конкретный заголовок<br>
<br>
директива fastcgi_buffer_size задает размер буфера для чтения<br>
заголовка ответа от апстрима, а директива fastcgi_buffers задает<br>
число и размер буферов которые потом уже используются для чтения<br>
тела ответа от апстрима. соответственно, чтобы убрать 502 ошибку<br>
достаточно будет просто увеличивать fastcgi_buffer_size на размер<br>
еще одной страницы памяти, для x86_64 - это ровно 4096 байт.<br>
<br>
по умолчанию, этого буфера размер равен 4K, если есть 502 ошибки -<br>
увеличиваем 4, 8, 12, 16, 20, 24, 28, 32, 36, 40,... до тех пор,<br>
пока 502 ошибки полностью не пропадут. и все, - проблема решена!<br>
<br>
а размер каждого буфера в fastcgi_buffers - увеличивать не надо,<br>
и лучше оставить равным размеру страницы, чтобы не было впустую<br>
расходования памяти, вместо этого лучше увеличить их количество,<br>
они же выделяются не все сразу, а только по мере необходиомости.<br>
<br>
зачем же тогда в интернете такое большое количество рекомендаций<br>
делать большой размер одного буфера в директиве fastcgi_buffers?<br>
<br>
> увеличение размера буферов --> увеличение расхода памяти.<br>
> если она есть в достатке, почему бы и нет.<br>
<br>
вне зависимости от того, сколько там есть памяти, все равно,<br>
убрать эту 502 ошибку можно только увеличивая размер буфера<br>
с помощою директивы fastcgi_buffer_size - и других вариантов<br>
тут нет, если backend должен вернуть именно такие заголовки.<br>
<br>
пока что остановился на таком наборе директив:<br>
<br>
fastcgi_buffer_size 8k;<br>
fastcgi_busy_buffers_size 16k;<br>
fastcgi_buffers 16 4k;<br>
<br>
proxy_buffer_size 8k;<br>
proxy_busy_buffers_size 16k;<br>
proxy_buffers 16 4k;<br>
<br>
Илья, спасибо, что помогли мне лучше разобраться с этим вопросом.<br>
<br>
P.S.<br>
<br>
freenginx уже не развивается, последнее обновление там было 2024-09-03.<br>
<br>
из живых форков nginx остались только nginx, OpenResty, Tengine и Angie.<br>
<br>
осталось только 4 варианта nginx, если не считать коммерческие версии.<br>
<br>
>>> у всех ли стоит задача максимально разгрузить бекенд ?<br>
>><br>
>> а разве нет?<br>
> <br>
> сильно зависит от бекенда. если бекенд вполне современный<br>
> и не имеет проблем с c10k, то дополнительная буферизация не нужна.<br>
> мы перед <a href="http://asp.net" rel="noreferrer" target="_blank">asp.net</a> выключали буферизацию. отлично работало.<br>
> <br>
> какой смысл ? терминация ssl, высокая плотность хостинга на белых адресах,<br>
> L7 маршрутизация по локейшенам.<br>
<br>
для такого набора задач - разве не будет лучше использовать haproxy ?<br></blockquote><div><br></div><div>одинаково хороши, что nginx, что haproxy.</div><div>вопрос в усилиях на миграцию, если что-то уже внедрено.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<a href="https://en.wikipedia.org/wiki/HAProxy" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/HAProxy</a><br>
<br>
HAProxy was written in 2000 by Willy Tarreau,<br>
a core contributor to the Linux kernel,<br>
who still maintains the project.<br>
<br>
тут это оффтопик наверное, но в open source версии haproxy, как я понял<br>
из документации, есть такие возможности настроки очередей и приоритетов,<br>
каких нет даже в коммерческой версии nginx и тем более в open source<br>
версии nginx, так что для терминации TLS, маршрутизации и приоретизации<br>
запросов - наверное haproxy еще лучше подходит? В том числе и уровень<br>
защиты от DDoS можно значительно повысить, разбив все клиентские<br>
подключения на классы, и в первую очередь обслуживая запросы от<br>
целевой аудитории, а те страны из которых приходят как правило<br>
только DDoS-запросы - обслуживать в самом конце списка приоритетов,<br>
только если будут свободными ресурсы сервера и не будет более <br>
приоритетных и более важных запросов от целевой аудитории<br>
и ботов поисковых систем. Такой алгоритм haproxy, как я понял<br>
из их документации, позволяет сделать. это же очень хорошие<br>
возможности, позволяют сделать сайт гораздо более защищенным<br>
от DDoS-атак и это позволит "максимально разгрузить бекенд".<br></blockquote><div><br></div><div>нет, к сожалению, в части "быстро вычитать терабайт с бекенда, сложить его временно на диск" haproxy не поможет.</div><div>on disk буферов не умеет.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
очереди есть только в платной версии nginx, а приоритетов -<br>
нет даже и в платной версии nginx, насколько я помню из доки.<br>
<br>
и Максим Дунин сказал, что не надо надеяться на то, что очереди<br>
из платной версии nginx когда-либо появятся в бесплатной версии.<br>
<br>
<br>
-- <br>
Best regards,<br>
Gena<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="https://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">https://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
</blockquote></div></div>