Да, спасибо. До переименования зоны я уже догадался. Но не сразу заметил. Экспериментировал с довольно сложным SSI, пришлось часто заглядывать в кэш, многоуровневый оказался неудобен, переключил в один уровень, вот только тогда. Потом уже полез в дебаг.
Себе в шпаргалку на заметку. Но все-таки, неплохо было бы сказать в доке о рестарте (ИМХО). >Пятница, 9 ноября 2018, 16:34 +03:00 от Maxim Dounin <mdou...@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