2012-10-16 11 views
20

私の顧客の1人がワニスのスピードの問題に遭遇しました。短いオブジェクトがキャッシュされているときにワニスが遅くなります(メモリ)

ロングデバッグ、:ニスは彼のキャッシュ(メモリ)からオブジェクトを取得すると
が、それは本当に低迷だ (> 5秒)、
ワニスは、(Apacheのバックエンド、無スピードの問題からオブジェクトを取得する必要がある場合< 1秒)。 (varnishlogから)遅い要求の

Exemple:

193 ReqStart  c <client ip> 59490 1329239608 
193 RxRequest c GET 
193 RxURL  c /<my_url>/toto.png 
193 RxProtocol c HTTP/1.1 
193 RxHeader  c Accept: */* 
193 RxHeader  c Referer: <my_referer> 
193 RxHeader  c Accept-Language: fr 
193 RxHeader  c User-Agent: <client_useragent> 
193 RxHeader  c Accept-Encoding: gzip, deflate 
193 RxHeader  c Host: <my_vhost> 
193 RxHeader  c Connection: Keep-Alive 
193 VCL_call  c recv lookup 
193 VCL_call  c hash 
193 Hash   c /<my_url>/toto.png 
193 Hash   c <my_vhost> 
193 VCL_return c hash 
193 Hit   c 1329136358 
193 VCL_call  c hit deliver 
193 VCL_call  c deliver deliver 
193 TxProtocol c HTTP/1.1 
193 TxStatus  c 200 
193 TxResponse c OK 
193 TxHeader  c Server: Apache 
193 TxHeader  c Last-Modified: Mon, 18 Jun 2012 08:57:46 GMT 
193 TxHeader  c ETag: "c330-4c2bb5c0ef680" 
193 TxHeader  c Cache-Control: max-age=1200 
193 TxHeader  c Content-Type: image/png 
193 TxHeader  c Content-Length: 49968 
193 TxHeader  c Accept-Ranges: bytes 
193 TxHeader  c Date: Tue, 16 Oct 2012 06:54:03 GMT 
193 TxHeader  c X-Varnish: 1329239608 1329136358 
193 TxHeader  c Age: 391 
193 TxHeader  c Via: 1.1 varnish 
193 TxHeader  c Connection: keep-alive 
193 TxHeader  c X-Cache: HIT 
193 TxHeader  c X-Cache-Hits: 210 
193 Length  c 49968 
193 ReqEnd  c 1329239608 1350370443.778280735 1350370480.921206713 0.372072458 0.000045538 37.142880440 

私は本当だ場合、問題は最後の行(ReqEnd)上で、
37.142880440ファイルを送信するために秒単位の時間です。
私はローカルで同じ問題を抱えています(バンド問題ではありません)。

この問題は、最大の訪問者がここにいる(〜400req/s)午前中にのみ発生します。ニスのための

オプション:

DAEMON_OPTS="-a :80 \ 
      -T localhost:6082 \ 
      -f /etc/varnish/default.vcl \ 
      -S /etc/varnish/secret \ 
      -p thread_pool_min=100 \ 
      -p thread_pool_max=1000 \ 
      -p session_linger=100 \ 
      -s malloc,8G" 

ワニスは、十分なRAMを持っているし、罰金のように見える:

SMA.s0.c_req    4303728  38.35 Allocator requests 
SMA.s0.c_fail     0   0.00 Allocator failures 
SMA.s0.c_bytes  169709790476 1512443.66 Bytes allocated 
SMA.s0.c_freed  168334747402 1500189.36 Bytes freed 
SMA.s0.g_alloc   172011   . Allocations outstanding 
SMA.s0.g_bytes  1375043074   . Bytes outstanding 
SMA.s0.g_space  7214891518   . Bytes available 

n_wrk      200   . N worker threads 
n_wrk_create    200   0.00 N worker threads created 
n_wrk_failed     0   0.00 N worker threads not created 
n_wrk_max     0   0.00 N worker threads limited 
n_wrk_lqueue     0   0.00 work request queue length 
n_wrk_queued    26   0.00 N queued work requests 
n_wrk_drop     0   0.00 N dropped work requests 

n_lru_nuked     0   . N LRU nuked objects 
n_lru_moved   8495031   . N LRU moved objects 

ニスが最新(3.0.3-1〜レニー)です。あなたが実際に推奨される最小で、以来、あなたが持っていた

-p thread_pool_max=1000 

を持っていた

backend default { 
    .host = "127.0.0.1"; 
    .port = "8000"; 
    .connect_timeout = 10s; 
    .first_byte_timeout = 10s; 
    .between_bytes_timeout = 5s; 
} 

sub vcl_recv { 
    set req.grace = 1h; 

    if (req.http.Accept-Encoding) { 
    if (req.http.Accept-Encoding ~ "gzip") { 
     set req.http.Accept-Encoding = "gzip"; 
    } 
    else if (req.http.Accept-Encoding ~ "deflate") { 
     set req.http.Accept-Encoding = "deflate"; 
    } 
    else { 
     unset req.http.Accept-Encoding; 
    } 
    } 

    if (req.url ~ "(?i)\.(png|gif|jpeg|jpg|ico|swf|css|js|eot|ttf|woff|svg|htm|xml)(\?[a-z0-9]+)?$") { 
    unset req.http.Cookie; 
    } 

    if (req.url ~ "^/content/.+\.xml$") { 
    unset req.http.Cookie; 
    } 

    if (req.url ~ "^/min/") { 
    unset req.http.Cookie; 
    } 

    if (req.restarts == 0) { 
    if (req.http.x-forwarded-for) { 
     set req.http.X-Forwarded-For = 
     req.http.X-Forwarded-For + ", " + client.ip; 
    } else { 
     set req.http.X-Forwarded-For = client.ip; 
    } 
    } 
    if (req.request != "GET" && 
    req.request != "HEAD" && 
    req.request != "PUT" && 
    req.request != "POST" && 
    req.request != "TRACE" && 
    req.request != "OPTIONS" && 
    req.request != "DELETE") { 
     return (pipe); 
    } 
    if (req.request != "GET" && req.request != "HEAD") { 
     return (pass); 
    } 
    if (req.http.Authorization || req.http.Cookie) { 
     return (pass); 
    } 
    return (lookup); 
} 

sub vcl_fetch { 
    if (req.url ~ "(?i)\.(png|gif|jpeg|jpg|ico|swf|css|js|eot|ttf|woff|svg|htm|xml)(\?[a-z0-9]+)?$") { 
     unset beresp.http.set-cookie; 
    } 

    if (req.url ~ "^/(content|common)/.+\.xml$") { 
     unset req.http.Cookie; 
    } 

    if (req.url ~ "^/min/") { 
     unset req.http.Cookie; 
    } 

    set beresp.grace = 1h; 

    if (beresp.ttl <= 0s || 
     beresp.http.Set-Cookie || 
     beresp.http.Vary == "*") { 
     set beresp.ttl = 120s; 
     return (hit_for_pass); 
    } 
    return (deliver); 
} 

sub vcl_deliver { 
    if (obj.hits > 0) { 
     set resp.http.X-Cache = "HIT"; 
     set resp.http.X-Cache-Hits = obj.hits; 
    } else { 
     set resp.http.X-Cache = "MISS"; 
    } 

    return (deliver); 
} 
+0

私は過去に「ホット」キャッシュされたURLが非常に遅くなり、高いreq/sのプロダクションでしか現れなかった、これまで同様の問題にぶつかりました。 問題は捕捉するのが難しく、開発者が行動できる検証可能なバグレポートを生成することができませんでした。 – ttt

+0

私はこの問題を回避するために、2番目のワニスサーバに負荷を分割することを検討しています。 私の経験のワニスからは、このような特定の状況でしか現れないこのような問題を捕らえるのがより微妙で難しいです。まだ十分に成熟していないと思います。サポートをニスするために問題を再現またはデモンストレーションする手順を記述できる場合は、どうかしてください: – ttt

+4

これを理解しましたか? –

答えて

1

あなたのアイデアやトラックを持っている場合は...

ワニスの設定

n_wrk_queued 26 

これは、スレッドを増やすべき時の指標であり、例えば2000に変更し、さらに必要がないことを確認するためにn_wrk_queuedを目にしていたら、うまくいきました。

関連する問題