版本:4.1.3

操作系統: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

【調優涉及的監控工具】

varnishstat ? ? #實時的數據 上下可以翻動查看各個指標數據

varnishstat -1 ? #打印統計信息到屏幕上，所有的指標信息 信息更全面

【常見varnish重要指標】

SMA.s0.g_bytes ?緩存已經使用的內存 ? ? ?#一般varnish運行時間長 ?分配的內存都會被耗盡

SMA.s0.g_space ?緩存總共內存還剩余多少

注:內存的分配給緩存多少，只有varnish重啟才能生效，reload是不生效的，意味著重啟varnish所有的緩存都要重新丟失，所以varnish分配多少內存要考慮好。運行期間就不能動態調整了。

LRU nuked objects ：代表緩存可使用的內存以達上線而不得不移除的對象個數?

LRU moved objects ：代表LRU策略被移動的對象個數(移動 因為LRU算法原理有關，不是移除)

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

MAIN.thread_queue_len 展示了當前回話等待一個線程的數量。

MAIN.sess_queued? 包含的回話數量被等待在隊列中的。原因是沒有可用的線程此刻。考慮去增加thread_pool_min參數。 這個數目是靜態的，一般是啟動就生成的，所以在中途過程中發現 再去調整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. 這個值應該為0

注意:thread_queue_len 反應當前線程的壓力，一般線程足夠這個值應該為0。 sess_drop 正常情況下應該為0.

MAIN.n_object – Number of object structs made。緩存中的對象數目。

MAIN.n_expired ?過期的對象數目 ?和設置的緩存TTL值相關，如果你設置了非200狀態的TTL時間很短如30秒。而其中的302 304 比較多。這個數據就會增長比較快。

線程: 這個需要進行壓測在決定設置什么值更適合。

MAIN.threads_limited: 多少個線程需要去創建，但是不可能，因為thread_pool_max被設置了。所以這個值一般為0.如果不為0 就是有線程不夠，但是又不能去創建。

?????????????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 ?當前工作的線程數 ?

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

thread_pools：用來設置線程池的數量，一般認為這個值和系統CPU的數目相同最好，設置過多的pools，varnish的并發處理能力會更強，但是也會消耗更多的CPU和內存

thread_pool_min ? ? ? ? ? ?50 [threads]

thread_pool_min：用來設置每個pool的最小threads數，當pool接收到可用的請求后，就會將請求分配給空閑的threads來處理。

thread_pool_max：表示每個pool對應的threads數總和的最大值，此值不能太大，可以設置為系統峰值的90%左右即可，設置過大，會導致進程hung住。

hread_pool_timeout：表示threads的超時過期時間，當threads數大于thread_pool_min設定值時，threads空閑超過thread_pool_timeout設定的時間時，thread就會被移除釋放掉。這個參數不是很重要

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]

重新設置pool

param.set thread_pools 4

重新設置最大的線程數

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.

【擴展知識】

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

1 LRU算法

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

1.2.?實現

最常見的實現是使用一個鏈表保存緩存數據，詳細算法實現如下：

1.?新數據插入到鏈表頭部；

2.?每當緩存命中（即緩存數據被訪問），則將數據移到鏈表頭部；

3.?當鏈表滿的時候，將鏈表尾部的數據丟棄。

1.3.?分析

【命中率】

當存在熱點數據時，LRU的效率很好，但偶發性的、周期性的批量操作會導致LRU命中率急劇下降，緩存污染情況比較嚴重。

【復雜度】

實現簡單。

【代價】

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

轉載于:https://blog.51cto.com/cuidehua/1871924

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。