The latest articles on DEV Community by reloading (@reloading). https://dev.to/reloading https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4095480%2F730bb945-4605-4f7f-aaf3-9da71eea432a.png https://dev.to/reloading en reloading Wed, 26 Aug 2026 10:00:39 +0000 https://dev.to/reloading/358-mb-rss-52-mb-live-heap-where-the-rest-went-mn6 https://dev.to/reloading/358-mb-rss-52-mb-live-heap-where-the-rest-went-mn6 <p>I was debugging a Rust service that had about 52 MB of live allocations but was sitting at 358 MB RSS.</p> <p>I expected allocator fragmentation or retained pages. The actual cause was Transparent Huge Pages interacting with jemalloc and the allocation pattern of the workload.</p> <p>Changing THP from <code>always</code> to <code>madvise</code> dropped RSS from 358 MB to 87 MB, with no application changes.</p> <p>I wrote up the debugging process, including the allocator stats, <code>smaps_rollup</code>, and the THP setting that finally explained it:</p> <p><a href="https://certstream.dev/blog/jemalloc-transparent-huge-pages-rss.html" rel="noopener noreferrer">https://certstream.dev/blog/jemalloc-transparent-huge-pages-rss.html</a></p> rust linux performance memory