从 CDN 超时到 Java Direct Memory OOM：大文件上传故障的全链路排查方法

这篇文章从什么视角出发

这不是一篇只讨论CDN超时、JVM参数或Kubernetes OOM的文章。我想从DevOps/SRE的全链路视角，展示如何让客户端、网络入口、API Gateway、Java应用和Kubernetes容器中的证据相互印证，最终把一个看似发生在网络层的问题定位到真实的应用内存边界。

这个视角并不取代Java开发、Kubernetes运维或网络工程师的专业判断。恰恰相反，它要求先尊重每个领域能提供的事实，再回答一个更高层的问题：这些局部事实能否组成同一个因果链？

因此，本文关注的不只是“怎样把 MaxDirectMemorySize 调大”，而是：

• 每个专业角色最先会看到什么？
• 单一视角能证明什么，又不能证明什么？
• 如何把三类证据拼成一个可复核的结论？
• 怎样定义修复完成和事件结案？

适用场景

• 大文件上传返回 524、502、504 或间歇性 500。
• 网关看起来异常，但应用团队和基础设施团队对故障归属存在分歧。
• Java 应用出现 Cannot reserve ... bytes of direct buffer memory。
• Kubernetes Pod突然重启，应用日志中却没有Java OOM堆栈。
• 同一文件有时上传成功、有时失败。
• Test环境失败而Prod环境成功，需要比较环境差异。

问题现象：看起来像网络超时

一次约270 MiB的视频上传在Test环境失败。入口最初返回CDN超时，直觉上很像以下问题：

• CDN或WAF限制了上传时长。
• API Gateway没有完整接收请求体。
• Ingress与上游连接超时。
• 网络链路传输速度太慢。

延长入口超时后，客户端不再收到CDN超时，而是收到HTTP 500，并出现类似错误：

java.lang.OutOfMemoryError:
Cannot reserve 284000000 bytes of direct buffer memory
(allocated: 587000000, limit: 805306368)

这时不能简单得出“网络没有问题”。正确的问题应该是：

1. 请求体是否完整通过每一层？
2. HTTP 500究竟由网关产生，还是由上游应用返回？
3. 为什么同一个文件重试后可能成功？
4. 为什么有时能看到Java OOM，有时Pod直接重启？

三个专业视角，三种合理判断

面对同一个故障，不同角色会从各自负责的系统边界出发。三种判断都可能合理，但任何一种都不足以单独解释完整事件。

Java开发视角：这是应用内存分配失败

Java开发首先关注异常内容、multipart解析路径、Direct Buffer分配和JVM参数：

Cannot reserve ... bytes of direct buffer memory

从这个视角，可以证明JVM拒绝了一次Direct Memory申请，并进一步检查是否存在整文件聚合、重复复制或资源释放不及时。但仅凭这条异常，还不能回答请求是否完整通过CDN和网关，也不能排除入口层同时存在超时限制。

Kubernetes运维视角：这是容器内存边界问题

Kubernetes运维更关注Pod重启、容器memory limit、lastState、exit code 137和OOM事件：

Reason: OOMKilled
Exit Code: 137

从这个视角，可以证明进程曾因容器总内存越界被内核杀死，也能核对实际镜像、启动参数和资源配额。但它不能仅凭 OOMKilled 判断是哪一类应用请求触发了峰值，也不能解释客户端最初为什么看到CDN超时。

网络工程师视角：先证明请求是否完整传输

网络工程师会关注CDN状态码、上传持续时间、请求体字节数、连接状态、网关response flags和upstream transport failure：

bytes_received
request_duration
response_flags
upstream_transport_failure_reason

从这个视角，可以判断请求是否被入口截断、网关是否发生连接失败，以及HTTP 500是否来自上游。但即使证明网络链路完整，也不能仅靠网络日志解释JVM为什么没有足够的Direct Memory。

更高层视角：不是选一个答案，而是建立因果链

DevOps/SRE的任务不是在三种看法中选边，而是把它们组织成一条时间和因果都一致的证据链：

这就是全链路排错的价值：不把“应用有OOM”“Pod被杀”“入口超时”视为三个孤立现象，而是验证它们是否构成同一条故障演化路径。

第一步：建立全链路时间线

先统一所有系统的时区，并记录客户端测试的开始和结束时间。每次测试生成一个关联标识，同时保留CDN请求ID和网关trace ID。

客户端开始上传
    ↓
CDN开始处理
    ↓
API Gateway接收请求体
    ↓
上游Java应用处理
    ↓
API Gateway返回响应
    ↓
CDN结束请求

如果CDN与API Gateway的开始、结束时间只相差几十毫秒，总耗时也基本一致，至少可以证明两层日志记录的是同一个请求，而不是把不同重试混在一起。

建议每次测试保存以下关联信息：

evidence_id
started_utc
finished_utc
CDN request ID
gateway request ID / trace ID

仅凭时间模糊匹配很危险。并发请求增加后，没有关联标识很容易串错证据。

第二步：用字节数证明请求到了哪里

状态码只说明最终结果，字节数更适合划定传输边界。

假设源文件大小为：

284,922,669 bytes

API Gateway记录：

bytes_received=284,923,019

差值为：

这350 bytes可以由multipart boundary、字段头和结尾构成。换句话说，网关接收的字节数覆盖了完整文件和multipart封装开销。

这个证据比“网关日志里出现了请求”更强，因为后者无法证明请求体是否完整。

第三步：证明500由谁产生

不同网关字段名称可能不同，但通常应关注：

response_code
response_code_details
response_flags
upstream_service_time
upstream_transport_failure_reason
bytes_received
request_duration

一组典型记录可能是：

response_code=500
response_code_details=via_upstream
response_flags=-
upstream_transport_failure_reason=-

这些字段组合说明：

• 网关没有主动拒绝请求。
• 没有上游连接失败、reset或transport error。
• HTTP 500来自上游应用。

如果网关还能记录上游响应正文，并且正文中包含Java OOM，那么责任边界就更加明确。

还可以拆分网关耗时：

total_duration = 99,863 ms
request_duration = 99,141 ms
upstream_service_time = 721 ms
response_tx_duration = 0 ms

未归属开销为：

这说明绝大部分时间用于接收大文件，上游应用在拿到完整请求后很快返回500，网关自身没有额外制造近百秒延迟。

注意，这只能证明“该次500由应用产生”，不能扩大成“上传耗时与网络完全无关”。请求体传输本身仍然花费了约99秒。

第四步：不要只盯着Java Heap

Java容器的内存不只有Heap。至少包括：

• Java Heap
• Direct Memory
• Metaspace
• 线程栈
• Code Cache
• JNI及其他Native Memory
• JVM自身开销

故障时，应用显式设置了：

-Xmx1280m
-XX:MaxDirectMemorySize=768m

错误发生前，Direct Memory已经使用约560 MiB；新请求还需要约272 MiB：

而上限只有768 MiB：

因此，即使Heap还有空间，Direct Memory仍会单独OOM。

这也解释了为什么同一文件可能有时成功、有时失败：新请求到达时，已有Direct Memory占用、并发数量和资源释放状态并不固定。这是一种容量余量不足导致的间歇性故障，不是简单的固定文件大小限制。

第五步：区分两种OOM

JVM Direct Buffer OOM

典型错误：

Cannot reserve ... bytes of direct buffer memory

这是JVM拒绝新的Direct Buffer分配。Java进程通常仍有机会抛出异常，因此可能在以下位置找到证据：

• 应用日志
• 全局异常处理器输出
• API Gateway保存的上游响应正文
• 客户端收到的500响应

Kubernetes OOMKilled

当容器总内存超过cgroup limit时，Linux内核可能直接杀死进程：

Last State:  Terminated
  Reason:    OOMKilled
  Exit Code: 137

这种情况下，Java进程可能来不及打印OOM堆栈。正确证据位置是：

kubectl describe pod <pod> -n <namespace>

kubectl get pod <pod> -n <namespace> `
  -o jsonpath='{.status.containerStatuses[0].lastState}'

kubectl logs <pod> -n <namespace> --previous --timestamps

kubectl get events -n <namespace> `
  --field-selector involvedObject.name=<pod> `
  --sort-by='.lastTimestamp'

没有Java OOM日志，不等于没有OOM。lastState.reason=OOMKilled、exit code 137和内核OOM事件才是容器级OOM的主要证据。

Kubernetes Event通常有保留期限，不能把它当作长期审计日志。重要事件应及时导出，或通过集中式日志与监控长期保存。

第六步：比较Prod与Test时，以运行态为准

环境差异不能只看仓库里的配置文件，还应核对：

• 实际运行镜像的tag和digest
• /proc/1/cmdline
• Deployment与ReplicaSet状态
• Pod resources.requests 和 resources.limits
• 环境变量、ConfigMap和启动参数
• CDN、Ingress与Gateway的有效配置

查看PID 1真实启动参数：

kubectl exec -n <namespace> <pod> -- `
  sh -c 'tr "\000" " " < /proc/1/cmdline; printf "\n"'

查看容器资源限制：

kubectl get pod -n <namespace> <pod> `
  -o jsonpath='request={.spec.containers[0].resources.requests.memory}{"\n"}limit={.spec.containers[0].resources.limits.memory}{"\n"}'

Dockerfile、Helm values、GitOps仓库和运行中的Pod可能发生漂移。最终解释线上行为的，是当时真正运行的镜像与参数。

如何修复

1. 先解除错误的固定上限

本例将过小的Direct Memory上限提高，并同步调整容器内存预算。下面只作为配置示例，不能直接复制到所有服务：

-XX:+UseContainerSupport
-XX:MaxRAMPercentage=35
-XX:MaxDirectMemorySize=2g

对应Kubernetes资源示例：

resources:
  requests:
    memory: 4Gi
  limits:
    memory: 5Gi

正确做法不是孤立地把某个数字调大，而是满足近似内存预算：

2. 限制并发，防止内存需求叠加

如果每个请求可能占用接近文件大小的Direct Buffer，并发上传会迅速放大内存需求。应根据单请求峰值和容器预算设置并发限制、队列或背压。

3. 从根本上避免整文件聚合

扩容是止血，不一定是最终方案。长期应排查multipart解析和下游SDK是否把完整文件聚合到单块内存，并优先考虑：

• 流式读取和流式转发
• 分块上传
• 临时文件落盘
• 对象存储预签名直传
• 避免不必要的byte array与Direct Buffer复制

如何验证

修复后应使用同一文件、同一真实域名和同一路径进行多轮测试，而不是绕过CDN直接访问源站。

$file = 'C:\path\to\large-video.mp4'
$evidenceId = 'upload-test-' + [DateTime]::UtcNow.ToString('yyyyMMddTHHmmssZ')
$url = "https://upload.example.com/api/videos?evidence_id=$evidenceId"

curl.exe `
  --http1.1 `
  --silent `
  --show-error `
  --connect-timeout 30 `
  --max-time 1200 `
  -H 'Expect:' `
  -H "X-Correlation-ID: $evidenceId" `
  -F "file=@$file" `
  --dump-header response-headers.txt `
  --output response-body.txt `
  --write-out "http_code=%{http_code}`nupload_bytes=%{size_upload}`nstarttransfer_seconds=%{time_starttransfer}`ntotal_seconds=%{time_total}`n" `
  $url

成功结果应同时满足：

HTTP 200
上传字节数与源文件加multipart开销一致
CDN和API Gateway无52x或transport failure
应用无新增Direct Buffer OOM
Pod restartCount不增加
Pod无新增OOMKilled事件

至少执行多轮串行上传；如果生产场景存在并发，还要进行受控并发压测。一次成功只能证明路径可用，不能证明容量设计合理。

从局部修复到系统结案

三个专业视角也对应三组验收条件：

只有三组条件同时成立，才能说故障完成闭环。只看到一次HTTP 200、只确认Pod处于Running，或者只把JVM参数调大，都不足以单独支持结案。

从更高层看，DevOps排障的价值不是替某一层快速下结论，也不是替专业团队做所有工作，而是让分散在不同系统中的事实形成一条可验证的证据链。当根因、修复和验收能够跨层相互印证，事件才真正结束。

一套可复用的TCA排错模式

可以把整个方法压缩为一句话：

先确认请求完整到了哪里，再确认响应由谁产生；先用传输证据划定边界，再进入应用运行时；最后用同一路径复测闭环。

常见误区

• 看到524就认定是CDN故障：入口超时可能只是最先暴露的限制层。
• 只看HTTP状态码，不看字节数：状态码不能证明请求体是否完整。
• 只关注 -Xmx：Direct Memory和其他Native Memory同样计入容器总内存。
• 没看到Java OOM堆栈就排除OOM：容器可能被内核直接SIGKILL。
• 同一文件重试成功就认为问题消失：间歇性OOM与并发和当时内存占用相关。
• 直接照搬Prod参数到Test：应根据各环境真实负载和容器预算设计参数。
• 只增加超时和内存：如果应用整文件聚合，容量问题仍可能在更大文件或更高并发下复现。

FAQ / 可被搜索的问题与答案

Java Heap没有满，为什么还会OOM？

因为Java进程还使用Direct Memory、Metaspace、线程栈和其他Native Memory。-Xmx只限制Heap，不能代表进程或容器的全部内存使用。

MaxDirectMemorySize应该设置多大？

没有适用于所有服务的固定值。应根据单请求Direct Memory峰值、最大并发、Heap、Native Memory和安全余量计算，并确保总预算低于容器limit。还要通过压测和运行指标校准。

OOMKilled为什么没有应用错误日志？

容器超过cgroup内存限制时，内核可能直接发送SIGKILL。Java进程没有机会执行异常处理或刷新日志，因此应检查Pod lastState、exit code 137、Kubernetes Event和 kubectl logs --previous。

如何证明API Gateway不是500的根因？

组合检查完整接收字节数、via_upstream或等价字段、空的response flags、空的upstream transport failure reason，以及上游响应正文。单个字段通常不够，证据组合才有说服力。

为什么大文件上传有时成功、有时失败？

如果失败取决于已有Direct Memory占用、并发、资源释放和容器剩余容量，同一个文件就可能间歇性成功。这说明容量余量或内存生命周期有问题，而不是故障不存在。

延长CDN或网关超时能解决问题吗？

只能解决入口提前超时的问题。延长后可能暴露下一层真实错误，例如应用500、Direct Buffer OOM或下游处理超时。每解除一层限制，都要继续验证下一层行为。

Best Practices

• 给每次外部请求生成可贯穿CDN、网关和应用的correlation ID。
• 在网关日志中保存请求字节数、响应来源、transport failure和分阶段耗时。
• 监控Heap、Direct Memory、容器Working Set、重启次数和OOM事件。
• 全局异常处理器记录完整stack trace，不要只把exception message返回给客户端。
• 在CI/CD中校验JVM参数与Kubernetes memory limit的预算关系。
• 用真实域名、真实链路和代表性文件做修复验证。
• 对大文件上传执行受控并发压测，而不只做单请求冒烟测试。
• 优先采用流式、分块或对象存储直传设计。