On 17.08.2015 23:10, Maxim Dounin wrote:

>>> Наиболее неприятный из известных мне нюансов состоит в том, что
>>> неразблокированные элементы кеша остаются, если какому-либо из
>>> рабочих процессов сказать TERM. Например, такое иногда практикуют
>>> для принудительного завершения старых рабочих процессов, плавное
>>> завершение которых занимает слишком много времени.
>>
>> Эту проблему можно решить, если элементы кеша блокировать не навсегда,
>> а на какое-то определенное количество времени, и по прошествии этого
>> времени - считать существующую блокировку элемента недействительной.
>
> Чтобы блокировать "не навсегда", умеющий это обрабатывать код
> должен быть в том числе со стороны запроса, которому данная
> блокировка нужна. Чтобы периодически блокировку обновлял, и был
> готов к тому, что её уберут, и всё это - со всеми прилагающимися
> дополнительными затратами ресурсов. В противном случае - будут
> segfault'ы, если таки выкинут нужную блокировку.

Хорошо, тогда другое предложение:

В функции ngx_shmtx_lock блокировка делается через
ngx_atomic_cmp_set, при этом, вместо 0 записывается
ngx_pid, следовательно, если блокировка стоит -
всегда можно узнать, какой именно процесс
эту блокировку поставил.

И, вместе с тем, когда дочерний процесс завершается,
- мастер-процесс nginx получает сигнал SIGCHLD,
и может узнать ngx_pid завершившегося дочернего
процесса.

В результате: мастер-процесс может самостоятельно
снять все "зависшие" блокировки на shared memory.
Дополнительные затраты ресурсов сервера при этом
практически равны 0.

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

Если удалять заблокированные элементы - разве не будут segfault'ы?

--
Best regards,
Gena

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