{"id":1216,"date":"2026-09-24T22:33:58","date_gmt":"2026-09-24T22:33:58","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1216"},"modified":"2026-09-24T22:33:58","modified_gmt":"2026-09-24T22:33:58","slug":"profiling-cpu-hotspots-perf-flamegraphs-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/profiling-cpu-hotspots-perf-flamegraphs-vps\/","title":{"rendered":"Finding CPU Hotspots on a Small VPS with perf and Flamegraphs"},"content":{"rendered":"\n

top<\/code> shows a process at 100% CPU and tells you nothing about which function is burning it. That is the gap perf<\/code> and flamegraphs close: instead of sampling at the process level, they sample at the instruction level and aggregate the samples into a single visual tree where the widest frames are the hottest code paths. This walkthrough builds that workflow on a small VPS, from installing perf<\/code> to reading a flamegraph for the first time.<\/p>\n\n\n\n

Installing perf and verifying it works<\/h2>\n\n\n\n

perf<\/code> ships with the kernel tools package. On Debian and Ubuntu the package is linux-tools<\/code> and it must match your running kernel version, which is the first place people get stuck.<\/p>\n\n\n\n

# Debian \/ Ubuntu\napt update\napt install -y linux-tools-common linux-tools-$(uname -r) linux-cloud-tools-$(uname -r)\n\n# RHEL \/ Alma \/ Rocky\ndnf install -y perf\n\n# sanity check\nperf --version\nperf stat -e cycles true<\/code><\/pre>\n\n\n\n
If perf stat<\/code> reports Permission denied<\/code> or an empty result, check that kernel.perf_event_paranoid<\/code> is not too restrictive. Values above 2 block non-root sampling; setting it to 1 allows user-space profiling, which is what we need.<\/p>\n\n\n\n
sysctl kernel.perf_event_paranoid\n# allow user-space sampling (not persistent; add to \/etc\/sysctl.d\/ to keep)\nsysctl -w kernel.perf_event_paranoid=1<\/code><\/pre>\n\n\n\n
Sampling the right target on a small VPS<\/h2>\n\n\n\n
You do not profile the whole system. Profile the process that is busy, and choose the event that matches the symptom. Frequency of samples is a tradeoff: more samples give finer resolution but add overhead you must not ignore on a 1-2 vCPU instance.<\/p>\n\n\n\n
Goal<\/th>Command<\/th>Note<\/th><\/tr><\/thead>
Find CPU hot functions<\/td>perf record -F 99 -p PID -g -- sleep 30<\/code><\/td>99 Hz is the standard; 30s window<\/td><\/tr>
Whole-system profile<\/td>perf record -F 99 -a -g -- sleep 30<\/code><\/td>Higher overhead; use short windows<\/td><\/tr>
Count events only<\/td>perf stat -p PID sleep 10<\/code><\/td>Cheap; good for IPC and cache misses<\/td><\/tr>
Call graph depth<\/td>add --call-graph dwarf<\/code><\/td>Better stacks, larger files, more overhead<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
On a two-vCPU server, an -F 99<\/code> profile for thirty seconds costs well under one percent of a core. Avoid profiling for minutes at a time on a small instance; the perf ring buffer itself starts to compete for memory and cache. Short, targeted windows beat long, unfocused ones.<\/p>\n\n\n\n
Generating the flamegraph<\/h2>\n\n\n\n
FlameGraph scripts turn the perf.data<\/code> file into an SVG. Clone the tooling once, then the pipeline is three commands.<\/p>\n\n\n\n
git clone https:\/\/github.com\/brendangregg\/FlameGraph.git\n\n# 1. record\nperf record -F 99 -p $(pgrep -n php-fpm) -g -- sleep 30\n\n# 2. dump the stack samples\nperf script > out.perf\n\n# 3. fold and render\nFlameGraph\/stackcollapse-perf.pl out.perf > out.folded\nFlameGraph\/flamegraph.pl out.folded > flamegraph.svg<\/code><\/pre>\n\n\n\n
Copy the SVG to your laptop and open it in a browser. On a VPS with no desktop you can serve it over an existing nginx vhost or pull it down with scp<\/code>. The file is self-contained HTML-wrapped SVG, so a single scp<\/code> is all that is required.<\/p>\n\n\n\n
Reading a flamegraph correctly<\/h2>\n\n\n\n