Re: nginx отъедает все процессорное время

Maxim Dounin mdounin на mdounin.ru
Вт Мар 1 17:48:50 UTC 2016


Hello!

On Tue, Mar 01, 2016 at 11:25:17AM -0500, mikhal123 wrote:

> Валентин Бартенев Wrote:
> -------------------------------------------------------
> > On Tuesday 01 March 2016 10:52:08 mikhal123 wrote:
> > > Валентин Бартенев Wrote:
> > > 
> > Это всё и объясняет.  Нельзя изменять файлы, которые раздаются. Клиент
> получит мусор, а вы получите странную ошибку или такое вот зацикливание.
> > 
> > Если вы хотите переписать файл, то делать это нужно атомарно, иначе
> представления nginx об отдаваемом файле и его размере разойдутся с
> фактическим на файловой системе.  У вас вероятность этого события была
> увеличена ещё в несколько раз включенным "open_file_cache".
> 
> Хм, что-то я не совсем понимаю ...
> 
> Вы утверждаете, что вот такие вот графики
> http://i023.radikal.ru/1602/db/01658625aa1f.png для nginx являются нормой?
> Что если представления nginx об отдаваемом файле и его размере по каким-то
> причинам разойдутся с фактическим на файловой системе, то он считает себя
> вправе войти в бесконечный цикл с пребыванием по большей части в контексте
> system?

Это, безусловно, ошибка - должна быть ругань в логе, а не цикл.
E.g, при выключенном sendfile'е - будет что-то вроде:

[alert] ... read() read only ... of ... from "..."

А на FreeBSD и при использовании sendfile() в таком случае будет:

[alert] ... sendfile() reported that "..." was truncated at ...

На Linux'е интерфейс sendfile() несколько другой, и явного 
детектирования таких ошибок сейчас nginx делать не умеет.  
Когда-нибудь обязательно научим, тем более, что при использовании 
thread'ов это стало нехорошо проявляться.

Следует, однако, понимать, что в случае неатомарного обновления 
файлов клиент имеет все шансы получить произвольную смесь из 
старого и нового файлов (не говоря уже о новом содержимом, 
обрезанном по старому размеру), и делать так - не надо.  А если вы 
так делаете - то надо быть готовым как минимум к мусору в ответах, 
а как максимум - и к более другим проблемам.

[...]

> и просто ради понимания - почему же все это началось только после перехода с
> Debian 8?
> до этого в точной такой же конфигурации nginx и при перезаписывании файла
> все отлично работало (без мусора в ответах, безконечных циклов и т.д) как
> минимум два года

"В точно такой же конфигурации" - это вряд ли.  Два года назад в 
nginx'е не было поддержи "aio threads", а на цикл вы наступили 
именно из-за неё - в обычной ситуации на Linux'е соединение просто 
повиснет до таймаута.

Что до мусора, то тут всё зависит от везения и конкретного формата 
данных.  Если специально не пытаться ловить повреждения данных - 
можно долго ничего не замечать, списывая проблемы на подземный 
стук.

-- 
Maxim Dounin
http://nginx.org/



Подробная информация о списке рассылки nginx-ru