Quiz: Linux Kernel Tuning¶
6 questions
L1 (3 questions)¶
1. A production server is dropping incoming TCP connections under load. dmesg shows 'TCP: request_sock_TCP: Possible SYN flooding on port 443'. What sysctl parameters should you check first and why?
Show answer
Check net.ipv4.tcp_max_syn_backlog (SYN queue size), net.core.somaxconn (listen backlog), and net.ipv4.tcp_syncookies (SYN flood protection). If syncookies is 0, enable it. If backlogs are at defaults (128/1024), increase them to match the server's connection rate. Also verify the application's listen() backlog argument. *Common mistake:* Increase net.ipv4.ip_forward — this is for routing, not connection handling.2. After deploying a high-throughput application, you see 'nf_conntrack: table full, dropping packet' in the logs. What happened and how do you fix it?
Show answer
The conntrack table (used by iptables/nftables for stateful tracking) is exhausted. Check net.netfilter.nf_conntrack_max (default ~65536) and increase it. Also reduce timeouts for established connections (net.netfilter.nf_conntrack_tcp_timeout_established) if many are long-idle. Monitor with /proc/sys/net/netfilter/nf_conntrack_count. *Common mistake:* Restart the firewall service — this clears the table but drops all tracked connections and does not fix the root cause.3. What does net.core.rmem_max control and when would you increase it?
Show answer
rmem_max sets the maximum receive socket buffer size that applications can request. Increase it for high-bandwidth UDP receivers (metrics collectors, DNS servers, video streaming) or TCP connections with high bandwidth-delay product. Pair with rmem_default for the default buffer and net.ipv4.tcp_rmem for TCP auto-tuning range. *Common mistake:* This controls disk read-ahead buffers — that is actually blockdev --setra.L2 (3 questions)¶
1. You are tuning a database server for large file I/O. What is the difference between vm.dirty_ratio and vm.dirty_background_ratio, and what happens if you set dirty_ratio too high?
Show answer
dirty_background_ratio is the % of memory at which background writeback starts (asynchronous). dirty_ratio is the hard limit at which all processes block until writeback catches up (synchronous). Setting dirty_ratio too high allows massive dirty page accumulation — when the limit hits, all I/O stalls, causing latency spikes. Typical tuning: background 5-10%, ratio 20-40%. *Common mistake:* Set both to 0 to disable caching entirely — this would force synchronous writes for every operation, destroying throughput.2. A containerized Java application is being OOM-killed despite the JVM heap being well within limits. What kernel memory settings should you investigate?
Show answer
Check cgroup memory limits (memory.max in cgroup v2). JVM total memory = heap + metaspace + thread stacks + native memory + NIO buffers. The cgroup limit applies to all RSS, not just heap. Also check vm.overcommit_memory — if set to 2, the kernel may deny allocations before the cgroup limit. Increase the cgroup limit or reduce JVM non-heap consumption. *Common mistake:* Increase vm.swappiness — swap can delay OOM but cgroups enforce hard limits regardless of swap unless memory.swap.max is also increased.3. You need to make sysctl changes persistent across reboots. What are the standard files and precedence order?