输入:GCP,Kubernetes,Java 11 Spring Boot 2应用程序
容器启动时的内存限制为1.6GB。 Java应用程序也限制内存-XX:MaxRAMPercentage = 80.0。在“沉重”(不是真的)负载下-在大约4个小时的时间内,每100毫秒大约1个HTTP请求被OOMKiller杀死。内部诊断工具显示内存远远不够:
但是GCP工具显示以下内容:
[GCP是否有其他衡量标准? POD仅包含Java应用程序(+ Jaeger代理)。奇怪的是,重新启动GCP后几乎显示了最大的内存使用情况,而不是如果出现内存泄漏则缓慢增长。
编辑:
Docker文件:
FROM adoptopenjdk/openjdk11:x86_64-ubuntu-jdk-11.0.3_7-slim VOLUME /tmp VOLUME /javamelody RUN apt-get update && apt-get install procps wget -y RUN mkdir /opt/cdbg && wget -qO- https://storage.googleapis.com/cloud-debugger/compute-java/debian-wheezy/cdbg_java_agent_gce.tar.gz | tar xvz -C /opt/cdbg RUN apt-get install fontconfig ttf-dejavu -y ARG JAR_FILE ARG VERSION ARG MODULENAME ENV TAG=$VERSION ENV MODULE=$MODULENAME COPY target/${JAR_FILE} app.jar COPY ./docker-entrypoint.sh / ENTRYPOINT ["/docker-entrypoint.sh"] CMD java -agentpath:/opt/cdbg/cdbg_java_agent.so \ -Dcom.google.cdbg.module=${MODULE} \ -Dcom.google.cdbg.version=${TAG} \ -Djava.security.egd=file:/dev/./urandom \ -XX:MaxRAMPercentage=80.0 \ -XX:+CrashOnOutOfMemoryError \ -XX:ErrorFile=tmp/hs_err_pid%p.log \ -XX:NativeMemoryTracking=detail \ -XX:+UnlockDiagnosticVMOptions \ -XX:+PrintNMTStatistics \ -XX:+HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath=tmp/ \ -jar /app.jar
并与Kubernetes一起运行(省略了其他细节):
apiVersion: apps/v1
spec:
replicas: {{ .Values.replicas }}
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 50%
maxUnavailable: 0
template:
spec:
initContainers:
bla-bla
containers:
lifecycle:
preStop:
exec:
command: [
# Gracefully shutdown java
"pkill", "java"
]
resources:
limits:
cpu: 1600
memory: 1300
requests:
cpu: 1600
memory: 1300
输入:GCP,Kubernetes,Java 11 spring boot 2应用程序容器以内存限制1.6GB启动。 Java应用程序也限制内存-XX:MaxRAMPercentage = 80.0。在“沉重”下(不是...
每个日志文件,有10,000多个启动线程。即使我们不关注为容器保留的少于2个CPU /内核,这也是[[很多