<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Profiling on Lorbic</title><link>http://localhost:1313/tags/profiling/</link><description>Recent content in Profiling on Lorbic</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 12 Jan 2026 00:12:45 +0530</lastBuildDate><atom:link href="http://localhost:1313/tags/profiling/index.xml" rel="self" type="application/rss+xml"/><item><title>Go Garbage Collector Mechanics: Pacer, GOGC, and Allocation Latency</title><link>http://localhost:1313/dont-take-out-the-garbage-go-gc-deep-dive/</link><pubDate>Wed, 07 Jan 2026 00:21:12 +0530</pubDate><guid>http://localhost:1313/dont-take-out-the-garbage-go-gc-deep-dive/</guid><description>&lt;p>In the world of high-throughput backend services, we often obsess over the usual suspects of performance: database indexing, network latency, and algorithmic complexity. But recently, while debugging our core gateway service (&lt;code>backend-gw&lt;/code>), I encountered a bottleneck that defied standard logic.&lt;/p>
&lt;p>The service was &lt;strong>CPU-bound&lt;/strong>, yet active heap usage was surprisingly low (~200MB). P99 latency was spiking at random intervals, but database queries were returning in milliseconds.&lt;/p>
&lt;p>The culprit was not the business logic. It was &lt;strong>memory management&lt;/strong>. I was effectively running a Denial-of-Service attack on my own runtime.&lt;/p></description></item></channel></rss>