<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Articles on Ignacio Ballester</title><link>https://ignacioballester.com/articles/</link><description>Recent content in Articles on Ignacio Ballester</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 07 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://ignacioballester.com/articles/index.xml" rel="self" type="application/rss+xml"/><item><title>When zram Makes Kubernetes Nodes Read From Disk</title><link>https://ignacioballester.com/articles/zram-swap-reclaim-loop/</link><pubDate>Fri, 07 Aug 2026 00:00:00 +0000</pubDate><guid>https://ignacioballester.com/articles/zram-swap-reclaim-loop/</guid><description>&lt;p&gt;Kubernetes nodes whose image ships with a zram swap device can produce a continuous stream of major page faults under memory pressure. Nodes without zram do not show it.&lt;/p&gt;
&lt;p&gt;The cause is two settings interacting on the same node, and the fix is a one-line change to one of them.&lt;/p&gt;
&lt;h2 id="diagnosis"&gt;Diagnosis&lt;/h2&gt;
&lt;p&gt;The metric that exposes the behavior is &lt;code&gt;node_vmstat_pgmajfault&lt;/code&gt;. A major page fault means that a page was not in memory and had to be fetched from a backing store. Under memory pressure, the rate can become &lt;strong&gt;continuously elevated rather than appearing as occasional spikes&lt;/strong&gt;.&lt;/p&gt;</description></item><item><title>Sizing a JVM Container — Increasing the Limit is not Enough</title><link>https://ignacioballester.com/articles/jvm-memory-sizing/</link><pubDate>Mon, 20 Jul 2026 00:00:00 +0000</pubDate><guid>https://ignacioballester.com/articles/jvm-memory-sizing/</guid><description>&lt;p&gt;Out of the box the modern JVM sizes its heap at 25 % of the container, for containers above roughly 500 MiB.&lt;sup id="fnref:1"&gt;&lt;a href="#fn:1" class="footnote-ref" role="doc-noteref"&gt;1&lt;/a&gt;&lt;/sup&gt; Almost nobody leaves it there, and nobody agrees on what to use instead. Red Hat&amp;rsquo;s OpenJDK images shipped 50 % for years, then moved to 80 %.&lt;sup id="fnref:2"&gt;&lt;a href="#fn:2" class="footnote-ref" role="doc-noteref"&gt;2&lt;/a&gt;&lt;/sup&gt; Plenty of guides say 75 %.&lt;sup id="fnref:3"&gt;&lt;a href="#fn:3" class="footnote-ref" role="doc-noteref"&gt;3&lt;/a&gt;&lt;/sup&gt; Same problem, same JVM, four different recommendations and none of which account for the actual memory behavior of your application.&lt;/p&gt;</description></item></channel></rss>