nginx menutup koneksi pada beberapa gambar

8

Ada masalah dengan nginx. Itu menutup koneksi sebelum klien selesai mengunduh. Sepertinya:

 $ wget -O /dev/null http://www.site.com/images/theme/front/clean.jpg
--2012-07-11 21:37:03--  http://www.site.com/images/theme/front/clean.jpg
Resolving www.site.com (www.site.com)... 123.234.123.234
Connecting to www.site.com (www.site.com)|123.234.123.234|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 90707 (89K) [image/jpeg]
Saving to: `/dev/null'

26% [===============>                    ] 24,291      --.-K/s   in 8.7s    

2012-07-11 21:37:12 (2.74 KB/s) - Connection closed at byte 24291. Retrying.

--2012-07-11 21:37:13--  (try: 2)  http://www.site.com/images/theme/front/clean.jpg
Connecting to www.site.com (www.site.com)|123.234.123.234|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 90707 (89K), 66416 (65K) remaining [image/jpeg]
Saving to: `/dev/null'

53% [+++++++++++++++============>        ] 48,555      --.-K/s   in 8.7s    

2012-07-11 21:37:23 (2.74 KB/s) - Connection closed at byte 48555. Retrying.

--2012-07-11 21:37:25--  (try: 3)  http://www.site.com/images/theme/front/clean.jpg
Connecting to www.site.com (www.site.com)|123.234.123.234|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 90707 (89K), 42152 (41K) remaining [image/jpeg]
Saving to: `/dev/null'

100%[+++++++++++++++++++++++++++========>] 90,707      --.-K/s   in 0.1s    

2012-07-11 21:37:25 (311 KB/s) - `/dev/null' saved [90707/90707]

pada saat yang sama dengan gambar yang lebih kecil semua baik-baik saja: 

 $ wget -O /dev/null http://www.site.com/images/theme/front/grease.jpg
--2012-07-11 21:41:28--  http://www.site.com/images/theme/front/grease.jpg
Resolving www.site.com (www.site.com)... 123.234.123.234
Connecting to www.site.com (www.site.com)|123.234.123.234|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 21404 (21K) [image/jpeg]
Saving to: `/dev/null'

100%[====================================>] 21,404      --.-K/s   in 0.07s   

2012-07-11 21:41:29 (316 KB/s) - `/dev/null' saved [21404/21404]

Ini adalah alasan mengapa gambar ini tidak dapat ditarik sepenuhnya di browser. Saya hanya bisa melihat kepala itu.

Nginx dikonfigurasi sebagai front-end dan apache sebagai back-end. Tautan langsung ke apache berfungsi dengan baik, sehingga ada masalah di nginx. Apakah saya benar?

konfigurasi nginx:

user satellite;
worker_processes  1;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
    multi_accept on;
}

http {
    include       /etc/nginx/mime.types;
    access_log  /var/log/nginx/access.log;

    sendfile        on;
    keepalive_timeout  0;
    tcp_nodelay        on;

    gzip  on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";
    client_max_body_size 100m;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
    server {
            listen 123.234.123.234:80;
            server_name site.com www.site.com;
            location ~* ^/(admin/|dump/|webmail/|myadmin/|webim/) {
                    proxy_pass http://123.234.123.234:8080;
                    proxy_redirect http://site.com:8080/ /;
                    proxy_set_header Host $host;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                    proxy_set_header X-Real-IP $remote_addr;
            }
            location / {
                    proxy_pass http://123.234.123.234:8080;
                    proxy_redirect http://site.com:8080/ /;
                    proxy_set_header Host $host;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                    proxy_set_header X-Real-IP $remote_addr;
                    proxy_cache ino;
                    proxy_cache_valid 12h;
                    proxy_hide_header "Set-Cookie";
                    proxy_ignore_headers "Cache-Control" "Expires";
            }
            location ~* ^.+\.(jpg|swf|flv|ico|txt|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ {
                    access_log /home/satellite/logs/site.com.nginx.access.log;
                    error_page 404 = @fallback;
                    if ( $host ~* ^((.*).site.com)$ ) {
                            set $proot /home/satellite/www/$1;
                            break;
                    }
                    if ( $host = "www.site.com" ) {
                            break;
                    }
                    if ( $host = "site.com" ) {
                            break;
                    }

                    root /home/satellite/www/site.com;
            }
            location @fallback {
                    proxy_pass http://123.234.123.234:8080;
                    proxy_set_header Host $host;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                    proxy_set_header X-Real-IP $remote_addr;
            }
    }

di mana saya harus menggali untuk memperbaiki masalah ini?

nginx  web-server 
— buru-buru
sumber
1
Apakah Anda mencoba mematikan sendfile?
— VBart
Ya, tidak ada yang berubah.
— buru

Jawaban:

9

Hal utama yang saya lupa adalah memeriksa /var/log/nginx/error.log.

2012/07/12 08:46:44 [crit] 24074#0: *3 open() 
"/var/lib/nginx/proxy/1/00/0000000001" failed (13: Permission denied) 
while reading upstream, client: 109.173.96.30, server: site.com, request: 
"GET /images/theme/front/clean.jpg HTTP/1.1", upstream: 
"http://123.234.123.234:8080/images/theme/front/clean.jpg", 
host: "www.site.com", referrer: "http://www.google.com"

Jadi saya memperbaiki /var/lib/nginx/proxy/*izin direktori ( sudo chown -R www-data:www-data /var/lib/nginx/proxy/*) dan sekarang semuanya berfungsi dengan baik. Terima kasih semuanya atas bantuannya.

— buru-buru
sumber
Terima kasih untuk ini. Sepertinya saran yang jelas tapi saya belum memeriksanya. Dalam kasus saya penyebabnya adalah ini: [crit] 6 # 6: * 2577 mkdir () "/ var / cache / nginx / proxy_temp / 8" gagal (28: Tidak ada ruang tersisa di perangkat) saat membaca upstream
— Damian Moore
1

Alasan yang mungkin untuk penutupan koneksi adalah koneksi yang lambat dan pendek keepalive_timeout. Nilai default untuk keepalive_timeoutadalah 75-an. Jika terlalu pendek dan koneksinya lambat, maka bisa ditutup terlalu dini.

http {
    ..
    keepalive_timeout 75;
}

Salah satu alasan mengapa unduhan gambar Anda bisa lambat adalah aplikasi Anda. Jika Anda menggunakan aplikasi Ruby-on-Rails dengan Asset Pipeline dalam kombinasi dengan Nginx, maka unduhan gambar bisa lambat karena Anda menggunakan url gambar yang salah (tanpa sidik jari yang dihasilkan oleh pipa aset). The Rails helps asset_path dan image_tag menghasilkan file form url yang tepat dengan sidik jari yang dapat diunduh dengan cepat.

— 0x4a6f4672
sumber
1

Hal lain yang sangat penting untuk diperiksa adalah: Pastikan Anda memiliki ruang disk yang tersisa!

Bagi saya itu seperti berikut:

[user@server]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        30G   29G     0 100% /

Bagi saya, nginx tidak dapat menulis ke disk yang pada akhirnya menyebabkan masalah yang sama! Semoga ini bisa membantu seseorang!

— Raptor
sumber
Tolong jelaskan mengapa Anda berpikir kekurangan ruang disk dapat menyebabkan koneksi TCP menutup secara tak terduga. Dan bagaimana membuka koneksi TCP baru sementara akan menyelesaikan masalah itu.
— kasperd
1
Ya tentu! Berikut ini sebuah skenario: - Nginx berfungsi sebagai server Proxy - Ini menerima file dari apache - Nginx menerima potongan pertama file (kode respons 206) - Ia menulis potongan ke hard drive dan mengirimkan permintaan untuk potongan berikutnya - Ia menerima potongan berikutnya dan gagal menulis ke hard drive karena tidak ada ruang yang tersisa! - Nginx menutup koneksi dengan kode respons 206. Konten lengkap tidak disajikan kepada klien! Semoga itu menjelaskan!
— Raptor
1
Dalam kasus Rush, potongan gambar pertama berukuran 24.291 berhasil diterima. Yang berarti hingga ~ 24.291 dapat dilayani oleh nginx langsung dari memori. Itu sebabnya gambar berikutnya dengan ukuran 21.404 berhasil disajikan karena tidak diperlukan HDD menulis.
— Raptor
0

Tingkat unduhan Anda sangat rendah. (2,74 KB / s!). Apakah Anda mendapatkan hasil yang sama saat menjalankan wget pada mesin yang sama di mana Nginx berada? Bisa jadi Nginx bereaksi wajar terhadap permintaan melalui tautan yang sangat lambat.

Kalau tidak, saya sarankan menjelajahi berbagai arahan waktu dalam dokumen Nginx . Cari setiap penyebutan "batas waktu" pada halaman dan lihat apakah Anda menemukan kecocokan yang baik. Misalnya, Anda dapat melihat waktu Anda habis dalam interval 10 detik, sehingga batas waktu sekitar 10 detik harus mendapat pemeriksaan ekstra.

Sebagai contoh, lingering_timeout default direktif untuk 10 detik, sehingga Anda mungkin memeriksa bahwa.

Anda juga harus melihat mengapa koneksi dengan klien Anda tampaknya sangat lambat.

Gagasan lain: Coba klien alternatif, seperti curl, dan lihat Anda mendapatkan hasil yang sama seperti Anda melakukannya wget. Jika curlberfungsi dengan baik, Anda harus curiga ada yang aneh dengan wgetmembuat permintaan.

— Mark Stosberg
sumber
Itu bukan masalah klien, karena firefox bahkan memiliki masalah yang sama. Saya mencobanya dari mesin yang berbeda di geolokasi defferent. Perilaku yang sama. Selanjutnya, seperti yang Anda dapat menyebutkan kecepatannya cukup baik pada gambar kecil. ps. Pada mesin di mana nginx berada semuanya OK. Jadi saya akan mencoba menggali arahan timeout. pps. Itu bukan masalah jaringan, menyebabkan tautan apache langsung ke gambar yang sama berfungsi dengan sempurna.
— buru
0

Periksa lingering_time nilai di nginx.conf. Ini secara default akan diatur ke 30sec. Jadi yang akan dilakukan adalah, nginx akan menunggu maksimal 30 detik untuk klien mengirim data.

Jika Anda melakukan unggahan atau POST file yang mungkin membutuhkan waktu lebih dari 30 detik untuk menyelesaikan, maka server nginx akan mengatur ulang koneksi ke klien dengan mengirimkan paket RST ke klien jika waktu untuk mengunggah melebihi 30 detik.

Agar nginx menunggu lebih banyak waktu untuk mendengarkan data klien, lalu atur nilai ini ke nilai yang lebih tinggi.

Untuk info terperinci tentang lingering_time, lihat di sini lingering_time

— Sanath Holla
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.