Re: nginx качает один и тот же файл в несколько коннектов с бэкенда

Vasiliy P. Melnik basil на vpm.net.ua
Ср Июн 7 19:47:41 UTC 2017


Похожая ситуация, только у меня скрипт картинки ресайзит. Если не менять
логику приложения и не писать очереди, то кроме как ограничить количество
сессий на бекэнд ничего умнее не придумал. Тогда клиент просто ждет, когда
ему отдадут картинку, но надо таймауты поднять, чтобы кеш разгонять
получалось.

7 июня 2017 г., 22:37 пользователь Maxim Dounin <mdounin на mdounin.ru>
написал:

> 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
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170607/8abce521/attachment-0001.html>


Подробная информация о списке рассылки nginx-ru