<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">чт, 6 мар. 2025 г. в 07:05, 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 05.03.2025 21:29, Илья Шипицин wrote:<br>
<br>
>> ведь никаких других способов кроме использования tcpdump<br>
>> и использования error_log /var/log/nginx/error.log debug;<br>
>> как я понимаю для поиска причины этой ошибки не существует?<br>
> <br>
> я не пробовал, но приходит в голову вариант с "error_page<br>
> 502=@some_location" и внутри some_location задать error_log<br>
> возможно, что не сработает<br>
<br>
server {<br>
     root /home/www/<a href="http://example.com/public" rel="noreferrer" target="_blank">example.com/public</a>;<br>
     location / { try_files $uri @backend; }<br>
     location @backend { fastcgi_pass ...; error_page 502=@workaround; }<br>
     location @workaround {<br>
         if ($request_method = "POST") { return 500; }<br>
         fastcgi_buffer_size 32k;<br>
         fastcgi_buffers 16 32k;<br>
         fastcgi_busy_buffers_size 64k;<br>
         fastcgi_pass ... ;<br>
     }<br>
}<br>
<br>
вместо того, чтобы вот такой workaround добавлять в каждый server { }<br>
мне проще будет увеличить размеры fastcgi буферов в контексте http { }<br>
<br>
>> или - имеет смысл не искать причину ошибки,<br>
>> а просто увеличить размер буферов и все?<br>
>><br>
> <br>
> увеличение размера буферов --> увеличение расхода памяти. если она есть в<br>
> достатке, почему бы и нет.<br>
<br>
виртуальной памяти - в достатке, ее много, swap раздел на 256<br>
гигабайт внутри каждой виртуальной машины, при этом на диске<br>
такой неиспользуемый swap раздел занимает физически мало места<br>
- всего несколько мегабайт. так и придется сделать, похоже на то.<br>
<br>
то есть, сейчас самый оптимальный алгоритм решения этой проблемы<br>
с 502 ошибками, которые возвращает nginx такой: увеличивать<br>
размеры fastcgi_buffer_size, fastcgi_buffers, fastcgi_busy_buffers_size<br>
до тех пор, пока nginx не прекратит возвращать 502 статусы на овтеты<br>
upstream.<br>
<br>
неудобно в этой ситуации то, что нет возможности как-либо мониторить<br>
сколько свободного места в буфере остается при обработке запросов,<br>
и насколько близко nginx находится к той критической границе,<br>
после которой он начнет сыпать 502 статусами, вместо нормальных ответов.<br>
может быть размеры этих буферов слишком большие или наоборот, слишком<br>
маленькие, и ситуация близкая к критической - это как можно узнать?<br>
<br>
в самом идеальном варианте - лучше было бы чтобы nginx сам мог<br>
бы добавить недостающие ему страницы буферов для обработки запроса,<br>
и мог бы динамически увеличивать размер одного буфера, чтобы нормально<br>
обработать ответ от upstream. например, идеальное решение проблемы:<br>
<br>
сделать переменную fastcgi_max_buffer_size, по умолчанию равную 8<br>
размерам переменной fastcgi_buffer_size, и в той ситуации, когда<br>
размера fastcgi_buffer_size не хватает для обработки какого-то запроса -<br>
динамически, "на лету" увеличивать размер буфера в два раза и продлжать<br>
нормальную обработку запроса, до тех пор, пока не будет превышен размер<br>
лимита fastcgi_max_buffer_size. И только при превышении этого лимита -<br>
возвращать клиенту 502 статус вместо нормально ответа от upstream.<br>
<br>
вопрос к разработчикам: можно ли так сделать? что мешает?<br>
<br>
<br>
> к этому можно подойти творчески.<br>
> fastcgi_buffer_size - это размер одного буфера. в один буфер<br>
> предполагается, что должны поместиться все хедеры.<br>
> а вот их количество увеличивать необязательно, и можно посмотреть в<br>
> сторону  отключения fastcgi_buffering, и тогда<br>
> запрос будет вычитываться постепенно.<br>
<br>
отключить fastcgi_buffering нельзя, тогда такой веб-сервер будет уявзвим<br>
к DDoS-атакам типа Slowloris и тогда будет очень мало смысла в наличии<br>
nginx перед upstream сервером и сайт сможет обработать меньше запросов.<br>
<br>
кстати, вариантов больше чем этих два:<br>
<br>
fastcgi_buffering on;<br>
<br>
fastcgi_buffering off;<br>
<br>
есть еще и промежуточный вариант между ними, когда буферизация<br>
в памяти разрешена, но только буферизация на диске запрещена.<br>
по умолчанию<br></blockquote><div><br></div><div>все верно. и еще есть request buffering ))</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>
fastcgi_max_temp_file_size 1024m;<br>
<br>
но если поставить<br>
<br>
fastcgi_max_temp_file_size 0;<br>
<br>
то в таком случае на диск nginx ничего не будет писать,<br>
но при этом - будет использовать буферизацию только в памяти.<br>
и для большинства вариантов использования nginx - это более<br>
предпочительный вариант чем fastcgi_buffering off;<br>
потому что в режиме<br>
<br>
fastcgi_buffering on;<br>
fastcgi_max_temp_file_size 0;<br>
<br>
производительность веб-сервера будет выше,<br>
и веб-сервер сможет обработать большее количество запросов.<br>
<br>
только в очень небольшом количестве случаев может быть целесообразно<br>
fastcgi_buffering off; - это когда backend написан на Go - но в таком<br>
случае и nginx там не особо нужен вообще, можно напрямую софт на<br>
Go выставить в интернет - в таком случае все накладные расходы<br>
от промежуточного проксирования будут отсутствовать полностью.<br>
<br>
> совершенно необязательно следовать дефолтным значениям.<br>
> по дефолту включена буферизация ответа бекенда. т.е. nginx будет вычитывать<br>
> ответ чтобы максимально<br>
> разгрузить бекенд (пытаясь сохранить сначала в своей памяти, а потом на<br>
> диске). у всех ли стоит задача максимально разгрузить бекенд ?<br>
<br>
<br>
а разве нет?<br></blockquote><div><br></div><div>сильно зависит от бекенда. если бекенд вполне современный и не имеет проблем с c10k, то дополнительная буферизация</div><div>не нужна. мы перед <a href="http://asp.net">asp.net</a> выключали буферизацию. отлично работало. </div><div><br></div><div>какой смысл ? терминация ssl, высокая плотность хостинга на белых адресах, L7 маршрутизация по локейшенам.</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 ставится перед backend? разве не для того,<br>
чтобы максимально разгрузить backend и чтобы веб-сервер смог обработать<br>
наибольшее количество запросов в секунду и выжать максимум из hardware?<br>
<br>
количество worker-процессов php-fpm на backend очень сильно ограничено,<br>
так что чем быстрее они обработают какой-либо запрос - тем будет лучше.<br>
<br>
я такого не видел, чтобы кто-то ставил nginx перед backend не для того,<br>
чтобы максимально разгрузить backend, а с прямо противоположной целью.<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>