垃圾收集时间较长，会导致网络连接断开，但 Kubernetes 中的 pod 不会弹跳

Question

我有以下场景：

1. 我有一个 pod，运行带有两个 sidecar 容器的应用程序。
2. 所有三个容器都有多个网络连接（大约 7 个服务器连接到它们）。他们不断下载/发送文件或保持连接以从其他服务器（包括证券交易所服务器）获取数据。
3. Kubernetes版本为v1.24.7+rke2r1
4. Java版本是openjdk_zulu8 (8.0.392-0) - jre1.8.0_362-amd64
5. 图像是使用 docker 1.13.1 构建的
6. Linux 镜像是 RHEL 7.9 (Maipo)
7. 我们没有使用任何云服务，这是我们内部的K8s环境。
8. 我们使用 Ceph 作为存储
9. 堆内存限制没有指定，我们让 JVM 决定。
10. 我们的 Prometheus/Grafana 图表显示没有资源问题，因此我们不认为这是资源问题，但这就是我们设置内存和 CPU 的方式：

• 主容器：

  limits:
    cpu: 3000m
    memory: 10Gi
  requests:
    cpu: 3000m
    memory: 10Gi
  

• 边车容器1：

  limits:
    cpu: 3000m
    memory: 4400Mi
  requests:
    cpu: 2000m
    memory: 4000Mi
  

• 边车容器2：

  limits:
    cpu: 3000m
    memory: 4400Mi
  requests:
    cpu: 2000m
    memory: 4000Mi
  

我面临的问题是，我们的应用程序突然冻结以进行垃圾收集几分钟并停止所有线程。所有三个容器都发生了这种情况。这最终会断开所有网络连接，因为这些应用程序必须进行心跳检测才能保持连接处于活动状态。奇怪的是，这并没有真正停止应用程序，因此 pod 没有重新启动。

我们尝试调整 java 参数以显示有关 GC 的更多数据（并添加更多资源），但我们确实无法在这里找到问题（这就是为什么您会看到我们添加的所有这些花哨的额外参数）看到问题后）。非常欢迎任何帮助/提示。

主要java调用参数：

/usr/java/jre1.8.0_362-amd64/bin/java -showversion -XX:+PrintFlagsFinal -XshowSettings:system -XX:+UseG1GC -XX:+ExplicitGCInvokesConcurrent -XX:+PrintGCDetails -XX:MaxGCPauseMillis=200 -Dsun.rmi.dgc.client.gcInterval=604800000 -Dsun.rmi.dgc.server.gcInterval=604800000 -XX:+SafepointTimeout -XX:SafepointTimeoutDelay=500 -Djava.net.preferIPv4Stack=true -XX:+UseContainerSupport -XX:ActiveProcessorCount=2 -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -javaagent:/opt/jhiccup/lib/jhiccup-2.0.10.jar=-d,5000,-i,1000,-s,3,-l

当出现 GC 问题时，我们开始看到 CPU 节流并且同步列变高：

49335.605: RevokeBias                       [      77          0              0    ]      [     0     0     0     0     0    ]  0
         vmop                    [threads: total initially_running wait_to_block]    [time: spin block sync cleanup vmop] page_trap_count
49335.605: RevokeBias                       [      77          0              0    ]      [     0     0     0     0     0    ]  0
         vmop                    [threads: total initially_running wait_to_block]    [time: spin block sync cleanup vmop] page_trap_count
49340.629: RevokeBias                       [      76          0              0    ]      [     0     0 21728     0     0    ]  0

我在看TOP命令，看到很多进程在这个Status = D，那就是不间断睡眠。看起来 CEPH 中的某些东西正在冻结整个应用程序。有人以前看过这个吗？

这是冻结发生后立即打印的 GC 统计信息。请注意，同步列具有非常高的值：

Answer 1

我们发现问题与存储有关。从 Ceph 更改为 CephRBD 后，问题就消失了。