使用 Jmeter - Kubernetes 进行测试后，spring boot 的容器内存使用率不低

Question

早上好。 我有一个查询，我对 Kubernetes 和 Java（spring boot）比较陌生，我目前正在使用 spring boot 部署一个带有三个容器的 pod，问题是我正在使用 Jmeter 进行测试以测量指标并在 Kubernetes 中使用 HPA 自动扩展，但是我发现当您强调容器的内存会增加时，但是当我完成测试时，容器不会降低内存使用量。 不知道这个话题是不是因为JVM的原因，是典型的Java，还是垃圾收集器失败了，必须在docker镜像中定义。 我在 yaml manifest 的容器中给了他 CPU 和内存方面的资源限制

这是我的容器在使用 Jmeter 开始测试之前的状态

用Jmeter测试后，通过了大约15分钟，容器在内存方面也是如此：

这就是我定义 Dockerfile 的方式：

FROM openjdk:8-alpine
RUN rm -rf /var/cache/apk/*
RUN rm -rf /tmp/*
RUN apk update
RUN apk add busybox-extras
ENV UBICATION_CERTIFICATE_SSL=/etc/letsencrypt/tmp224.p12
ENV PASSWORD_CERTIFICATE_SSL=xxxxx
ENV ALIAS_CERTIFICATE_SSL=tmp224
ADD FindAccountNumber-0.0.1-SNAPSHOT.jar /home/app.jar
ADD tmp224.p12 /etc/letsencrypt/tmp224.p12
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/home/app.jar"]

还有我的清单 yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: find-complementary-account-info-1
  labels:
    app: find-complementary-account-info-1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: find-complementary-account-info-1
  template:
    metadata:
      labels:
        app: find-complementary-account-info-1
    spec:
      containers:
      - name: find-account-number-1
        image: find-account-number:latest
        imagePullPolicy: IfNotPresent
        resources:
          limits:
            cpu: "250m"
            memory: "350Mi"
          requests:
            cpu: "150m"
            memory: "300Mi"
        ports:
        - containerPort: 8081
        env:
        - name: URL_CONNECTION_BD
          value: jdbc:oracle:thin:@xxxxxxxx:1531/DEFAULTSRV.WORLD
        - name: USERNAME_CONNECTION_BD
          valueFrom:
            secretKeyRef:
              name: credentials-bd-pers
              key: user_pers
        - name: PASSWORD_CONNECTION_BD
          valueFrom:
            secretKeyRef:
              name: credentials-bd-pers
              key: password_pers
      - name: find-account-validators-1
        image: find-account-validators:latest
        imagePullPolicy: IfNotPresent
        resources:
          limits:
            cpu: "250m"
            memory: "350Mi"
          requests:
            cpu: "150m"
            memory: "300Mi"
        ports:
        - containerPort: 8082
        env:
        - name: URL_CONNECTION_BD
          value: jdbc:oracle:thin:@xxxxxxxx:1522/DEFAULTSRV.WORLD
        - name: USERNAME_CONNECTION_BD
          valueFrom:
            secretKeyRef:
              name: credentials-bd-billing
              key: user_billing
        - name: PASSWORD_CONNECTION_BD
          valueFrom:
            secretKeyRef:
              name: credentials-bd-billing
              key: password_billing
      - name: find-complementary-account-info-1
        image: find-complementary-account-info:latest
        imagePullPolicy: IfNotPresent
        resources:
          limits:
            cpu: "250m"
            memory: "350Mi"
          requests:
            cpu: "150m"
            memory: "300Mi"
        ports:
        - containerPort: 8083
        env:
        - name: UBICATION_URL_ACCOUNT_NUMBER
          value: "https://localhost:8081/api/FindAccountNumber"
        - name: UBICATION_URL_ACCOUNT_VALIDATORS
          value: "https://localhost:8082/api/FindAccountValidator"
---

apiVersion: v1
kind: Service
metadata:
  name: svc-find-complementary-account-info-1
  labels:
    app: find-complementary-account-info-1
  annotations:
    metallb.universe.tf/allow-shared-ip: shared-ip
  namespace: default
spec:
  selector:
    app: find-complementary-account-info-1
  externalTrafficPolicy: Cluster
  loadBalancerIP: 10.161.174.68
  type: LoadBalancer
  ports:
   -
    protocol: TCP
    port: 8083
    targetPort: 8083
    nodePort: 30025
---

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: find-complementary-account-info-1
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: find-complementary-account-info-1
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

我怎样才能减少在容器中使用弹簧靴的内存，因为我想它会随着压力的增加而不断增加

Answer 1

我认为差异很小（~220 MB vs 250-290 MB），你不应该为此烦恼。

但您似乎在谈论 Java 应用程序（不是）将内存返回给操作系统。 这是很长一段时间以来的常见行为，它取决于垃圾收集器 - 这并不意味着 GC 不起作用。 您使用的是 JDK 8，因此您没有太多选择，但在更高版本中，有改进的收集器，例如

• JDK 12 中的 G1 GC：及时从 G1 返回未使用的已提交内存
• 雪兰多

您可以在此处找到更多信息： GC 是否将内存释放回操作系统？