Hello!

On Tue, Aug 18, 2015 at 09:40:15AM +0300, Gena Makhomed wrote:

> On 17.08.2015 23:10, Maxim Dounin wrote:
>
> >>>Наиболее неприятный из известных мне нюансов состоит в том, что
> >>>неразблокированные элементы кеша остаются, если какому-либо из
> >>>рабочих процессов сказать TERM. Например, такое иногда практикуют
> >>>для принудительного завершения старых рабочих процессов, плавное
> >>>завершение которых занимает слишком много времени.
> >>
> >>Эту проблему можно решить, если элементы кеша блокировать не навсегда,
> >>а на какое-то определенное количество времени, и по прошествии этого
> >>времени - считать существующую блокировку элемента недействительной.
> >
> >Чтобы блокировать "не навсегда", умеющий это обрабатывать код
> >должен быть в том числе со стороны запроса, которому данная
> >блокировка нужна. Чтобы периодически блокировку обновлял, и был
> >готов к тому, что её уберут, и всё это - со всеми прилагающимися
> >дополнительными затратами ресурсов. В противном случае - будут
> >segfault'ы, если таки выкинут нужную блокировку.
>
> Хорошо, тогда другое предложение:
>
> В функции ngx_shmtx_lock блокировка делается через
> ngx_atomic_cmp_set, при этом, вместо 0 записывается
> ngx_pid, следовательно, если блокировка стоит -
> всегда можно узнать, какой именно процесс
> эту блокировку поставил.

Речь про блокировки отдельных элементов кеша, а не всей зоны
разделяемой памяти. С зоны разделяемой памяти блокировку после
падения процессов мы снимать умеем, см. ngx_shmtx_force_unlock().

[...]

> >На практике вполне неплохо работает вывод сообщений в логи и
> >перемещение заблокированных элементов в начало очереди,
> >реализованное для обработки удаления старых элементов по inactive.
> >Проблемы, судя по рассылке, наблюдаются у тех, кто очистку по
> >inactive фактически выключил - и, видимо, в сочетании с какой-то
> >ещё проблемой, какой - пока непонятно.
>
> Если удалять заблокированные элементы - разве не будут segfault'ы?

Их никто не удаляет, их перемещают и ругаются в лог. См.
ngx_http_file_cache_expire().

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

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru