ignore long locked inactive cache entry

[Gena Makhomed]

On 08.05.2021 0:36, Maxim Dounin wrote:

>>> Скорее всего в данном случае дело в aio_write, см.
>>> https://trac.nginx.org/nginx/ticket/2162.

>> Максим, Вы говорите в комментариях к этому тикету:
>>
>>   > It is not expected to affect real-world use cases,
>>   > though probably worth fixing anyway.
>>
>> У меня этот bug проявился именно что в real-world use case.
> 
> Ну видимо сильно зависит от use case'а. Такое может быть, когда кроме
> aio-записи в кэш ничего больше в рабочем процессе не остаётся,
> тогда shutdown может случиться раньше, чем надо. В норме такого
> не бывает, т.к. shutdown задерживают медленные клиенты.

У меня перед nginx-backend стоит nginx-frontend,
так что все медленные клиенты подключаются к nginx-frontend,
а nginx-backend только очень быстро обрабатывает запросы
и очень быстро отдает их на сторону nginx-frontend,
медленных клиентов nginx-backend никогда не увидит.

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

В документации эти моменты не описаны вообще,
откуда же обычный пользователь nginx, вроде меня,
может узнать какие опции можно безопасно включать,
а какие следует включать с большой осторожностью?

Насколько я знаю, в интернете нет в электронном виде книги/сайта
где были бы описаны в доступном виде все такие нюансы настроек.

Использовать конфиг-по-умолчанию - это тоже не вариант, потому что
там по-умолчанию отключено практически все, что только можно отключить.

> Патчи, что называется, welcome.  Тем более, что основной вопрос
> там - как это красиво исправить, по возможности вписав
> в существующую инфраструктуру, не изобретая новых механизмов
> для задержки shutdown'а.

Если для всех thread_pool`ов сделать корректное закрытие перед
shutdown`ом worker-процесса nginx, тогда и проблемы тогда не будет.

Ведь aio-запись происходит в отдельных thread`ах, и проблема в том,
что в момент shutdown`а worker-процесса nginx эти thread`ы еще активны.

В файле ngx_thread_pool.c есть функция ngx_thread_pool_exit_worker,
но она нигде в коде не используется, в частности, не используется
в функции ngx_worker_process_exit из файла ngx_process_cycle.c

Было бы логично сначала закрыть все thread_pool`ы,
перед тем, как делать проверку на утечку сокетов.

-- 
Best regards,
  Gena