Re[2]: Странная ситуация с levels

[CoDDoC]

Да, спасибо.
До переименования зоны я уже догадался.
Но не сразу заметил. Экспериментировал с довольно сложным SSI, пришлось часто заглядывать в кэш, многоуровневый оказался неудобен, переключил в один уровень, вот только тогда. Потом уже полез в дебаг.

Себе в шпаргалку на заметку. Но все-таки, неплохо было бы сказать в доке о рестарте (ИМХО).


>Пятница,  9 ноября 2018, 16:34 +03:00 от Maxim Dounin <mdounin на mdounin.ru>:
>
>Hello!
>
>On Fri, Nov 09, 2018 at 10:18:30AM +0300, CoDDoC wrote:
>
>> nginx-debug -v
>> nginx version: nginx/1.15.6
>> 
>> Специально обновился, до этого была версия 1.13.12, там то же самое.
>> Изменение levels в proxy_cache_path применяется только после полного рестарта (service nginx-debug restart)
>> nginx-debug -s reload ожидаемого результата не дает
>> 
>> Как воспроизвести:
>> 1. В контексте http:
>> proxy_cache_path /var/www/html/cache levels=1:2:1 use_temp_path=off keys_zone=testcache:5m inactive=10m max_size=50m;
>> 2. service nginx-debug restart
>> 3. В error.log:
>> cache manager process <PID> exited with code 0
>> start cache manager process <PID>
>> start cache loader process <PID>
>> 4. Делаю запрос в локейшен, для которого активирована зона testcache
>> 5. Получаю ожидаемое:
>> /var/www/html/cache/3/05/8/e62d74fdc44e220f0225168323c28053
>> 6. Удаляю ветку '3/05/8/e62d74fdc44e220f0225168323c28053'
>> 
>> 7. Меняю levels 1:2:1 -> levels 1
>> 8. nginx-debug -s reload
>> 9. В error.log:
>> cache "testcache" had previously different levels
>> 10. Запрос в тот же локейшен дает тот же результат:
>> /var/www/html/cache/3/05/8/e62d74fdc44e220f0225168323c28053
>> 11. Опять удаляю '3/05/8/e62d74fdc44e220f0225168323c28053'
>> 12. service nginx-debug restart
>> 13. В error.log:
>> cache manager process <PID> exited with code 0
>> start cache manager process <PID>
>> start cache loader process <PID>
>> 14. Запрос в тот же локейшен опять дает ожидаемое:
>> /var/www/html/cache/3/e62d74fdc44e220f0225168323c28053
>> 
>> Если это нормальное поведение, может, имеет смысл как-то отметить в документации необходимость рестарта?
>
>Это нормальное поведение.
>
>Многие вещи, работа с которыми происходит через зоны разделяемой 
>памяти из всех процессов, поменять без пересоздания зоны 
>разделяемой памяти - нельзя.  Наиболее банальный пример - нельзя 
>поменять собственно размер зоны разделяемой памяти.
>
>В чуть более сложных случаях - нельзя менять параметры, которые 
>меняют поведение рабочих процессов на несовместимое с другими 
>рабочими процессами или с уже имеющейся в разделяемой памяти 
>информацией.  В частности, levels в кэше - определяют, в каком 
>именно виде лежат данные на диске, и каким именно файлам на диске 
>соответствуют элементы в разделяемой памяти.  То есть поменять 
>levels просто так нельзя - фактически, надо выкинуть из памяти всю 
>информацию, которая становится негодной, и презагрузить содержимое 
>кэша заново.  Кроме того, всё ещё осложняется тем, что у нас есть 
>старые рабочи процессы, которые могут работать неопределённо 
>долго, и эти рабочие процессы предполагают старое значение levels, то 
>есть если мы таки выкинем и перезагрузим содержимое разделяемой 
>памяти - начнут вести себя некорретно они.
>
>Чтобы подобных проблем не возникало - при применении новой 
>конфигурации nginx проверяет, что конфигурация совместима с тем, 
>как использовались зоны разделяемой памяти ранее.  И если 
>обнаруживает, что попытались поменять что-то, что менять нельзя - 
>логгирует соответствующую ошибку в error log, и откатывается к 
>старой конфигурации.
>
>Если тем не менее хочется соответствующие параметры поменять, то 
>это можно сделать одним из следующих способов:
>
>- Переименовать зону разделяемой памяти (в случае кэша - лучше 
>  при этом заодно задать новый путь), и использовать её в 
>  конфигурации с новыми параметрами.  При таком изменении 
>  конфликтов между старой и новой конфигурацией не будет, можно 
>  будет сделать reload.  И при этом сохранится содержимое 
>  остальных зон разделяемой памяти, конфигурацию которых не меняли.
>
>- Сделать binary upgrade.  При этом все зоны разделяемой памяти будут 
>  созданы заново, однако потерь запросов не будет.
>
>- Ну и собственно сделать restart.  Всё тоже заработает с новой 
>  конфигурацией, но смысла в этом приблизительно никакого - binary 
>  upgrade даст тот же результат, но без потери запросов.
>
>-- 
>Maxim Dounin
>http://mdounin.ru/
>_______________________________________________
>nginx-ru mailing list
>nginx-ru на nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


--
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20181110/f56b4be5/attachment.html>