<div dir="ltr"><div>Hello Luca,</div><div><br></div><div>This should give you some information: <a href="https://info.varnish-software.com/blog/understanding-varnish-cache-memory-usage" target="_blank">https://info.varnish-software.com/blog/understanding-varnish-cache-memory-usage</a> . Notably, you need to account for some memory fragmentation.</div><div><br></div><div>Note that your formula is probably a bit optimistic: each thread is allowed to consume as much as workspace_client/workspace_backend, and workspace will be consumed by VCL operations, like regex matching and substitutions.</div><div><br></div><div>One thing you can do is use vmod_vtc: <a href="https://varnish-cache.org/docs/trunk/reference/vmod_vtc.html#int-workspace-free-enum-client-backend-session-thread">https://varnish-cache.org/docs/trunk/reference/vmod_vtc.html#int-workspace-free-enum-client-backend-session-thread</a> . You could log the remaining size for all requests and see how close you get to zero.</div><div><br></div><div>I'd like to ask: which Varnish packages are you using? (i.e. version and origin). I know some people have been hurt before, by the jemalloc package I think, and depending on how Varnish is built, you can get better a smaller memory footprint.<br></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br></div><div>Guillaume Quintard<br></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 1, 2024 at 5:02 PM Luca Gervasi <<a href="mailto:luca.gervasi@gmail.com" target="_blank">luca.gervasi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<div>I'm following an issue that caused some OOMs during a huge spike.</div><div>Currently I have the following properties set:</div><div><br></div><div> -p thread_pool_max=2000 \<br> -p thread_pool_min=35 \<br> -p feature=+esi_disable_xml_check \<br> -p feature=+esi_ignore_other_elements \<br> -p feature=+esi_remove_bom \<br> -p feature=+http2 \<br> -p pcre_match_limit_recursion=64 \<br> -p syslog_cli_traffic=off \<br> -p sigsegv_handler=on \<br> -p workspace_client=2m \<br> -p workspace_backend=2m \<br> -p http_max_hdr=128 \<br> -p http_req_hdr_len=32k \<br> -p http_resp_hdr_len=32k \<br> -p http_req_size=2m \<br> -p http_resp_size=2m \<br> -p thread_pool_stack=256k \<br> -s malloc,20G \<br> -S /config/varnish/secret \<br> -f /config/varnish/default.vcl \<br> -p vsl_reclen=700<br></div><div><br></div><div>And I'm using this formula to somehow calculate how much memory is varnish going to use:</div><div>thread_pool_max*thread_pool_stack+thread_pool_max*(workspace_client+http_req_hdr_len+http_req_size) + malloc<br><br>And it is somewhere close to where I get OOM. I suspect that what did screw up was the high esi-to-request ration that I normally have:</div><div><br></div><div>MAIN.client_req 469.22<br>MAIN.esi_req 5489.25<br></div><div><br></div><div>Hit rate on that esi requests is pretty high as we use high ttls and invalidations, but I think that those ESIs have to be taken into account too (as well as the backend requests too...).</div><div><br></div><div>I wasn't able to find an official memory sizing guide, sorry. How do you size correctly memory usage?</div><div>I know I should use MSE, at the moment is not on my list.</div><div><br></div><div>Thanks</div><div>Luca</div></div>
_______________________________________________<br>
varnish-misc mailing list<br>
<a href="mailto:varnish-misc@varnish-cache.org" target="_blank">varnish-misc@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc" rel="noreferrer" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc</a><br>
</blockquote></div>