<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Memory on Linux Security</title><link>https://linuxtransfer.com/tags/memory/</link><description>Recent content in Memory on Linux Security</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 29 Oct 2026 08:32:57 +0200</lastBuildDate><atom:link href="https://linuxtransfer.com/tags/memory/index.xml" rel="self" type="application/rss+xml"/><item><title>Tracing a Sudden Drop‑in‑Memory Spike with journalctl and systemd‑coredump logs</title><link>https://linuxtransfer.com/post/2026-10-29-tracing-a-sudden-dropinmemory-spike-with-jour/</link><pubDate>Thu, 29 Oct 2026 08:32:57 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-10-29-tracing-a-sudden-dropinmemory-spike-with-jour/</guid><description>&lt;h2 id="sudden-memory-spike-use-journalctl--systemdcoredump-to-pin-it-down">Sudden Memory Spike? Use journalctl + systemd‑coredump to Pin It Down&lt;/h2>
&lt;p>When a server’s RAM jumps from 30 % to 90 % in a matter of minutes, the first instinct is to kill processes, restart services, or add more memory. Those are quick fixes, but they don’t tell you &lt;em>why&lt;/em> the spike happened. On a system that runs systemd, the combination of &lt;code>journalctl&lt;/code> and &lt;code>systemd‑coredump&lt;/code> gives a precise, timestamp‑aligned view of what went wrong. This post walks through a real‑world scenario, shows how to extract the relevant logs, and explains how to interpret the data so you can fix the root cause and harden the system against future incidents.&lt;/p></description></item></channel></rss>