Overhead and Fragmentation
So if you have a server with a certain amount of memory available for Varnish Cache, how much of that memory do we allocate to malloc? The conservative answer is 75%. So if we have 32GB of memory available, it’s recommended to only give malloc 25GB. Why? Overhead and fragmentation.https://info.varnish-software.com/blog/understanding-varnish-cache-memory-usage
First, we have to account for memory that Varnish Cache needs outside of storage. This is called overhead. Varnish Cache has 1KB overhead per object. So if you have 100,000 objects, Varnish Cache will require 100MB of memory to manage it. We also need to make sure we have enough memory for other things like thread stacks, request workspaces, and everything else that requires memory. Even the memory allocator requires upfront space. We can conservatively estimate this at around 100MB (default configuration). Together, we can estimate about 5% of the total storage size.
malloc
メモリ上にストレージを置いているVarnishで一番高速なストレージです。
メモリ上に置くため当然のことながらサーバの移設での一時停止や再起動、
workerのpanicでの自動再起動などでキャッシュが吹き飛んでしまいます。file
ファイル上にストレージを置く、若干遅いストレージです。
ファイルと名前はついているものの永続化を目的としておらず、
ストレージへの書き込み時にflushしません。
読み書きはページ・バッファキャッシュ、つまりOSに任せており
Varnishでは特に制御はおこなっていないため、オーバーヘッドが少なく高速です。
正直HDDを使っているときは、あまりおすすめできません。
しかし、SSDやioDriveといった高速なデバイスの場合は使えるストレージです。先程も書いた通り、永続化を目的としていないためmallocと同様に再起動でキャッシュが吹き飛びます。
名前に騙されてはいけません。
Varnishのストレージの話 – cat /dev/random > /dev/null & 2012
Storage backends file
The file backend stores objects in virtual memory backed by an unlinked file on disk with mmap, relying on the kernel to handle paging as parts of the file are being accessed.
https://varnish-cache.org/docs/trunk/users-guide/storage-backends.html#storage-backends
The file used by the file storage will be fully allocated, ie. you;ll have
a 75G file on your disk. Then varnish will mmap it to memory, which means
the kernel will give Varnish a memory space corresponding to the file
content. The trick is that the whole file doesn't need to be in memory,
only the "active" parts are.What happens is that we let the kernel manage that space, and it will
leverage the unused memory to do so. So, true, it you had 200G of RAM, the
file storage would effectively take 75G, because they would be available.
That's not your case, so the kernel will only use whatever amount is unused.That being said, outside of storage, Varnish uses roughly 1K per object
stored, that's probably not impacting right now, but that's good to keep in
mind.high memory usage with malloc and file backends configured 2017
> My understanding is that Varnish uses a mmap'd file, but it doesn't re-use
> the file's contents when it is restarted.Correct.
> Why does Varnish use a mmap'd file
> instead of just using regular virtual memory (swap) directly?For many small reasons, none of which are particularly good.
You can use regular VM by enabling the "malloc" storage method
and various people report good success with that.> I would think
> that the operating system would be more eager to write the data to the
> mmap'd file than it would be to write to swap; on a system where the hot
> cache entries can be stored on disk, it would seem that the swap-based
> method would be superior.Well, it's slightly more complex than that, we mmap with the
MAP_NOSYNC flag so it should be about a wash.mmap'd file vs. swap 2008
FreeBSD memory
https://unix.stackexchange.com/questions/234446/how-does-freebsd-allocate-memory
https://wiki.freebsd.org/Memory
https://forums.freebsd.org/threads/exploring-swap-on-freebsd.78418/
https://freebsd-hackers.freebsd.narkive.com/017STzQV/sudden-grow-of-memory-in-laundry-state
Tuning Jemalloc
https://info.varnish-software.com/blog/understanding-varnish-cache-memory-usage
FreeBSD 13.1 でエラー
: Invalid conf pair: lg_dirty_mult:8 : Invalid conf pair: lg_chunk:18
https://github.com/jemalloc/jemalloc/releases/tag/5.0.0
jemallocの更新で opt.lg_dirty_mult opt.lg_chunk は削除
