<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Performance on Samuel Matildes - Knowledge Base</title><link>https://docs.matildes.dev/tags/performance/</link><description>Recent content in Performance on Samuel Matildes - Knowledge Base</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 26 May 2026 14:15:13 +0100</lastBuildDate><atom:link href="https://docs.matildes.dev/tags/performance/index.xml" rel="self" type="application/rss+xml"/><item><title>How to Troubleshoot Linux Performance — Field Playbook</title><link>https://docs.matildes.dev/linux/admin/linux-performance-playbook/</link><pubDate>Tue, 19 May 2026 00:00:00 +0000</pubDate><guid>https://docs.matildes.dev/linux/admin/linux-performance-playbook/</guid><description>&lt;p&gt;&lt;i class="fas fa-tachometer-alt" aria-hidden="true"&gt;&lt;/i&gt; A field-ready reference for Linux performance investigations — keep it open in a second terminal.&lt;/p&gt;
&lt;h2 id="how-to-use-this-playbook"&gt;How to use this playbook&lt;a class="td-heading-self-link" href="#how-to-use-this-playbook" aria-label="Heading self-link"&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Linux performance problems split cleanly into &lt;strong&gt;two very different investigations&lt;/strong&gt;, and picking the wrong one wastes hours:&lt;/p&gt;
&lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;Situation&lt;/th&gt;
 &lt;th&gt;Track&lt;/th&gt;
 &lt;th&gt;What you do&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;The problem is happening &lt;strong&gt;right now&lt;/strong&gt; (or you can reproduce it on demand)&lt;/td&gt;
 &lt;td&gt;&lt;strong&gt;Track A — Live Triage&lt;/strong&gt;&lt;/td&gt;
 &lt;td&gt;Interactive tools, sample at 1s intervals, follow the bottleneck&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;The problem is &lt;strong&gt;intermittent / random&lt;/strong&gt; (happens overnight, once a week, only under load you can&amp;rsquo;t reproduce)&lt;/td&gt;
 &lt;td&gt;&lt;strong&gt;Track B — Background Collection&lt;/strong&gt;&lt;/td&gt;
 &lt;td&gt;Arm continuous loggers &lt;em&gt;before&lt;/em&gt; the next occurrence, then mine the logs afterwards&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
&lt;/table&gt;
&lt;div class="kb-callout kb-callout--rule"&gt;
 &lt;div class="kb-callout__title"&gt;
 &lt;i class="fas fa-bullseye" aria-hidden="true"&gt;&lt;/i&gt;
 &lt;span&gt;Rule of thumb&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="kb-callout__body"&gt;
 If you can&amp;rsquo;t reproduce it, &lt;strong&gt;do not&lt;/strong&gt; keep staring at &lt;code&gt;top&lt;/code&gt;. Stop, deploy collectors, walk away, and analyse later. Otherwise you&amp;rsquo;ll miss the event every single time.
 &lt;/div&gt;
&lt;/div&gt;

&lt;p&gt;&lt;img src="https://docs.matildes.dev/linux/admin/linux-performance-playbook/workflow.png" alt="Decision flow: live triage vs. background collection"&gt;&lt;/p&gt;</description></item><item><title>Before You Scale: Why Software Optimization Beats Hardware Every Time</title><link>https://docs.matildes.dev/software-engineering/memory-optimization/</link><pubDate>Mon, 02 Feb 2026 00:00:00 +0000</pubDate><guid>https://docs.matildes.dev/software-engineering/memory-optimization/</guid><description>&lt;p&gt;&lt;i class="fas fa-microchip" aria-hidden="true"&gt;&lt;/i&gt; Before You Scale: Why Software Optimization Beats Hardware Every Time&lt;/p&gt;
&lt;h2 id="summary"&gt;Summary&lt;a class="td-heading-self-link" href="#summary" aria-label="Heading self-link"&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;When your application crashes with an Out-of-Memory (OOM) error, the instinctive response is often: &amp;ldquo;Let&amp;rsquo;s add more RAM.&amp;rdquo; In the age of cloud computing where resources are just a slider away, this approach has become the default. But what if I told you that a 30-minute code investigation could reduce your memory usage by &lt;strong&gt;95%&lt;/strong&gt;—turning a 3GB memory spike into 150MB?&lt;/p&gt;</description></item><item><title>Understanding IO Delays in Linux - Performance Testing with io-delayer</title><link>https://docs.matildes.dev/linux/admin/io-delayer-performance-testing/</link><pubDate>Wed, 07 Jan 2026 00:00:00 +0000</pubDate><guid>https://docs.matildes.dev/linux/admin/io-delayer-performance-testing/</guid><description>&lt;p&gt;
 &lt;a href="https://github.com/samatild/io-delayer" target="_blank" rel="noopener"&gt;
 &lt;i class="fab fa-github" aria-hidden="true"&gt;&lt;/i&gt; GitHub
 &lt;/a&gt;
 &amp;nbsp;•&amp;nbsp;
 &lt;a href="https://pypi.org/project/tuxtoaster" target="_blank" rel="noopener"&gt;
 &lt;i class="fab fa-linux" aria-hidden="true"&gt;&lt;/i&gt; Linux Kernel Module
 &lt;/a&gt;
&lt;/p&gt;
&lt;p&gt;&lt;i class="fas fa-clock" aria-hidden="true"&gt;&lt;/i&gt; Simulate and analyze IO performance degradation at multiple kernel layers to understand system bottlenecks.&lt;/p&gt;
&lt;h2 id="why-io-delays-matter-in-system-performance"&gt;Why IO Delays Matter in System Performance&lt;a class="td-heading-self-link" href="#why-io-delays-matter-in-system-performance" aria-label="Heading self-link"&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Input/Output operations form the backbone of system performance, yet they represent one of the most complex and often misunderstood aspects of Linux performance engineering. When applications experience slowdowns, the root cause frequently traces back to IO delays introduced at various kernel layers.&lt;/p&gt;</description></item><item><title>How to Benchmark Linux with Tux Toaster</title><link>https://docs.matildes.dev/linux/admin/benchmarking-with-tuxtoaster/</link><pubDate>Fri, 17 Oct 2025 00:00:00 +0000</pubDate><guid>https://docs.matildes.dev/linux/admin/benchmarking-with-tuxtoaster/</guid><description>&lt;p&gt;
 &lt;a href="https://github.com/samatild/tuxtoaster" target="_blank" rel="noopener"&gt;
 &lt;i class="fab fa-github" aria-hidden="true"&gt;&lt;/i&gt; GitHub
 &lt;/a&gt;
 &amp;nbsp;•&amp;nbsp;
 &lt;a href="https://pypi.org/project/tuxtoaster" target="_blank" rel="noopener"&gt;
 &lt;i class="fab fa-python" aria-hidden="true"&gt;&lt;/i&gt; PyPI
 &lt;/a&gt;
 &amp;nbsp;
&lt;/p&gt;
&lt;p&gt;&lt;i class="fas fa-tachometer-alt" aria-hidden="true"&gt;&lt;/i&gt; Benchmark smarter, not harder — with Tux Toaster.&lt;/p&gt;
&lt;h2 id="what-is-tux-toaster"&gt;What is Tux Toaster?&lt;a class="td-heading-self-link" href="#what-is-tux-toaster" aria-label="Heading self-link"&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://github.com/samatild/tuxtoaster"&gt;&lt;code&gt;Tux Toaster&lt;/code&gt;&lt;/a&gt; is an all-in-one performance toolkit for Linux. It triggers various load tests (&amp;ldquo;toasters&amp;rdquo;) to help you evaluate the performance and stability of your system across CPU, memory, disk, and network. It offers an interactive terminal menu with multi-select support and clear, stoppable workloads.&lt;/p&gt;</description></item><item><title>Understanding CPU Statistics in Linux (/proc/stat)</title><link>https://docs.matildes.dev/linux/kernel/cpu-statistics/</link><pubDate>Tue, 14 Jan 2025 00:00:00 +0000</pubDate><guid>https://docs.matildes.dev/linux/kernel/cpu-statistics/</guid><description>&lt;p&gt;&lt;i class="fas fa-microchip" aria-hidden="true"&gt;&lt;/i&gt; Kernel-Level CPU Time Accounting&lt;/p&gt;
&lt;h2 id="summary"&gt;Summary&lt;a class="td-heading-self-link" href="#summary" aria-label="Heading self-link"&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The Linux kernel maintains precise, per-CPU time accounting across ten distinct execution contexts. These statistics, exposed via &lt;code&gt;/proc/stat&lt;/code&gt;, represent cumulative jiffy counters (typically 1/100th or 1/1000th of a second) since system boot. Understanding these counters is essential for performance analysis, capacity planning, and diagnosing CPU contention, I/O bottlenecks, interrupt storms, and virtualization overhead.&lt;/p&gt;
&lt;h2 id="the-procstat-interface"&gt;The /proc/stat Interface&lt;a class="td-heading-self-link" href="#the-procstat-interface" aria-label="Heading self-link"&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;&lt;code&gt;/proc/stat&lt;/code&gt; is a virtual file provided by the kernel&amp;rsquo;s proc filesystem. It contains system-wide statistics aggregated across all CPUs and individual per-CPU lines. The format is non-blocking and updated atomically by the kernel scheduler&amp;rsquo;s tick handler.&lt;/p&gt;</description></item></channel></rss>