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