1. Time to Live (TTL):
   • Definition: TTL is the duration for which a cached object is considered fresh and can be served from the cache without checking the origin server.
   • Usage: When a request is made, the caching system checks if the object is still within its TTL. If yes, it serves the cached version; otherwise, it fetches a fresh copy from the origin server.
2. Grace:
   • Definition: Grace is an extension of the TTL concept. It represents the additional time during which a cached object can be served even after its TTL has expired, while the caching system attempts to fetch a fresh copy from the origin server.
   • Usage: If a cached object’s TTL has expired but it is still within the grace period, the caching system may serve it while initiating a background request to the origin server to refresh the content.
3. Keep:
   • Definition: Keep is another extension of the TTL concept, specifying the maximum time a cached object can be retained in the cache, irrespective of whether the TTL has expired.
   • Usage: Keep allows the caching system to retain objects in the cache for a longer duration, even if the TTL has expired. It is useful in scenarios where you want to keep certain objects in the cache for a fixed period, regardless of their freshness.

In summary:

• TTL: Specifies how long an object remains valid in the cache.
• Grace: Represents the additional time during which an expired object can still be served while a background fetch is attempted.
• Keep: Defines the maximum duration an object can be retained in the cache, regardless of its TTL.

These parameters provide flexibility in balancing the need for serving fresh content and minimizing the load on the origin server by intelligently managing cached objects. Configuring TTL, grace, and keep values requires consideration of the specific requirements and characteristics of the cached content.

The post Understanding the lifetime of Varnish cached objects: TTL, grace, and keep appeared first on Sergey Lysenko.

Error: Child (65162) died signal=6
Error: Child (65162) Panic at: Fri, 25 Mar 2022 11:18:31 GMT
Assert error in obj_getmethods(), cache/cache_obj.c line 98:
  Condition((oc->stobj->stevedore) != NULL) not true.
version = varnish-6.5.2 revision NOGIT, vrt api = 12.0

The content of the error is not important here, the main thing here is that the child process has died. In this case, the cache will naturally be lost:

If you notice this, then you should pay attention to the transparent_hugepage setting on the server. If it is set to always, then this is bad and varnish warns about this in the documentation.

How to check? Login to the server and run the command:

cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

You need to set this parameter to transparent_hugepage=madvise. To do this, edit the grub file:

nano /etc/default/grub

Find the parameter there:

GRUB_CMDLINE_LINUX="...

Add a value to it:

transparent_hugepage=madvise

As a result, the parameter will look something like this:

GRUB_CMDLINE_LINUX="resume= ... quiet transparent_hugepage=madvise"

After that run:

grub2-mkconfig -o /boot/grub2/grub.cfg
reboot

The above steps set this setting permanently. This will allow Varnish to comply with the requirements and it will work more correctly.

The post Spontaneous loss of Varnish cache appeared first on Sergey Lysenko.

In that case, you’ll see such errors in your system log:

kernel: varnishd[20091]: segfault at 4a82dd8a ip 00007f1c58ed277d sp 00007f1c52293458 error 4 in libexecinfo.so.1[7f1c58ec6000+d000]

This is because Varnish does not work well with the libexecinfo library. The developers are aware of this and at some point they decided to drop libexecinfo and start using libunwind.

If you are using Varnish 4.1.11 then you have 2 options to get rid of the error:

1. Upgrade Varnish to version 6.5, in which case you will have to rewrite the VCL and check the compatibility of previously used modules;
2. Patch Varnish 4.1.11 yourself, because the developers did not provide this fix for older versions.

I have prepared a patch for Varnish 4.1.11 to enable –with-unwind configure switch. You can download and apply it on the Varnish source code, then just rebuild and use it.

The post Varnish segfault because of libexecinfo.so appeared first on Sergey Lysenko.

The master process of the Varnish controls the execution of the child process, which contains the entire cache. The operating system running the Varnish has an oom-killer that makes sure the system has enough memory to run and calculates which processes can be killed. When a child process of a Varnish grows in size, it becomes the first candidate for termination. After the child process terminates, the Varnish master process spawns a new child process and the accumulated cache is completely lost.

At the same time, the memory consumption graph shows us:

In this case, the following messages can be seen in the host’s log:

kernel: Memory cgroup out of memory: Killed process 21363 (varnishd) total-vm:5264564kB, anon-rss:5099268kB, file-rss:0kB, shmem-rss:0kB, UID:1000720000 pgtables:10344kB oom_score_adj:682
kernel: oom_reaper: reaped process 21363 (varnishd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

To understand whether the child process rebooted or not, just look at varnishstat, the very top lines will show the lifetime of the master and child processes:

If the lifetime at the top is the same, then the child process was not killed. If different, then he was previously killed.

The Transient cache is a special type of Varnish storage for objects with very low ttl. By default it is 10 seconds. This ttl is controlled by “shortlived” parameter:

This is a special storage for short-lived objects, which is always active, on any installation, even if you did not specifically configure it. This is where an unexpected surprise can await us: this storage has no size limit by default! That is, you will simply use up all the memory over time and notice something only when the varnish loses the cache.

To avoid an uncontrolled increase in memory consumption, you need to set a memory limit for the Varnish. Usually, only one limit is set, but as mentioned above, there is one more additional storage (transient), so you need to set two values.

Each cache store in a Varnish can be named. This is convenient if you want to put different objects in different storages, for example, some in RAM, and others on disk. It is easy to set a limit for the transient storage, it is enough just to specify storage named Transient at startup. Another storage, where all other objects will be stored, can be called Cache, or by any other name.

This is what the parameters for launching a Varnish with the specified value of memory limits look like:

varnishd -s Cache=malloc,${CACHE_MEMORY} -s Transient=malloc,${TRANSIENT_MEMORY}

Let’s say you have 8 gigabytes of memory on the instance, how much memory should we allocate for each storage? First, we agree that we cannot use all 8 gigabytes of memory, it is recommended to use 75% of the host’s available memory. That is, we have 6 gigabytes left. This memory can be divided 80 / 20: 4.8 gigabytes for the main storage, and 1.2 gigabytes for the Transient storage.

Here are the values of the memory parameters:

CACHE_MEMORY = 4800M
TRANSIENT_MEMORY = 1200M

To see and track how memory is actually being used, you can look at varnishstat again:

Once you’ve set a Transient cache limit, you may notice that Varnish no longer suddenly loses cache.

The post Setup Varnish Transient cache for Magento appeared first on Sergey Lysenko.

First, log in to your Varnish instance and get to Varnish console:

varnishadm -S /usr/local/var/varnish/secret -T localhost:6082

You can perform there some commands. For example, you can list available compiled Varnish configs using the command:

vcl.list

So you have changed your vcl and wish to reload it. First, you should compile the new version of it:

vcl.load varnish_01 /usr/local/etc/varnish/default.vcl

Where varnish_01 is the custom name for your new configuration, you can create multiple configs, but only one is active.

Then after successful compiling, you can apply the new config using:

vcl.use varnish_01

So, the new version of the config is applied. Easy peasy.

To quit the CLI just use:

quit

The post Reload Varnish VCL using varnishadm appeared first on Sergey Lysenko.