2012-10-16 15 views
20

मेरे ग्राहक में से एक वार्निश के लिए गति की समस्या के साथ आया था।ऑब्जेक्ट कैश किए जाने पर वार्निश धीमा (मेमोरी)

लांग डिबग, लघु:
जब वार्निश अपने कैश (स्मृति) से एक वस्तु मिलता है, यह वास्तव में सुस्त है (> 5 सेकंड),
जब वार्निश अपाचे बैकएंड, कोई गति की समस्या से वस्तु प्राप्त करने की आवश्यकता (< 1 सेकंड)।

धीमे अनुरोध (varnishlog से) का उदाहरण:

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) पर है,
३७.१४,२८,८०,४४० यह सेकंड में समय फ़ाइल भेजने के लिए है ।
मुझे स्थानीय पर एक ही समस्या है (इसलिए यह बैंडविड्थ समस्या नहीं है)।

समस्या केवल तभी होती है जब अधिकतम आगंतुक यहां हैं (~ 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" 

वार्निश पर्याप्त राम है और ठीक होने लगते हैं:

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 ~ लेनी)।

आप एक विचार या एक ट्रैक है ...

वार्निश विन्यास:

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

मैंने अतीत में इसी तरह की समस्या को मारा, जहां कभी-कभी 'हॉट' कैश किया गया यूआरएल बहुत ही धीमा हो गया और केवल उच्च रिक/एस के साथ उत्पादन में प्रकट हुआ। समस्या को पकड़ना मुश्किल था और मैंने सत्यापित करने योग्य बग रिपोर्ट तैयार करने में कामयाब नहीं रहा है कि डेवलपर्स कार्य कर सकते हैं। – ttt

+0

मुझे लगता है कि हमने लोड को दूसरे वार्निश सर्वर में विभाजित करके इस समस्या के आसपास काम किया था। मेरे अनुभव से वार्निश में इस तरह के मुद्दों को पकड़ने के लिए और अधिक सूक्ष्म और कठिन है जो केवल विशिष्ट परिस्थितियों में प्रकट होता है - मुझे लगता है कि यह अभी तक पर्याप्त परिपक्व नहीं है। यदि आप वार्निश समर्थन के लिए समस्या को पुन: उत्पन्न या प्रदर्शित करने के लिए चरणों का वर्णन कर सकते हैं - इसके लिए कृपया :) – ttt

+4

क्या आपने इसे समझ लिया? –

उत्तर

1

आप

-p thread_pool_max=1000 

था जो वास्तव में एक न्यूनतम है की सिफारिश की है, और जब से तुम था

n_wrk_queued 26 

जो एक संकेतक है कि धागे को बढ़ाने का समय है, मुझे विश्वास है कि अगर आपने इसे 2000 में बदल दिया है और उदाहरण के लिए n_wrk_queued के लिए नजर रखी है, तो यह सुनिश्चित करने के लिए कि आपको और अधिक की आवश्यकता नहीं है, चीजें ठीक से काम कर सकतीं।

संबंधित मुद्दे