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
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Ответить