搜索结果: "memory"

title: K8s Java DirectMemory OOM 诊断 — 堆内存充足但 OOMKilled 的根因与复现

tags: [kubernetes, java, jvm, troubleshooting, memory, performance]

# K8s Java DirectMemory OOM 诊断

> GC 平稳、堆内存只用了一半、Pod 却突然 OOMKilled（退出码 137）？问题不在堆，而是被长期忽略的**堆外内存（DirectMemory）**悄悄拖垮。本文从错误认知、根因、故障复现代码到生产配置，完整拆解这类隐性 OOM。

| DirectMemory 堆外内存 | `-XX:MaxDirectMemorySize` | NIO/Netty 核心使用区域 |

> 💡 本文是"速查清单/决策树"视角。MySQL 性能调优（慢查询/锁/死锁/索引/Buffer Pool）深度内容见 [[mysql-performance-config]]；Redis 内存优化（数据结构/TTL/淘汰/Bigkey/碎片）见 [[redis-memory-optimization]]；Redis 连接管理见 [[redis-connection-management]]。

| `performance_schema` / `sys` | 锁等待/IO/语句统计 | `MEMORY USAGE key` | 单个 key 内存占用 |

| `information_schema` | 元数据（表大小/索引） | `MEMORY DOCTOR` | 内存问题诊断 |

**现象**：写入报 `OOM command not allowed when used memory > 'maxmemory'`

redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human|maxmemory_policy'

tags: [redis, database, memory, production, performance, debugging]

sources: [raw/articles/redis-memory-optimization-guide.md]

可淘汰：配置合理的 maxmemory 和淘汰策略

**建议：** 内存敏感场景下，用 `MEMORY USAGE key` 实测真实占用，对比不同序列化方式。

但 Hash 不是永远更省 — field 名太长、field 太多、value 特别大时也可能膨胀。**结合 MEMORY USAGE 实测。**

dmesg | grep -i "out of memory"

# JVM 堆内存 + native/direct buffer/mmap 等堆外内存之和 ≤ 容器 memory limit

docker run -e JAVA_OPTS="-Xmx768m" --memory=1g my-java-app

limit=$(docker inspect $name --format '{{.HostConfig.Memory}}')

| [[k8s-java-directmemory-oom-diagnosis]] | K8s Java DirectMemory OOM 诊断 — GC 正常/堆内存充足但 OOMKil |

memory: "2Gi"

memory: "4Gi"

resourceRequestMemory: "512Mi"

resourceLimitMemory: "1Gi"

resourceRequestMemory: "128Mi"

tags: [kubernetes, java, troubleshooting, memory, container, performance]

├── Direct Memory ← NIO 的 DirectByteBuffer，-XX:MaxDirectMemorySize 控制

cgroup.memory.current = RSS（常驻物理内存）

+ Kernel Memory（slab、socket buffer 等）

jcmd VM.native_memory summary | grep "Internal"

| requests.memory | 调度 + 驱逐排序 | Pod 希望被保证的内存 | Scheduler + kubelet eviction |

| limits.memory | 运行 | 内存硬上限，超限后 OOMKilled | OOM killer / cgroup |

> ⚠️ 驱逐排序：BestEffort > 超 request 的 Burstable > Guaranteed。但 Guaranteed 超 memory limit 仍会被杀。

1. **历史资源水位** — CPU/Memory/Network/Disk 的 P50/P90/P95/P99

容器 RSS ≈ Heap + Metaspace + Direct Memory + Thread Stack + Code Cache + GC Native + JNI + glibc arena

tags: [kubernetes, java, jvm, memory, performance, troubleshooting, architecture]

1. **`-Xmx` 只约束堆，`memory.limit` 约束容器总内存** — 堆调到容器上限 ≈ 主动制造 OOM

容器 memory.limit = 4Gi

├── Direct Memory ← Netty ByteBuf / NIO DirectByteBuffer

**Direct Memory：** Netty ByteBuf、Kafka 客户端缓冲、NIO DirectByteBuffer。特点是：吞吐好、GC 压力小、**但不受 -Xmx 约束**。必须设 `-XX:MaxDirectMemorySize`。

| `memory.available` | 可用内存 | `< 100Mi` | 设了 limits 没设 requests，内存超卖严重 |

很多团队只给 CPU/Memory 设配额，忘了本地临时存储。容器日志、`/tmp`、emptyDir、镜像可写层都会消耗本地盘，超出阈值即被驱逐。K8s v1.8+ 支持 `ephemeral-storage` 资源配额。

重点看 `Conditions` 部分是否挂上 `MemoryPressure` 或 `DiskPressure` 标签。

- `Pod was evicted due to memory pressure` → 内存不够

kubectl top pods -A --sort-by=memory | head -20

**Events 关键词：** `Insufficient cpu` / `Insufficient memory` / `Insufficient ephemeral-storage`

# 0/5 nodes are available: 3 Insufficient memory.

**⚠️ 资源碎片化 ≠ 总量不足：** 调度事件 `0/26 nodes are available: 5 Insufficient cpu, 10 Insufficient memory, 3 node(s) had taint...` 的重点是**失败原因分散在不同节点**——不是集群没资源，而是 request 设置过大导致零散资源无法利用，此时扩容节点往往无效。正确做法：对照 `kubectl top pods -A`（实际使用）与 `kubectl describe nodes`（request 预留）两组数据，基于历史使用重新校准 request，高估服务先灰度调整。VPA 可参考，流量波动大的场景勿自动采纳。

| `node.kubernetes.io/memory-pressure` | 内存压力 | 默认 NoSchedule |

│ │ ├─ Insufficient cpu/memory → 方向一

memory: "256Mi"

memory: "512Mi"

- **Memory**: **强烈建议 Request = Limit**，否则导致 OOMKill 优先级异常（见下文）

| Burstable | min(max(2, 1000 - 1000×memoryRequest/nodeMemory), 999) | 中等 |

kubectl describe pod | grep -E "QoS|Memory|Limit|Request"

| `kubectl get nodes` | 看节点状态：NotReady、DiskPressure、MemoryPressure |

真正要看的是：NodeDiskPressure/NodeMemoryPressure、kubelet 与 API Server 通信失败、证书过期、容器运行时无响应、节点级 OOM 杀掉 kubelet。

`0/26 nodes are available: 5 Insufficient cpu, 10 Insufficient memory, 3 node(s) had taint...`

退出码 137 时很多 Java 团队第一反应是「堆设太大了」，这经常只说对一半。容器内存限制看到的是**整个进程空间**：Java Heap、Metaspace、Direct Memory、线程栈、JIT/Native Library 等额外开销。即使 `-Xmx` 没碰到 limit，总内存仍可能超限被 cgroup 杀掉。

详见 [[k8s-java-directmemory-oom-diagnosis]]、[[jvm-container-oom-offheap-troubleshooting]]。

MemoryPressure False KubeletHasSufficientMemory

| MemoryPressure | 内存不足 | 节点内存耗尽，OOM risk |

### 内存压力（MemoryPressure）

sudo dmesg | grep -i "out of memory" | grep -i "kubelet"

memory.available: "100Mi"

-o jsonpath='{.spec.containers[*].resources.limits.memory}'

| Burstable | min(max(2, 1000 - 1000×memoryRequest/nodeMemory), 999) | 中等 |

1. **增大 memory limits**（如果是正常业务增长）`kubectl patch deployment`

memory: "128Mi"

memory: "128Mi"

tags: [linux, memory, performance, troubleshooting, monitoring, debugging]

dmesg | grep -i "out of memory\|killed process"

cat /sys/fs/cgroup/memory.max # 硬限制（字节），超过触发 OOM

cat /sys/fs/cgroup/memory.high # 软限制，超过触发回收但不杀进程

cat /sys/fs/cgroup/memory.low # 保护阈值，低于此值尽量不回收

| `dmesg -T \| tail` | 最近内核报错 | OOM、磁盘错误、网络超时 | 出现 `Out of memory` 或 `hung_task` |

dmesg | grep -i "out of memory\|killed process" # OOM 日志

**Java 特殊注意：** JVM 内存 ≠ -Xmx。包含堆 + 元空间 + 直接内存 + Native。用 `jcmd VM.native_memory`。

| [[linux-memory-management-deep-dive]] | Linux 内存管理深潜（Buffer/Cache/Page Cache/Slab/回收/OOM/cgroup v2） |

| [[k8s-java-memory-tuning-production-guide]] | Kubernetes 下 Java 内存调优完整指南 — 内存预算模型、生产参数配置、四层诊断流程、 |

| OOM 日志 | `journalctl -k \| grep -Ei 'out of memory|oom-killer'` |

| PSI 压力 | `cat /proc/pressure/memory` |

cat /sys/fs/cgroup/memory.current

cat /sys/fs/cgroup/memory.max

cat /sys/fs/cgroup/memory.events

- [[k8s-java-directmemory-oom-diagnosis]] — K8s Java DirectMemory OOM 诊断 — GC 正常/堆内存充足但 OOMKilled 的根因分析、故障复现代码与生产配置方案

- [[k8s-java-memory-tuning-production-guide]] — Kubernetes 下 Java 内存调优完整指南 — 内存预算模型、生产参数配置、四层诊断流程、GC 选型、发布策略

- [[linux-disk-io-monitoring-reference]] — 磁盘 IO 监控参考 — iostat/vmstat 字段详解与五指标框架。磁盘使用率/饱和度/IOPS/吞吐量/响应时间五指标框架。iostat 逐字段解读（avg-cpu 段：user/nice/system/iowait/steal/idle；Device 段：rrqm/s/wrqm/s/r/s/w/s/rMB/s/wMB/s/avgrq-sz/avgqu-sz/await/svctm/%util）。vmstat 逐字段解读（procs r/b；memory swpd/free/buff/cache；swap si/so；io bi/bo；system in/cs；cpu us/sy/id/wa/st）。await vs svctm 核心判断。综合决策表（7 种场景）。

- [[linux-memory-management-deep-dive]] — Linux 内存管理深潜：Buffer/Cache/Page Cache/Slab/三级回收/OOM/cgroup v2

- [[redis-memory-optimization]] — Redis 内存优化完全指南：key设计/数据结构选型/序列化/bigkey/碎片/淘汰策略/TTL

- Created raw: raw/articles/redis-memory-optimization-guide.md

- Created concepts: redis-memory-optimization（12 章节覆盖 key/value/数据结构/序列化/淘汰策略/bigkey/碎片/fork-COW/缓冲区/排查命令）

- Created concepts: linux-memory-management-deep-dive（配套 server-performance-four-dimensions 的内存专项深潜）

- Updated: server-performance-four-dimensions, redis-memory-optimization, linux-kernel-tuning-production（添加内存管理交叉引用）

- 文章与 [[server-performance-four-dimensions]] + cpu-spike / linux-load-average / linux-memory / network-troubleshooting 等多页高度重叠

tags: [linux, performance, networking, security, tcp, memory, scheduling]

vm.overcommit_memory = 1 # 允许内存超分（数据库/Redis 场景）

- **overcommit_memory = 1** — 允许内存超分，数据库、Redis 场景避免服务启动失败

- [[linux-memory-management-deep-dive]] — Linux 内存管理深潜

| 48 | cgroups 在 K8s 中的应用？ | CPU(cfs_period_us/cfs_quota_us) + 内存(memory.limit_in_bytes/OOM) + IO(blkio) + PID(pids.max)。v1 内存泄漏→升级 v2 + systemd 驱动 | [[k8s-resource-limits-configuration]] |

| 13 | Redis 性能优化？ | 合适数据结构 + TTL + pipeline + 持久化策略 + 哨兵/集群 + 内存分配 | [[redis-memory-optimization]] |

| [[redis-memory-optimization]] | Redis 内存优化 |

| 资源不足 | describe Events 显示 "Insufficient cpu/memory" | 降低 requests 或扩节点 |

| 137 | SIGKILL，通常 OOM | 调大 limits.memory 或排查内存泄漏 |

**OOM 建议：** limits.memory ≥ 峰值用量 × 1.2，并用监控观察实际 RSS。

- **OOMKilled:** 增大 memory limits 或优化应用内存（Java 容器注意：`-Xmx` 设置 + 元空间/线程栈/直接内存等额外开销总和 < container limits）

# Message: "0/3 nodes are available: 1 Insufficient memory, 2 node(s) had taints..."

- Pod 被 OOMKill → 退出码 137，调大 memory limits 或优化内存

grep -C 5 "OutOfMemoryError" /var/log/app/app.log

2026-07-14 09:12:03 INFO Loaded 500000 records into memory

2026-07-14 09:12:06 ERROR OutOfMemoryError: Java heap space

# procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----

**系统日志关键字（`journalctl -xe | tail -50` / `dmesg | tail -50`；持续监控用 `journalctl -f`）：** `Out of memory`（内存不足）、`I/O error`（磁盘 IO 错误）、`segfault`（进程段错误）、`hung task`（进程卡死）、`soft lockup`（软锁死）/ `hard lockup`（硬锁死）。

**Prometheus + Grafana 重点指标：** node_load1/node_load5/node_load15（Load Average）、node_cpu_seconds_total（CPU 使用时间）、node_memory_MemAvailable_bytes（可用内存）、node_memory_SwapCached_bytes（Swap 使用量）、node_disk_io_time_seconds_total（磁盘 IO 时间）、node_disk_read_bytes_total（磁盘读字节数）、node_disk_written_bytes_total（磁盘写字节数）、node_network_receive_bytes_total（网络接收字节数）、node_network_transmit_bytes_total（网络发送字节数）。以上指标名称仅供参考，实际指标名称取决于使用的 exporter 版本。

| [[redis-memory-optimization]] | Redis 内存优化（客户端输出缓冲区 + 大响应排查） |

| [[server-performance-four-dimensions]] | 系统级 fd/memory 监控 |

gather_subset: ['!all', '!min', 'hostname', 'distribution', 'memory', 'processor', 'network']

Total Memory: {{ ansible_memtotal_mb }} MB

内存管理底层原理参见 [[linux-memory-management-deep-dive]]（Buffer/Cache/Slab 全链路）。

| [[linux-memory-management-deep-dive]] | 内存 Buffer/Cache/OOM 全链路 |

memory: 4Gi

memory: 1Gi

| 节点资源压力（eviction） | 现有 Pod 被终止 | `The node was low on resource: memory` |

> ⚠️ **风险提醒：** CoreDNS 的 `resources.limits.memory` 不足会导致 OOM 重启，引发间歇性 DNS 超时——这是"服务一会好一会坏"的最常见原因。

- [[k8s-java-directmemory-oom-diagnosis]] — K8s Java DirectMemory OOM 诊断 — GC 正常/堆内存充足但 OOMKil

- [[linux-memory-management-deep-dive]] — Linux 内存管理（GC 根因涉及内存）

| [[linux-memory-management-deep-dive]] | 内存管理深潜（swappiness/cache 压力） |

| [[k8s-java-memory-tuning-production-guide]] | Kubernetes 下 Java 内存调优完整指南 — 内存预算模型、生产参数配置、四层诊断流程、 |

| `sudo dmidecode -t memory` | 查看物理内存插槽信息 |

| `sudo lshw -C memory` | 查看内存详细配置 |

- `Out of memory` → 内存爆了

| [[linux-memory-management-deep-dive]] | Linux 内存管理深度解析 |

vmstat 1 3 # procs/memory/io/system/cpu

free -h -w # memory pressure

- memory: 内存管理与优化

**预防**：备份盘容量规划 = 备份大小 × 1.5。加 `--use-memory=2G` 限制内存。

- [[redis-memory-optimization]] — Redis 内存优化完全指南（fork/COW 对 BGSAVE 的影响）

| [[redis-memory-optimization]] | 内存优化（淘汰策略场景参考） |

- [[redis-memory-optimization]] — Redis 内存优化完全指南（fork/COW 内存影响）

| 按 CPU/内存排序 | `kubectl top pods -n --sort-by='.cpu\|.memory.usage'` |

- [[redis-memory-optimization]] — Redis 内存优化（缓存的存储层基础）

| process_resident_memory_bytes | 内存使用量 | 接近限制值的 80% |

- `kubectl get nodes` → 节点状态（NotReady、DiskPressure、MemoryPressure）

- 建议 limits.memory 设为 requests.memory 的 1.5-2 倍（MySQL/Java 等）

-XX:+HeapDumpOnOutOfMemoryError \

### memory 段（KB）

| [[linux-memory-management-deep-dive]] | 内存管理（含 swap 机制） |

- [[linux-memory-management-deep-dive]] — Linux 内存管理（/proc/meminfo）

- [[linux-memory-management-deep-dive]] — Linux 内存管理深潜（vm.swappiness/vm.min_free_kbytes 等参数详解）

dmesg | grep -i "out of memory" # 查 OOM

free -h > /tmp/memory.txt

df = pd.read_csv(f, low_memory=False)

logger "Memory usage too high: $MEM_USAGE%"; exit 1