【发布时间】：2018-11-15 10:27:41
【问题描述】：
我们使用 OpenShift 3.6 作为我们的 Cloud PaaS，我正在测试连接到 Couchbase 集群的 Spring Boot 和 Vert.X 应用程序。可用的默认 POD 大小为 250millicore X 1 GB、400millicore X 1.5 GB 和 1core X 3 GB。
当我尝试部署应用程序（Spring Boot / Vert.X）时，我观察到 250millicore POD 的引导时间 > 2-3 分钟，而 1Core POD 的引导时间为 45 秒。因此，Couchbase 引导程序在 250millicore POD 上花费了大量时间，这违反了其默认的连接超时并导致应用程序崩溃。
如果我增加超时时间，应用程序会启动，但是在执行任何事务时它会很缓慢。我可以使用 1 X 3 POD，但会增加成本。但是，我似乎对使用的内存没有任何问题。
Q1) JVM 在启动期间对 CPU 的依赖是什么（旋转新线程、在内存中处理、类加载等）。
Q2) 我知道 JVM 在启动期间是资源密集型的，但是对于正在使用的堆栈是否有推荐的最小 POD 大小，应用程序在该堆栈上运行良好。
Q3) 如果更大的 POD 大小是 Java 应用程序/JVM 的默认要求，那么它是否违背了能够将其用作应该是轻量级的微服务的概念。
我已经调整了 JVM 参数、Xmx、Xms 和不同的 GC 组合，如 G1GC、ParallelGc 等（看看它是否会以不同的方式发挥作用），但仍然经历相同的引导时间。唯一似乎有影响的是 CPU 大小。
Spring Boot v2.1 OpenShift v3.6 沙发底座 v5.1 Java v1.8.161 CB SDK 2.5.7
Attached is a VisualVM snapshot of the app on my local machine (i5 - 4 core) 在应用生命周期的初始阶段，这似乎占用了大约 30% 的 CPU 容量。
【问题讨论】：
-
只衡量有效的方法，然后相应地应用设置。
标签： java docker jvm kubernetes openshift