-
一次对 Go slice 做切片后 append,意外覆盖了原始 slice 里的数据,让一份订单列表凭空窜了值:一次共享底层数组的深度复盘
只往一段子切片里 append 了几个元素,原始订单 slice 紧挨其后的数据却被莫名其妙改掉了。根因是 Go 的 slice 切片(s[0:3])不复制数据、和原 slice 共享同一底层数组,且子切片的 cap 到底层数组末尾、有剩余容量,append 便原地写入、覆盖了原 slice 的元素;而 cap 不够时 append 会扩容分配新数组、不影响原数组——故行为时灵时不灵、极难复现。本…- 7
- 0
-
容器设了 2GB 内存上限服务却反复被 OOMKilled、可 JVM 堆明明没满:JVM 不感知容器限制按宿主机算堆撑爆容器的避坑复盘
这是我们把一个老 Java 服务上容器时踩的第一个也是最懵的一个坑。我们把这个服务打成镜像部署到 K8s 给它的容器设了一个内存上限 2GB,我们估摸着这个服务平时也就用几百兆内存 2GB 绰绰有余了。可服务一启动跑不了多久就被 K8s 给 OOMKilled 因内存超限被杀了,杀了之后自动重启重启完跑一会又被杀如此反复陷入了 CrashLoopBackOff 崩溃重启循环根本起不来。我特别纳闷这…- 6
- 0
-
宿主机内存够却被 OOMKilled:容器 JVM 内存避坑
我们把一个 Java 服务容器化上了 K8s,给 Pod 配了 2GB 内存上限,本以为足够宽裕。可上线后容器三天两头重启,Pod 状态写得明明白白:OOMKilled、退出码 137。最费解的是这台宿主机有 64GB 内存空闲得很,进容器用 top、free 看显示的全是宿主机那 64GB 富得流油,可容器就是一次次以内存超限为由被处决。排查好一阵真相才浮出水面、经典得让人哭笑不得:我那个版本的…- 0
- 0
-
free -h 显示内存快满了是内存泄漏吗:一次 Linux 内存认知的复盘
一台 16G 内存的服务器跑着 Java 服务,free -h 一看 used 那列写着 15G,只剩 1G,我第一反应内存泄漏熬夜导堆分析,结果 Java 堆才 2G 很健康,所有进程内存加起来才 4G,中间那 10 多个 G 谁吃了。排查梳理:lsof 排除已删文件句柄,/proc/meminfo 看到 11G 在 Cached 页缓存,free -h 的 available 一列写着 13G…- 0
- 0
-
load 飙到 21 但 CPU 几乎空闲:一次 Linux swap 颠簸拖垮服务器的复盘
一台 4 核 8G 的应用服务器,服务慢到接口大量超时,SSH 登录卡、敲命令字一个个蹦。top 一看 load average 高达 21,可 CPU 的 us+sy 才 8%,iowait 却高达 63%——负载爆表,CPU 却闲着。free 显示物理内存 7.1G/7.6G 榨干、swap 2G 也用满,vmstat 的 si/so 两列持续几千在疯狂换页。排查梳理:load average…- 4
- 0
-
free 看内存只剩两百兆吓一跳:一次 Linux buff/cache 排查复盘
一台 16G 内存的服务器 free -m 看空闲只剩两百多兆,以为快 OOM 了,可所有进程 RSS 加起来才六七个 G,中间将近 10G 内存找不到是谁占的。排查梳理:free 命令输出的 free 那一列不是可用内存,它是纯粹没被任何用途碰过完全闲置的内存;available 那一列才是真正还能用的内存,等于 free 加上 buff/cache 里可回收的部分;那消失的内存跑去了 buff…- 0
- 0
-
内存明明宽裕服务却偶发卡顿:一次 Linux swap 与 swappiness 排查复盘
一个 Java 服务跑在 32G 内存的机器上,偶发卡顿几百毫秒到一秒多,可 CPU 闲着、free 还显示 8G 空闲内存,而 swap 却用掉了 2.3G。排查梳理:swap 不是内存的备用油箱不是内存满了才用,内核内存够时也会主动把很久没访问的冷页换出去,这是为多留文件缓存做的主动内存管理;判断 swap 要不要紧看 vmstat 的 si/so 换入换出流量而非 free 里 used 的…- 3
- 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 内存使用率排查复盘
监控告警内存使用率 95%,差点扩容,一个 free -h 发现绝大部分是 buff/cache。排查梳理:free 每一列的含义、为什么该看 available 而非 free、used 高不等于危险、RSS 与 VSZ 之别、swap 与 swappiness、page cache 与 drop_caches 的误区,以及怎么区分假告警与真泄漏。- 0
- 0
内存
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×