Да, спасибо.
До переименования зоны я уже догадался.
Но не сразу заметил. Экспериментировал с довольно сложным 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


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