Page 5 - Linux

A memory leak first shows up as a steadily growing RES value in top, followed by ever tighter free memory and eventually an OOM kill in the middle of the day. Simply restarting the affected service buys time, not insight. This guide shows how to use built-in tools like smaps_rollup, smem and pmap to systematically find out which process is losing memory and where in the code or configuration the cause lies.

Anyone who wants to systematically solve network problems on a Linux server needs a clear understanding of interfaces, routing and name resolution. This article explains how ip addr and ip link manage interfaces, how the routing table works with ip route, how resolv.conf and nsswitch.conf control DNS, and the fixed order in which connectivity failures can reliably be narrowed down.

An overloaded web server is rarely down to application code alone. More often, it comes down to mismatched operating system limits and undersized PHP-FPM pools that collapse under real traffic. This article shows, in practical terms, how to correctly size Nginx worker processes, file descriptor limits, the TCP backlog, and pm.max_children based on the memory actually available, and how to back up every single change with real benchmark numbers instead of relying on guesswork.

nice and ionice only lower the priority of background jobs, but do not prevent them from briefly occupying entire cores. CPU pinning goes a step further: it reserves specific cores exclusively for PHP-FPM workers, while reindexing and cron are only allowed to run on other cores.

Anyone who randomly changes configurations and restarts services during an incident extends the downtime and leaves behind contradictory traces for the root cause analysis. A fixed process of availability verification, change comparison, resource checks, and systematic log analysis gets to the cause faster, produces traceable documentation for the postmortem, and makes clear when to escalate instead of digging alone indefinitely.

Docker containers are not magic and not lightweight virtual machines either, they are ordinary Linux processes that the kernel starts with a restricted view of processes, networking, and the filesystem through namespaces, while cgroups cap their resource usage. Understanding both mechanisms lets you inspect and reason about any running container directly from the host.

When the Linux kernel comes under memory pressure, the OOM killer decides within a split second which process must die, often the database or PHP-FPM pool instead of the actual memory hog. This article explains the oom_score calculation, shows how to trace OOM kills in dmesg and journalctl, and how to protect critical services through oom_score_adj and cgroup limits.

Load average shows three exponentially damped averages of the queue of runnable and blocked processes over one, five, and fifteen minutes. Anyone judging the number solely against the core count often confuses CPU-bound with I/O-bound load. This guide explains the calculation, shows how to correctly read uptime and top, and provides clear diagnostic steps for daily practice.

OPcache is usually treated purely as a PHP setting, yet its effectiveness depends directly on the underlying Linux filesystem. Inode behavior, mount options and network filesystems such as NFS can make the exact same OPcache configuration reliable on one server and unusable on another.

On multi-core servers, network card interrupts without deliberate IRQ affinity often all land on the same CPU core, while the remaining cores stay uninvolved. Under high packet rates, that one core becomes a bottleneck long before the server's overall CPU utilization is anywhere near exhausted.