Похожая ситуация, только у меня скрипт картинки ресайзит. Если не менять логику приложения и не писать очереди, то кроме как ограничить количество сессий на бекэнд ничего умнее не придумал. Тогда клиент просто ждет, когда ему отдадут картинку, но надо таймауты поднять, чтобы кеш разгонять получалось.
7 июня 2017 г., 22:37 пользователь Maxim Dounin <[email protected]> написал: > Hello! > > On Tue, Jun 06, 2017 at 03:42:27PM +0200, Yury Lyakh wrote: > > > День добрый, может кто сталкивался с проблемой закачки файлов с бэкенда > параллельно в несколько потоков. > > > > Есть мелкий конфиг ниже. > > Клиенты приходят с запросами ренжовыми и обычными, если файл отсутствует > в кеше он начинает качаться с бэкенда, но качается во столько нитей сколько > клиентов запросило файл. В итоге трафик на бэкенде растет в прогрессии и > все закономерно встает через пару минут. > > > > применили: > > proxy_cache_lock on; > > и > > proxy_cache_use_stale updating; > > но ситуация не изменилась, все равно качается в множество нитей > > > > Почистили полностью машину от временных файлов (temp файлы закачки > находятся в кеше use_temp_path=off). > > Запустили трафик, буквально через 10 секунд прошелся по кешу в поиске > временных файлов, чтобы посмотреть их KEY в заголовке, видим что > одновременно создались и качаются 177 временных файлов для одного по сути > файла: > > > > [root@upload-3 cache]# find -L ./ -type f -iname '*\.[0-9]*' | xargs > head -n2 | grep -a ^KEY | sort | uniq -c > > 177 KEY: /ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg. > 001 > > > > самы файлы выглядят как: > > ... > > -rw------- 1 nginx nginx 205168640 Jun 6 13:15 ./wop/1f/51/ > 006afe023b4083e96128680af13b511f.0000000253 > > -rw------- 1 nginx nginx 209281024 Jun 6 13:15 ./wop/1f/51/ > 006afe023b4083e96128680af13b511f.0000000254 > > -rw------- 1 nginx nginx 286048256 Jun 6 13:15 ./wop/1f/51/ > 006afe023b4083e96128680af13b511f.0000000255 > > -rw------- 1 nginx nginx 671723520 Jun 6 13:15 ./wop/1f/51/ > 006afe023b4083e96128680af13b511f.0000000257 > > -rw------- 1 nginx nginx 217743360 Jun 6 13:15 ./wop/1f/51/ > 006afe023b4083e96128680af13b511f.0000000258 > > -rw------- 1 nginx nginx 239915008 Jun 6 13:15 ./wop/1f/51/ > 006afe023b4083e96128680af13b511f.0000000259 > > -rw------- 1 nginx nginx 635768832 Jun 6 13:15 ./wop/1f/51/ > 006afe023b4083e96128680af13b511f.0000000261 > > .... > > > > > > версия nginx-1.13.1 > > > > конфиг: > > proxy_cache_path /var/lib/nginx/cache/wop levels=2:2 keys_zone=wop:20m > inactive=2d use_temp_path=off; > > > > server { > > listen 80; > > listen [::]:80; > > server_name dl-share.wop.net <http://dl-share.wop.net/>; > > > > proxy_cache wop; > > proxy_ignore_client_abort on; > > > > location / { > > proxy_pass http://dl.wop.net <http://dl.wop.net/>; > > proxy_set_header Host $proxy_host; > > proxy_cache_lock on; > > proxy_cache_lock_age 1d; > > proxy_cache_lock_timeout 1d; > > proxy_cache_use_stale error updating; > > proxy_cache_key "$uri"; > > proxy_cache_revalidate on; > > proxy_cache_valid 404 10s; > > proxy_cache_valid 200 1h; > > } > > } > > > > запросы с которыми идут пользователи: > > > > "195.242.151.17" "-" "-" "[06/Jun/2017:13:03:28 +0000]" "GET > /ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001 HTTP/1.1" > "206" "0" "-" "wdsa::Torrents/1.1 libtorrent/1.1.3.0" "0" "-" "http" " > dl-share.wop.net <http://dl-share.wop.net/>" "81.114" "81.114" "235" > "bytes=1744977920-1745043455" "[gn]" "MISS" "42008576" "91.213.124.60:80" > "0" "0" "-" "-" > > "195.242.151.17" "-" "-" "[06/Jun/2017:13:03:26 +0000]" "GET > /ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001 HTTP/1.1" > "206" "0" "-" "wdsa::Torrents/1.1 libtorrent/1.1.3.0" "0" "-" "http" " > dl-share.wop.net <http://dl-share.wop.net/>" "121.167" "121.167" "235" > "bytes=2059403264-2059468799" "[gn]" "MISS" "42008576" "91.213.124.60:80" > "0" "0" "-" "-" > > > > Ткните пожалуйста в документацию где я не дочитал, что вообще > происходит?.. > > Такая картина - множество запросов к одному и тому же ресурсу на > бекенде, не смотря на включённый proxy_cache_lock - может > наблюдаться, если в кеше лежит повреждённый кеш-файл и/или > кеш-файл со старым форматом заголовка. > > В этом случае nginx обнаруживает проблему позже, чем возможно > использование proxy_cache_lock. Однако и вернуть клиенту > существующий в кеше ответ в соответствии с "proxy_cache_use_stale > updating" тоже нельзя, так как кеш-файл невозможно использовать. В > результате все запросы просто проксируются на бекенд, как если бы > proxy_cache_lock не использовался. > > В логе ошибок при этом будут сообщения про "cache file ..." на > уровне crit в случае повреждённых кеш-файлов, и на уровне info в > случае файлов устаревшего формата. > > Если дело в этом, то очистка кеша от старых / повреждённых файлов > должна помочь. Рано или поздно это произойдёт само - если, > конечно, что-то не портит файлы. > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx-ru mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
