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