чт, 6 мар. 2025 г. в 17:55, Hennadii Makhomed <g...@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 >
_______________________________________________ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
