ср, 5 мар. 2025 г. в 19:10, Hennadii Makhomed <g...@csdoc.com>:
> Здравствуйте, All! > > В error.log встречается время от времени 502 статус и такая запись: > > upstream sent too big header while reading response header from upstream > > но какой именно заголовок в ответе от backend большого размера > и какое его очень большое содержимое не указывается в error.log, > - что значительно затрудняет поиск причины ошибки и ее устранение. > в данном случае имеется в виду весь header, не какой-то конкретный заголовок (соглашусь, текст ошибки сбивает с толку) > > можно ли сделать так, чтобы в случае возникновения такой 502 ошибки > чтобы имя этого очень большого заголовка ответа и его содержимое > писалось в error.log файл? или вообще все заголовки запроса > и все заголовки ответа пис ались в лог, в случае, если возникает > такая вот неожидання 502 ошибка по причине, что там too big header? > ошибки такие возникают не так часто и поймать их очень трудно. > приходится включать > > error_log /var/log/nginx/error.log debug; > > и переключаться на nginx-debug, что приводит > к очень быстрому росту лог-файла на диске. > > ведь никаких других способов кроме использования tcpdump > и использования error_log /var/log/nginx/error.log debug; > как я понимаю для поиска причины этой ошибки не существует? > я не пробовал, но приходит в голову вариант с "error_page 502=@some_location" и внутри some_location задать error_log возможно, что не сработает > > на backend - не хотят или не умеют найти причину этой ошибки. > > или - имеет смысл не искать причину ошибки, > а просто увеличить размер буферов и все? > увеличение размера буферов --> увеличение расхода памяти. если она есть в достатке, почему бы и нет. > > chat.deepseek.com рекомендует поставить > > fastcgi_buffer_size 32k; # Было 4k/8k → увеличиваем до 32k > fastcgi_buffers 16 32k; # Было 8 4k/8k → 16 буферов по 32k > fastcgi_busy_buffers_size 64k; # Было 8k/16k → увеличиваем до 64k > к этому можно подойти творчески. fastcgi_buffer_size - это размер одного буфера. в один буфер предполагается, что должны поместиться все хедеры. а вот их количество увеличивать необязательно, и можно посмотреть в сторону отключения fastcgi_buffering, и тогда запрос будет вычитываться постепенно. зависит от объема доступной памяти > > если это не поможет - то выставлять тогда > > fastcgi_buffer_size 64k; > fastcgi_buffers 32 64k; > fastcgi_busy_buffers_size 128k; > > и если ошибка сохраняется - то увеличивать и дальше, 32k → 64k → 128k > > наверное вот эти значения: > > fastcgi_buffer_size 32k; # Было 4k/8k → увеличиваем до 32k > fastcgi_buffers 16 32k; # Было 8 4k/8k → 16 буферов по 32k > fastcgi_busy_buffers_size 64k; # Было 8k/16k → увеличиваем до 64k > > - это будет нормально, а чтобы не падал с out of memory, просто > дам каждой виртуальной машине 256 гигабайт swap на диске, да и все. > > дефолтовые значения для директив fastcgi_buffer_size, fastcgi_buffers > и fastcgi_busy_buffers_size - такого небольшого размера - это самый > оптимальный вариант, их точно не надо сейчас сделать больше, > хотя бы в два раза больше, для современных сайтов? > совершенно необязательно следовать дефолтным значениям. по дефолту включена буферизация ответа бекенда. т.е. nginx будет вычитывать ответ чтобы максимально разгрузить бекенд (пытаясь сохранить сначала в своей памяти, а потом на диске). у всех ли стоит задача максимально разгрузить бекенд ? > > насколько я понимаю, никак нельзя исправить эту ситуацию, что nginx > аварийно завершает обработку запроса и возвращает 502 статус, если > ему размер header не понравился, отправленный ему со стороны upstream? > > если он считает размеры буферов не оптимальными - можно было бы написать > warning в error.log, но зачем же возвращать 502 стратус вместо ответа? > такова механика работы - чтобы как-то работать с ответом, надо сначала вычитать полностью хедеры, предполагая, что они поместились в один буфер. и далее стримится тело ответа. если хедеры не влезли в один буфер, каких-то вариантов обработать запрос нет. > > большой размер заголовков, например, до 32KiB или 64KiB - это же > не является нарушением HTTP стандарта? Зачем же тогда 502 статус? > > и как их правильно тюнить, эти размеры буферов fastcgi_buffer_size, > fastcgi_buffers и fastcgi_busy_buffers_size ? увеливать до тех пор, > пока nginx не прекратит возвращать 502 ошибки на запросы клиентов? > > P.S. > > — В 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
