版本:4.1.3

操作系統(tǒng):6.6 Centos

參考文檔:

http://book.varnish-software.com/4.0/chapters/Examining_Varnish_Server_s_Output.html

https://www.varnish-cache.org/docs/4.1/reference/varnish-counters.html

【調(diào)優(yōu)涉及的監(jiān)控工具】

varnishstat ? ? #實(shí)時(shí)的數(shù)據(jù) 上下可以翻動(dòng)查看各個(gè)指標(biāo)數(shù)據(jù)

varnishstat -1 ? #打印統(tǒng)計(jì)信息到屏幕上，所有的指標(biāo)信息 信息更全面

【常見varnish重要指標(biāo)】

SMA.s0.g_bytes ?緩存已經(jīng)使用的內(nèi)存 ? ? ?#一般varnish運(yùn)行時(shí)間長 ?分配的內(nèi)存都會(huì)被耗盡

SMA.s0.g_space ?緩存總共內(nèi)存還剩余多少

注:內(nèi)存的分配給緩存多少，只有varnish重啟才能生效，reload是不生效的，意味著重啟varnish所有的緩存都要重新丟失，所以varnish分配多少內(nèi)存要考慮好。運(yùn)行期間就不能動(dòng)態(tài)調(diào)整了。

LRU nuked objects ：代表緩存可使用的內(nèi)存以達(dá)上線而不得不移除的對(duì)象個(gè)數(shù)?

LRU moved objects ：代表LRU策略被移動(dòng)的對(duì)象個(gè)數(shù)(移動(dòng) 因?yàn)長RU算法原理有關(guān)，不是移除)

注意:最重要的指標(biāo)是 nuked(不是move)，它告訴我們有多少個(gè)對(duì)象從緩存中移除，基于LRU算法。如果這個(gè)數(shù)據(jù)增長很快，你就需要考慮增大你的內(nèi)存。

MAIN.thread_queue_len 展示了當(dāng)前回話等待一個(gè)線程的數(shù)量。

MAIN.sess_queued? 包含的回話數(shù)量被等待在隊(duì)列中的。原因是沒有可用的線程此刻。考慮去增加thread_pool_min參數(shù)。 這個(gè)數(shù)目是靜態(tài)的，一般是啟動(dòng)就生成的，所以在中途過程中發(fā)現(xiàn) 再去調(diào)整thread_pool_min的值，是沒用的。不過不影響，只要不增加。

MAIN.sess_droppedCounts how many times sessions are dropped because varnishd hits the maximum thread queue length. You may consider to increase the thread_queue_limit Varnish parameter as a solution to drop less sessions. 這個(gè)值應(yīng)該為0

注意:thread_queue_len 反應(yīng)當(dāng)前線程的壓力，一般線程足夠這個(gè)值應(yīng)該為0。 sess_drop 正常情況下應(yīng)該為0.

MAIN.n_object – Number of object structs made。緩存中的對(duì)象數(shù)目。

MAIN.n_expired ?過期的對(duì)象數(shù)目 ?和設(shè)置的緩存TTL值相關(guān)，如果你設(shè)置了非200狀態(tài)的TTL時(shí)間很短如30秒。而其中的302 304 比較多。這個(gè)數(shù)據(jù)就會(huì)增長比較快。

線程: 這個(gè)需要進(jìn)行壓測(cè)在決定設(shè)置什么值更適合。

MAIN.threads_limited: 多少個(gè)線程需要去創(chuàng)建，但是不可能，因?yàn)閠hread_pool_max被設(shè)置了。所以這個(gè)值一般為0.如果不為0 就是有線程不夠，但是又不能去創(chuàng)建。

?????????????threads limited" is the number of times Varnish wanted to create a worker thread, but wasn't able to ?????????????because of the thread_pool_max setting. This should also be 0

MAIN.threads ?當(dāng)前工作的線程數(shù) ?

thread_pools ? ? ? ? ? ? ? 2 [pools] (default

thread_pools：用來設(shè)置線程池的數(shù)量，一般認(rèn)為這個(gè)值和系統(tǒng)CPU的數(shù)目相同最好，設(shè)置過多的pools，varnish的并發(fā)處理能力會(huì)更強(qiáng)，但是也會(huì)消耗更多的CPU和內(nèi)存

thread_pool_min ? ? ? ? ? ?50 [threads]

thread_pool_min：用來設(shè)置每個(gè)pool的最小threads數(shù)，當(dāng)pool接收到可用的請(qǐng)求后，就會(huì)將請(qǐng)求分配給空閑的threads來處理。

thread_pool_max：表示每個(gè)pool對(duì)應(yīng)的threads數(shù)總和的最大值，此值不能太大，可以設(shè)置為系統(tǒng)峰值的90%左右即可，設(shè)置過大，會(huì)導(dǎo)致進(jìn)程hung住。

hread_pool_timeout：表示threads的超時(shí)過期時(shí)間，當(dāng)threads數(shù)大于thread_pool_min設(shè)定值時(shí)，threads空閑超過thread_pool_timeout設(shè)定的時(shí)間時(shí)，thread就會(huì)被移除釋放掉。這個(gè)參數(shù)不是很重要

The thread_pool_timeout is how long a thread is kept around when there is no work for it before it is removed. This only applies if you have more threads than the minimum, and is rarely changed.

Another less important parameter is the thread_pool_fail_delay, which defines how long to wait after the operating system denied us a new thread before we try again.

lru_interval ? ? ? ? ? ? ? 20 [seconds]

重新設(shè)置pool

param.set thread_pools 4

重新設(shè)置最大的線程數(shù)

param.set thread_pool_max 5000

"Backend connections recycled" is increased whenever we have a keep-alive connection that is put back into the pool of connections. It has not yet been used, but it might be, unless the backend closes it.

"Backend connections reused" is increased whenever we actually reuse a connection from the pool of backend connections.

【擴(kuò)展知識(shí)】

參考:?http://flychao88.iteye.com/blog/1977653

1 LRU算法

LRU（Least?recently?used，最近最少使用）算法根據(jù)數(shù)據(jù)的歷史訪問記錄來進(jìn)行淘汰數(shù)據(jù)，其核心思想是“如果數(shù)據(jù)最近被訪問過，那么將來被訪問的幾率也更高”。

1.2.?實(shí)現(xiàn)

最常見的實(shí)現(xiàn)是使用一個(gè)鏈表保存緩存數(shù)據(jù)，詳細(xì)算法實(shí)現(xiàn)如下：

1.?新數(shù)據(jù)插入到鏈表頭部；

2.?每當(dāng)緩存命中（即緩存數(shù)據(jù)被訪問），則將數(shù)據(jù)移到鏈表頭部；

3.?當(dāng)鏈表滿的時(shí)候，將鏈表尾部的數(shù)據(jù)丟棄。

1.3.?分析

【命中率】

當(dāng)存在熱點(diǎn)數(shù)據(jù)時(shí)，LRU的效率很好，但偶發(fā)性的、周期性的批量操作會(huì)導(dǎo)致LRU命中率急劇下降，緩存污染情況比較嚴(yán)重。

【復(fù)雜度】

實(shí)現(xiàn)簡單。

【代價(jià)】

命中時(shí)需要遍歷鏈表，找到命中的數(shù)據(jù)塊索引，然后需要將數(shù)據(jù)移到頭部。

轉(zhuǎn)載于:https://blog.51cto.com/cuidehua/1871924

總結(jié)

以上是生活随笔為你收集整理的Varnish的性能调优的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。