CGROUP
Platform Ops OS Linux Advanced
Issue #055 · September 2026

LINUX ADVANCED

systemd · Kernel Tuning · Namespaces & Cgroups · Profiling · LVM

The exact primitives Kubernetes and Docker are built on top of. Understand namespaces and cgroups here, and "how does a container actually work" stops being magic.

15
Concepts Covered
2
of 4 Linux Resources
v2
Cgroups
systemd3
UnitsjournaldCustom Services
Kernel & Sysctl3
/proc/sysNet TuningVM Tuning
Namespaces & Cgroups3
7 NamespacesCgroups v2Containers
Profiling3
straceperfiostat/vmstat
LVM & Storage3
PV/VG/LVSnapshotsext4/XFS/Btrfs
systemd Unitsjournalctlsysctlnet.core.somaxconnPID NamespaceCgroups v2strace / perfFlame GraphsLVM SnapshotsXFS / Btrfs systemd Unitsjournalctlsysctlnet.core.somaxconnPID NamespaceCgroups v2strace / perfFlame GraphsLVM SnapshotsXFS / Btrfs

FROM INIT TO CONTAINER PRIMITIVES

Five layers under the hood — where systemd manages the machine, and namespaces/cgroups quietly became the foundation of every container runtime.

🔴 systemd
Unit Files
Targets
journald
Dependencies
Timers
🟠 Kernel/Sysctl
/proc/sys
Net Params
VM Params
sysctl.conf
Swappiness
🔵 Namespaces
PID / NET / MNT
UTS / IPC
User / Cgroup
Cgroups v2
unshare/chroot
🟢 Profiling
strace/ltrace
perf
Flame Graphs
iostat/vmstat
sar
🟣 LVM/Storage
PV / VG / LV
Resize Online
Snapshots
ext4/XFS
Btrfs
Deep-Dive

ADVANCED REFERENCE

Click any layer to explore concepts, commands, and production-tested guidance.

SYSTEMD DEEP-DIVE
The init system that boots, supervises, and logs almost everything on the box
3 Concepts
⚙️
Units, Targets & Dependencies
Everything systemd manages — services, mounts, sockets, timers — is a "unit." Targets group units, like old-school runlevels but composable.
Must Know
Must Know
Unit TypeManages
.serviceA long-running process (nginx, sshd)
.socketA network/Unix socket, can lazily start its service
.timerScheduled activation — systemd's answer to cron
.mountA filesystem mount point
.targetA synchronization point / group of units (e.g. multi-user.target)
Commands
systemctl
systemctl list-dependencies nginx
systemctl get-default # current default target
📓
journalctl & Log Management
systemd's binary log store — structured, indexed, and queryable in ways plain text files in /var/log never were.
Important
Important
journalctl
journalctl -u nginx --since "1 hour ago"
journalctl -f # follow, like tail -f
journalctl -p err -b # errors since last boot
journalctl --disk-usage
🔵Set SystemMaxUse=500M in /etc/systemd/journald.conf — unbounded journals can fill the root disk
✍️
Writing Custom systemd Services
Turning any script or binary into a properly supervised, restartable, boot-enabled service.
Practical
Recommended
/etc/systemd/system/billing-worker.service
unit file
[Unit]
Description=Billing background worker
After=network.target
[Service]
ExecStart=/usr/local/bin/billing-worker
Restart=on-failure
User=billing
[Install]
WantedBy=multi-user.target
activate
systemctl daemon-reload && systemctl enable --now billing-worker
KERNEL PARAMETERS & SYSCTL
Tuning the kernel's behavior without recompiling anything
3 Concepts
🎛️
/proc/sys and sysctl Basics
The kernel exposes thousands of tunable parameters as virtual files — sysctl is just a friendlier way to read and write them.
Must Know
Must Know
sysctl
sysctl vm.swappiness # read one value
sysctl -w vm.swappiness=10 # set, until reboot
echo "vm.swappiness=10" >> /etc/sysctl.d/99-tuning.conf
sysctl --system # apply all files, persists across reboots
🌐
Network Kernel Tuning
The parameters that matter under real load — connection backlog, TIME_WAIT reuse, and ephemeral port range.
Important
Important
ParameterEffect
net.core.somaxconnMax queued connections per listening socket — raise for high-throughput services
net.ipv4.tcp_tw_reuseAllows reusing TIME_WAIT sockets for new connections
net.ipv4.ip_local_port_rangeWidens the ephemeral port pool — matters for high-connection-count services
net.core.rmem_max / wmem_maxMax socket buffer sizes — affects throughput on fast networks
🧠
Memory & VM Tuning
Swappiness and overcommit behavior — two settings that quietly decide how a memory-pressured box behaves.
Tuning
Recommended
Key Parameters
🔵vm.swappiness (0-100) — lower means the kernel prefers dropping caches over swapping; on DB servers, set low (1-10)
🔵vm.overcommit_memory — controls whether the kernel allows allocating more memory than physically exists
Rule of Thumb
1
Database/cache workloads: low swappiness, they'd rather OOM than swap and stall
2
General app servers: default (60) is usually fine — don't tune without a measured reason
NAMESPACES & CGROUPS
The two kernel features that make "container" a meaningful word
3 Concepts
🧩
The Seven Linux Namespaces
Namespaces give a process its own isolated view of a global resource — PIDs, network interfaces, mounts, and more.
Must Know
Must Know
NamespaceIsolates
PIDProcess IDs — a container's PID 1 isn't the host's PID 1
NETNetwork interfaces, routing tables, ports
MNTMount points — a container's filesystem view
UTSHostname and domain name
IPCInter-process communication (shared memory, semaphores)
USERUser/group ID mapping — root in a container ≠ root on host
CGROUPCgroup root directory view
📊
Cgroups v2 & Resource Limits
If namespaces control what a process can see, cgroups control what it can use — CPU, memory, I/O bandwidth, all metered and capped.
Important
Important
cgroups v2
cat /sys/fs/cgroup/cgroup.controllers
systemd-cgtop # live resource usage per cgroup, like top
# memory.max, cpu.max, io.max — the limits that Docker's --memory/--cpus set under the hood
📦
How Containers Actually Work
A "container" is namespaces + cgroups + a chroot'd filesystem, wrapped in tooling. Prove it to yourself with the raw primitives.
Demo
Recommended
Build a "container" by hand
unshare
unshare --pid --net --mount --uts --fork --mount-proc bash
# new PID/network/mount/hostname namespace, PID 1 inside
hostname sandbox && ps aux # only sees its own processes
🔵This is, roughly, what containerd/runc does under Docker/Kubernetes — plus image layers and a lot of tooling
PERFORMANCE PROFILING
Stop guessing what's slow — measure it
3 Concepts
🔬
strace & ltrace
See exactly which syscalls (strace) or library calls (ltrace) a process makes — the ground truth when "it's slow" needs an actual answer.
Must Know
Must Know
strace
strace -c -p 4821 # summary of syscall time, attach to running PID
strace -T -e trace=network myapp # time each network syscall
🔥
perf & Flame Graphs
Sampling profiler built into the kernel — turns "which function is burning CPU" into a picture instead of a guess.
Important
Important
perf
perf top # live, like top but for CPU-hot functions
perf record -F 99 -p 4821 -g -- sleep 30
perf script | stackcollapse-perf.pl | flamegraph.pl > out.svg
📈
iostat/vmstat/sar — the Classic Toolkit
Before reaching for perf, these three answer 80% of "what's the bottleneck" questions in seconds.
Toolkit
Recommended
the classics
vmstat 2 # CPU, memory, swap, every 2s
iostat -xz 2 # per-disk utilization & latency
sar -n DEV 2 # network throughput per interface
STORAGE: LVM & ADVANCED FILESYSTEMS
Resizing a live disk without downtime — and the filesystems built for it
3 Concepts
🧱
LVM Concepts (PV/VG/LV)
A flexible layer between raw disks and filesystems — resize, extend, and snapshot without unmounting anything.
Must Know
Must Know
The Three Layers
🔵PV (Physical Volume) — a raw disk or partition
🔵VG (Volume Group) — a pool combining one or more PVs
🔵LV (Logical Volume) — the resizable "partition" carved from a VG, this is what gets formatted
Setup
lvm
pvcreate /dev/sdb
vgcreate data-vg /dev/sdb
lvcreate -L 100G -n data-lv data-vg
📐
Resizing & Snapshots
The two operations that make LVM worth the extra layer of abstraction — grow a volume live, or freeze a point-in-time copy.
Important
Important
resize + snapshot
# grow the LV, then the filesystem on top, no downtime
lvextend -L +50G /dev/data-vg/data-lv
resize2fs /dev/data-vg/data-lv # ext4
# point-in-time snapshot before a risky migration
lvcreate -L 10G -s -n data-snap /dev/data-vg/data-lv
🗄️
ext4 vs XFS vs Btrfs
The filesystem layered on top of the LV — each with a different sweet spot.
Decision
Recommended
FilesystemBest ForNotes
ext4General purpose, default on most distrosMature, predictable, well-understood failure modes
XFSLarge files, high-throughput workloadsDefault on RHEL; excellent parallel I/O; can't shrink
BtrfsSnapshots, checksums, built-in RAID-like featuresMore moving parts; used by default on some SUSE/Fedora setups
Decision Guide

strace, perf, OR THE CLASSICS?

A quick lookup for which profiling tool actually answers your question.

QuestionToolWhy
"Which syscall is this process stuck on?"straceShows every syscall in real time, including blocking ones
"Which function is burning CPU?"perfSampling profiler, low overhead, gives you a flame graph
"Is this a CPU, memory, or disk problem?"vmstat / iostatFastest first-pass triage before reaching for heavier tools
"Is the network the bottleneck?"sar -n DEVPer-interface throughput over time

COMMAND CHEATSHEET

systemd
systemctl daemon-reload
systemctl list-units --failed
journalctl -xe
Kernel / Sysctl
sysctl -a | grep net.core
sysctl --system
Namespaces / Cgroups
lsns
systemd-cgtop
unshare --pid --fork bash
Profiling
perf top
strace -c -p PID
vmstat 2
LVM
lvs / vgs / pvs
lvextend -L +10G /dev/vg/lv
resize2fs /dev/vg/lv
General
lscpu
free -h
uptime
VA
Vishal Abhinav
Platform Ops Engineer · Ops Newsletter — Issue #055