https://frn.sh/Recent content in frn.sh on Fernando SimõesHugoen-USCopyright © Fernando Simões.Wed, 09 Sep 2026 00:00:00 +0000https://frn.sh/go-heap/Wed, 09 Sep 2026 00:00:00 +0000https://frn.sh/go-heap/The case: a cgroup running two processes with memory.max set to 900 MiB. The main process is a Go program with a baseline RSS of around 32 MiB. The other, a neighboring HTTP server, uses ~400 MiB (without spikes). The Go process spikes to 500+ MiB on io.ReadAll and proto.Unmarshal, which trigger an OOM kill. I had an idea: what if I set memory.high to 700 MiB and use a swap backend so the kernel can push anonymous pages during spikes?https://frn.sh/swap/Tue, 08 Sep 2026 00:00:00 +0000https://frn.sh/swap/I recently ran into a problem with cgroup running two processes, with memory.max set to 900 MiB. The main process is a Go program with a baseline RSS of around 32 MiB; the other, a neighboring HTTP server, uses ~400 MiB. The problem was that, randomly through the day, the Go process would experience a massiv spike in anonymous memory, growing from 32 MiB to 500+ MiB, which triggered an OOM kill.https://frn.sh/io-uring/Mon, 31 Aug 2026 00:00:00 +0000https://frn.sh/io-uring/Note: Most of this post is me having fun with something that doesn’t run in production. I wrote it for myself and mostly to play around with io_uring and some kernel features I’ve never messed with before - I/O merging and cache misses. Someone opened a PR to implement readahead in Turso. It was a throwaway implementation, but a good excuse to measure io_uring and understand more about it. Turso has two backends.https://frn.sh/pgfsync/Sat, 18 Jul 2026 00:00:00 +0000https://frn.sh/pgfsync/DRAFT Take a look at this wait-event table: wait_event_type | wait_event | coun ----------------+---------------+------- LWLock | WALWrite | 1193 IO | DataFileRead | 194 IO | DataFileWrite | 4 Lock | frozenid | 2 IO | WalSync | 1 1193 backends on WALWrite made no sense at all. This was a Postgres whose normal workload barely wrote anything. IOPS had exhausted a few hours earlier. Since writes seemed to be bonking the database, I needed to understand why.https://frn.sh/tforks/Thu, 11 Dec 2025 00:00:00 +0000https://frn.sh/tforks/One of the servers was hitting 90% of CPU utilization. A few containers running, no alerts. I ssh’ed and found a process with cmd bash startup.sh that had been running for 28 minutes. I straced it for a few minutes: % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 75.36 52.698676 390 134819 26094 wait4 12.27 8.583416 78 108725 fork 7.42 5.190671 5 926332 rt_sigprocmask 2.69 1.https://frn.sh/sigterm/Tue, 08 Apr 2025 00:00:00 +0000https://frn.sh/sigterm/A kernel mystery I hit today: load average at 12 on a 2 vCPU machine during a production incident. Linux load average counts three things: processes running on a CPU, processes waiting in the run queue, and processes in uninterruptible sleep - D state. From the kernel source: The global load average is an exponentially decaying average of nr_running + nr_uninterruptible. Regular sleep doesn’t count, so if load average says 12, those 12 were either running, runnable, or in D.