性能排查

爱好曙光2 天前
linux·ebpf·延迟·性能排查·bpftrace
生产延迟尖刺排查:用 bpftrace 抓系统调用与调度延迟线上 Java 或 Go 服务 P99 从 12ms 变成 200ms,指标盘却很干净:CPU 40%,内存稳定,GC 正常,下游 RT 也没变。这种尖刺经常出在内核路径:线程被调度器挂起、futex 等待、或一次 fsync 卡住写路径。bpftrace 能在不改代码、几乎不增加负载的前提下,把这些事件按进程和堆栈捞出来。
祥Sir的SRE笔记3 天前
linux·面试·性能优化·dba·sre·故障定位·性能排查
CPU 100% 不一定是故障:压测打满、业务饱和、突变打满的判断与排查前言"CPU 飙到 100% 怎么排查"是 SRE 面试的必考题,但十个候选人八个开口就是工具连招:top、vmstat、iostat、pidstat、perf——报得挺顺,方向全错。本文先拆掉"CPU 100% = 故障"这个隐含前提,给出三种性质的定性判断,再按 us/sy/wa/si 四分法展开每一条排查命令的实际用法,最后附一个最邪门的真实案例:sys 90%、strace/iostat/数据库视图全部干净,根因是大内存进程 fork 触发的内核页表锁竞争。
Starry-sky(jing)21 天前
linux·内核·服务器运维·soft lockup·性能排查
watchdog: BUG: soft lockup - CPU#3 stuck for 22s! 怎么排查——从寄存器 dump 到自旋锁争用根因你的服务器 dmesg 里反复冒出这一行:机器要么卡住几十秒、SSH 敲不进去,要么直接重启。你去搜中文答案,十篇有八篇叫你 sysctl kernel.watchdog_thresh=30 把阈值调大。调完报错确实少了,但下一次它不打招呼,直接变成 Hard LOCKUP panic。
我是有底线的