Version: 4.1.3
Operating system: 6.6 Centos
Reference Documentation:
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
"Tuning the monitoring tools involved"
Varnishstat #实时的数据 up and down to see each indicator data
Varnishstat-1 #打印统计信息到屏幕上, all indicators information more comprehensive
"Common varnish Important indicators"
SMA.s0.g_bytes memory used by the cache #一般varnish运行时间长 allocated memory will be exhausted
SMA.s0.g_space Cache Total Memory How much is left
Note: The allocation of memory to the cache, only varnish restart to take effect, reload is not effective, meaning that the focus on varnish all the cache to be re-lost, so varnish allocate how much memory to consider good. It cannot be adjusted dynamically during operation.
LRU nuked objects: The number of objects that have to be removed to represent the memory that the cache can use to reach the line
LRU moved objects: The number of objects that are moved on behalf of the LRU policy (moving because of the LRU algorithm principle, not removal)
Note: The most important indicator is nuked (not a move), which tells us how many objects are removed from the cache, based on the LRU algorithm. If this data grows fast, you need to consider increasing your memory.
Main.thread_queue_len shows the number of threads that are waiting for a thread to be in the current callback.
The number of main.sess_queued contained in the queue is waiting for the queued. The reason is that there are no threads available at the moment. Consider to increase the thread_pool_min parameter. This number is static, which is usually generated on startup, so it is useless to find a way to adjust the value of thread_pool_min in the middle of the process. But does not affect, as long as does not increase.
main.sess_droppedCounts How many times sessions is dropped because varnishd hits the maximum thread queue length . Consider to increase the Thread_queue_limit Varnish parameter as a solution to drop less sessions. This value should be 0.
Note:Thread_queue_len reacts to the current thread's stress, and the general thread is sufficient for this value to be 0. Sess_drop should be 0 under normal conditions.
MAIN. N_object–number of object structs made. The number of objects in the cache.
Main.n_expired the number of expired objects and the set cache TTL value is related if you set the TTL time for a non-200 state to be short as 30 seconds. and 302 304 of them are more. This data will grow more quickly.
Thread: This needs to be measured in deciding what value to set to fit.
Main.threads_limited: How many threads need to be created, but not possible, because Thread_pool_max is set. So this value is generally 0. If not 0 is not enough thread, but can not be created.
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 is 0
Main.threads the number of threads currently working
Thread_pools 2 [pools] (default
Thread_pools: Used to set the number of thread pool, it is generally considered that this value and the number of system CPUs is the best, too many pools,varnish can be set more concurrent processing power, but also consumes more CPU and memory
thread_pool_min [Threads]
Thread_pool_min: Used to set the minimum threads number for each pool, and when the pool receives the available requests, the request is assigned to the idle threads for processing.
Thread_pool_max: Represents the maximum value of the sum of threads for each pool, this value cannot be too large, can be set to about 90% of the system peak, set too large, will cause the process to live hung.
Hread_pool_timeout: Indicates the timeout expiration time of the threads, when threads idle exceeds the Thread_pool_timeout set time when the threads number is greater than the Thread_pool_min set value, Thread will be removed and released. This parameter is not very important
The thread_pool_timeout is how long a thread was kept around when there was no work for it before it was removed. This if applies has more threads than the minimum, and is rarely changed.
Another less important parameter are 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 [seconds]
Re-set Pool
Param.set Thread_pools 4
Reset the maximum number of threads
Param.set Thread_pool_max 5000
"Backend connections recycled" is increased whenever we had a keep-alive connection that was put back into the pool of con Nections. It has no yet been used, but it might is, unless the backend closes it.
"Backend connections reused" is increased whenever we actually reuse a connection from the pool of backend connections.
"Extending Knowledge"
Reference: http://flychao88.iteye.com/blog/1977653
1 LRU algorithm
The core idea of the LRU (Least recently used, least recently used) algorithm is to retire data based on the historical access records of the data, with the heart being that "if the data has been accessed recently, the chances of being accessed in the future are higher".
1.2. Implement
The most common implementation is to use a linked list to save the cached data, the detailed algorithm is implemented as follows:
650) this.width=650; "src=" Http://my.csdn.net/uploads/201205/24/1337859321_3597.png "style=" border:0px;margin:0px ;p adding:0px; "/>
1. Inserting new data into the list head;
2. Whenever the cache hits (that is, the cached data is accessed), the data is moved to the list header;
3. When the list is full, discard the data at the end of the list.
1.3. Analysis
Hit rate
When there is hot data, LRU efficiency is very good, but the occasional, periodic batch operation will cause the LRU hit rate drops sharply, the cache pollution is more serious.
"Complexity"
Simple to implement.
Cost
A hit will need to traverse the linked list, find the hit block index, and then need to move the data to the head.
This article is from "Swallow Lie triple" blog, please be sure to keep this source http://cuidehua.blog.51cto.com/5449828/1871924
Performance Tuning for Varnish