-
GC 语言也会内存泄漏:Python 服务被 OOM 反复杀死的排查
一个稳稳跑了好几个月的数据处理服务,突然开始被 OOM Killer 反复杀死:重启,过几小时,又被干掉。盯着监控曲线看,那条内存线像爬楼梯一样只涨不跌,撞到上限被杀、清零、再爬。这是教科书级的内存泄漏症状——可这是 Python,一门带垃圾回收的语言,怎么还会漏?几天排查下来真相平淡得让人脸热:漏的不是解释器,正是我们自己的代码。一个图省事的可变默认参数、一个只进不出的全局缓存字典、再加几处循环…- 2
- 0
-
Go time.After 在 for-select 循环里每秒 5 万次的内存泄漏 3 天复盘:18 小时准时 OOM + ticker / NewTimer.Reset / Go 1.23 三套正解
event-fanout 服务跑 18 小时稳定 OOM,goroutine 不泄漏 channel 不堆积,heap profile 显示 time.NewTimer 占 63% 分配。根因是 for-select 里 time.After(30s) 每秒触发 5 万次,稳态留 150 万个未到期 timer。本文讲清 time.After 的 runtime 行为、3 种修法、Go 1.23 …- 3
- 0
-
Java 线程池配置完全指南:从一次"线程池把服务拖到 OOM"看懂为什么不能用 Executors
2023 年我给一个订单服务加异步处理下单成功后要发通知写审计流水更新统计报表这些事都不该卡住下单这条主流程我决定把它们丢给一个线程池在后台异步做第一版我做得很顺手一行 Executors.newFixedThreadPool 拿到一个 10 线程的池子业务里需要异步的地方任务 submit 进去就不管了本地我测了测任务都正常执行完了我心里很笃定线程池嘛就是设一个线程数我把任务交给它它就用那几个线…- 3
- 0
-
JVM 内存与 GC 完全指南:从一次半夜 OOM 告警看懂堆内存怎么排查
2023 年的一个凌晨两点,我被告警电话叫醒:一个核心 Java 服务被系统 OOM Killer 杀掉了。重启、又挂、再重启,堆内存像一条笔直的斜线一路往上爬,涨到顶就崩。我第一反应是"流量涨了内存不够",准备提工单扩容——幸好在提单之前先把堆 dump 下来看了一眼:堆里 80% 的空间被一个 static HashMap 占着,塞了几百万个对象,一个都没被清理。这根本不是…- 7
- 0
-
进程半夜无声消失:一次 Linux OOM Killer 排查复盘
一个 Java 订单服务在凌晨 3 点突然消失被守护脚本拉起,应用日志干净地停在一条正常业务日志后再无任何异常堆栈,像被一枪打死连哼都没哼。排查梳理:进程消失分自己崩和被他杀两类,被杀的证据不在应用日志里要去看内核日志;OOM Killer 用 SIGKILL 杀进程这个信号无法被捕获,所以进程没机会打任何遗言,日志干净到毫无征兆恰恰是被偷袭的特征;dmesg -T 看 killed proces…- 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 两个内核参…- 2
- 0
-
核心服务凌晨被处决:一次 Linux 内存与 OOM Killer 排查复盘
核心服务凌晨 4 点凭空消失,应用日志却干干净净。排查梳理:dmesg 里的 OOM Killer 实锤、free 各列与该看的 available、OOM Killer 按 oom_score 选受害者、用 ps --sort=-%mem 揪出内存真凶、swap 与 swappiness、用 systemd MemoryMax 给每个服务设内存上限,以及一套内存排查纪律。- 2
- 0
-
服务进程隔几天就消失:一次 Linux 进程与信号排查的复盘
后台服务隔几天就凭空消失一次,应用日志最后一行却干干净净,没有任何报错。一个进程的死法远不止"自己崩溃":被信号杀、被 OOM Killer 处决、被父进程带走。排查梳理:ps/pstree 看进程、读懂 STAT 状态、信号与退出码 137、dmesg 找 OOM、systemd 自愈兜底。- 0
- 0
-
线程池踩坑:无界队列把堆撑爆,一次 OOM 宕机的复盘
活动高峰服务反复 OOM 宕机,dump 分析发现一个线程池队列里堆了三百多万个任务,几个 G 的堆全被它占满。罪魁是 Executors.newFixedThreadPool 默认的无界队列。几天治理:显式构造 ThreadPoolExecutor、有界队列、拒绝策略产生背压、按业务隔离线程池、补齐 7 类监控指标。- 0
- 0
OOM
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×