Kubernetes中Meteor/Node服务内存限制调整问题排查

Exit code 134 typically means your application process received the SIGABRT signal—this usually happens when the app triggers an abort on its own (like hitting an unhandled out-of-memory error) or hits an assertion failure. Since your pod’s memory usage never comes close to the 6Gi limit you set, let’s break down the most likely missing configurations or hidden issues to check:

• Process-level memory exhaustion (not container-level)
  For JVM-based apps, even with a 6Gi container memory limit, if your JVM heap (-Xmx) or off-heap memory settings (direct memory, thread stacks, metaspace, etc.) are too low, the app can still throw an OutOfMemoryError and self-abort (resulting in exit code 134). The container’s overall memory usage might stay under the limit because the JVM hasn’t tapped into the full allocated container memory.
  Fix: Align your JVM parameters with the container’s memory limit. For example, with a 6Gi limit, set -Xmx4G to leave enough headroom for off-heap memory and system overhead. Double-check parameters like -XX:MaxDirectMemorySize to ensure they’re sized appropriately too.

• Insufficient CPU resources
  While exit code 134 is linked to memory, CPU starvation can indirectly cause crashes. If your pod has tight CPU limits, frequent CPU throttling might disrupt application execution, leading to unexpected internal errors that trigger SIGABRT.
  Fix: Check your pod’s CPU requests and limits—temporarily increase the CPU limit to see if crashes stop. Use kubectl top pod or your cluster’s monitoring stack to track CPU throttling metrics and confirm if this is the root cause.

• Application-level bugs triggering SIGABRT
  Exit code 134 can also stem from code-level issues: uncaught exceptions, assertion failures, or memory leaks in off-heap regions (like native libraries). These problems make the process call abort() on its own, without the container hitting a memory limit.
  Fix: Enable core dumps for your container (check your runtime’s docs for setup steps) and dig into application logs (especially stderr) for crash-time errors. For Java apps, look for hs_err_pid files in the container—they detail exactly why the JVM crashed.

• Misconfigured memory requests
  Even with a 6Gi memory limit, if your requests.memory is set too low (e.g., way less than the 1.6Gi your pod actually uses), the scheduler might place the pod on a node with insufficient available memory. While this usually leads to exit code 137 (SIGKILL from kubelet), node-level memory pressure could indirectly cause application instability.
  Fix: Set requests.memory to a value close to your pod’s typical usage (e.g., 2Gi) to ensure the pod gets scheduled on nodes with enough resources.

• Incomplete memory usage metrics
  The memory usage you’re viewing might only track RSS (Resident Set Size) and exclude other memory types like page cache, shared memory, or buffers. While this is unlikely given the huge gap between 1.6Gi and 6Gi, it’s worth verifying.
  Fix: Run kubectl exec <your-pod-name> -- free -h inside the container to see the full memory breakdown (including cache/buffers) and confirm it’s still under the 6Gi limit.

内容的提问来源于stack exchange，提问作者Miguel Morujão