Re[2]: Странная ситуация с levels
Да, спасибо. До переименования зоны я уже догадался. Но не сразу заметил. Экспериментировал с довольно сложным SSI, пришлось часто заглядывать в кэш, многоуровневый оказался неудобен, переключил в один уровень, вот только тогда. Потом уже полез в дебаг. Себе в шпаргалку на заметку. Но все-таки, неплохо было бы сказать в доке о рестарте (ИМХО). >Пятница, 9 ноября 2018, 16:34 +03:00 от Maxim Dounin : > >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 exited with code 0 >> start cache manager process >> start cache loader process >> 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 exited with code 0 >> start cache manager process >> start cache loader process >> 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
Re: Странная ситуация с levels
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 exited with code 0 > start cache manager process > start cache loader process > 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 exited with code 0 > start cache manager process > start cache loader process > 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
Странная ситуация с levels
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 exited with code 0 start cache manager process start cache loader process 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 exited with code 0 start cache manager process start cache loader process 14. Запрос в тот же локейшен опять дает ожидаемое: /var/www/html/cache/3/e62d74fdc44e220f0225168323c28053 Если это нормальное поведение, может, имеет смысл как-то отметить в документации необходимость рестарта? Спасибо. --___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
