-
内存明明宽裕服务却偶发卡顿:一次 Linux swap 与 swappiness 排查复盘
一个 Java 服务跑在 32G 内存的机器上,偶发卡顿几百毫秒到一秒多,可 CPU 闲着、free 还显示 8G 空闲内存,而 swap 却用掉了 2.3G。排查梳理:swap 不是内存的备用油箱不是内存满了才用,内核内存够时也会主动把很久没访问的冷页换出去,这是为多留文件缓存做的主动内存管理;判断 swap 要不要紧看 vmstat 的 si/so 换入换出流量而非 free 里 used 的…- 0
- 0
-
服务进程凭空消失日志却干净:一次 Linux OOM Killer 排查复盘
一个跑在 8G 内存机器上的 Java 服务毫无征兆地消失,进程没了端口不通,可应用日志干干净净,在某行业务日志中间硬断,没有任何异常栈。排查梳理:进程不是自己崩的,是内核里的 OOM Killer 在内存耗尽时强行杀的;它用 SIGKILL 不可捕获,进程没机会写遗言所以应用日志才是空的,真相在 dmesg 的 Out of memory 行里;看内存余量要看 available 不是 free…- 0
- 0
-
服务进程半夜凭空消失:一次 Linux OOM Killer 排查复盘
一个 Java 服务隔三差五进程凭空消失,ps 找不到,应用日志最后一行戛然而止没有任何异常。排查梳理:进程无声消失且日志没遗言极可能是被 SIGKILL 杀的,真凶是内核内存耗尽时的 OOM Killer;dmesg -T 与 journalctl -k 找 killed process 铁证、读懂 OOM 时的进程内存排行表;oom_score 决定杀谁、oom_score_adj 给关键进程…- 0
- 0
-
服务半夜凭空消失日志却很干净:一次 Linux 内存与 OOM Killer 排查复盘
一个 Java 服务半夜进程凭空消失,端口也没了,应用日志结尾却平静得反常、没有半个字的报错。排查梳理:凶手不在应用日志在内核日志、dmesg 里找 OOM Killer、free 看 available 不看 free、buff/cache 是内核借用的缓存、swap 是内存的备胎与变慢预警、OOM Killer 挑占内存最多的进程下手、overcommit 与 swappiness 两个内核参…- 0
- 0
-
核心服务凌晨被处决:一次 Linux 内存与 OOM Killer 排查复盘
核心服务凌晨 4 点凭空消失,应用日志却干干净净。排查梳理:dmesg 里的 OOM Killer 实锤、free 各列与该看的 available、OOM Killer 按 oom_score 选受害者、用 ps --sort=-%mem 揪出内存真凶、swap 与 swappiness、用 systemd MemoryMax 给每个服务设内存上限,以及一套内存排查纪律。- 0
- 0
-
内存被吃光了?——一次 Linux 内存使用率排查复盘
监控告警内存使用率 95%,差点扩容,一个 free -h 发现绝大部分是 buff/cache。排查梳理:free 每一列的含义、为什么该看 available 而非 free、used 高不等于危险、RSS 与 VSZ 之别、swap 与 swappiness、page cache 与 drop_caches 的误区,以及怎么区分假告警与真泄漏。- 0
- 0
内存
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×