Opened 7 years ago
Last modified 7 years ago
#1472 accepted enhancement
Downloads stop after 1GB depending of network
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | nginx-module | Version: | |
Keywords: | proxy | Cc: | |
uname -a: | Linux NAME 4.9.0-0.bpo.5-amd64 #1 SMP Debian 4.9.65-3+deb9u2~bpo8+1 (2017-01-05) x86_64 GNU/Linux | ||
nginx -V: |
nginx version: nginx/1.12.2
built by gcc 4.9.2 (Debian 4.9.2-10) built with OpenSSL 1.0.1t 3 May 2016 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' |
Description
Hi,
we tried nginx version 1.6.2 till version 1.12.2 and have a problem when used as proxy before artifactory. Downloads get interrupted at 1GB.
This behavior depends on the internal VLAN. On one VLAN this always happens. On an other VLAN it never happens. This is size limited, not time limited. From some network it stops after 30 seconds and from one other slow network it stops after 13 minutes.
We made a minimal proxy setup with apache and this works with all VLANs. This is why we expect it has something to do with nginx or the combination of nginx and TCP/IP stack of linux.
In wireshark we see "TCP Dup ACK" on the client side sent to the nginx server.
Wget fails with connection closed at byte 1083793011 but continues download with partial content. docker can't handle this and our customers can't download docker images with layers greater 1 GB.
The following text shows two anonymized minimal configs. The nginx config that is problematic and the apache config that works:
NGINX config: server { listen *:80; server_name NAME; client_max_body_size 3G; access_log /var/log/nginx/NAME.access.log; error_log /var/log/nginx/NAME.error.log; if ($request_uri !~ /artifactory/) { rewrite ^ $scheme://NAME/artifactory/ permanent; } location /artifactory { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_pass http://ARTIFACTORY:PORT; proxy_pass_header Server; proxy_read_timeout 90s; } } APACHE config: <VirtualHost *:80> ServerName NAME ServerAdmin NAME ErrorLog ${APACHE_LOG_DIR}/error.log LogLevel warn ProxyRequests Off <Proxy *> Order allow,deny Allow from All </Proxy> ProxyPass / http://ARTIFACTORY:PORT/ ProxyPassReverse / http://ARTIFACTORY:PORT/ </VirtualHost>
Change History (3)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
This was it! Thank you very much for your answer!
We used the first solution and raised the limit.
We were so confused because the circumstances with the different networks. We already tried throttleing and stuff to reproduce it.
comment:3 by , 7 years ago
Status: | new → accepted |
---|---|
Type: | defect → enhancement |
Version: | 1.12.x |
Ok, thanks for the confirmation.
For the record, this seems to be more or less typical problem, reported from time to time (see here for an example). While this behaviour is not a bug, we might consider doing some improvements to make such timeouts less likely to happen. In particular, reviving and improving the p->cyclic_temp_file feature (currently disabled in all modules) might be the way to go.
The 1GB limit suggests that the problem is due to proxy_max_temp_file_size. It is one gigabyte by default, and if the limit is reached, nginx will stop reading from the backend till all disk-buffered data are sent to the client. This in turn can result in a send timeout on the backend side.
Please check nginx and your backend logs to see what happens here. Likely there are something like "upstream prematurely closed connection" in nginx error log, and send timeouts in your backend logs. Alternatively, just check if
proxy_max_temp_file_size 0;
helps (this will disable disk buffering completely).If the above suggestion is true, the two possible solutions are:
proxy_max_temp_file_size
. Consider either configuring the limit above the size of all expected responses, or small enough for your backend to don't time out. In particular,proxy_max_temp_file_size 0;
might be a good choice when proxying large files.