容器docker并行计算_调整容器中的并行处理

容器docker并行计算

一般而言，我们希望我们的服务器能够一次处理多个请求。 如果我们仅在单个线程上运行所有内容，那么我们可能会发现CPU利用率较低，并且感觉我们在浪费金钱来浪费未充分使用的计算机的正常运行时间。

但是，当您运行带有Java应用程序之类的容器时，如何计算最终得到的多个参数呢？ 这些参数包括：

• CPU分配–整个CPU的百分比
• 容器内存
• 容器内存中的Java堆-TBH，具有现代Java版本（例如，支持容器的容器-从Java 10开始），您可能应该使用默认值
• 执行特定任务的并行线程数
• 应用于下游资源的缓存量
• 要并行运行的容器的副本数量是多少？

调整参数的组合将取决于您正在运行的确切任务，甚至可能在您自己的软件版本之间发生根本性的变化。

调整的一般方法是找到一种方法，以在高负载下连续运行系统进行试验，然后在试图找到一些合理的调整参数时对其进行监视。 找到正确的近似大小后，您可以对即将部署的最终版本进行一些微调。

将系统调整为100％的资源使用率并不会带来任何好处，因为负载大小的变化或后台作业所需的任何时间都会降低性能。 最好调到80％左右。

从哪儿开始？

找出一些不要做的事情可能会更容易。

对于主要使用一些Web服务的CPU轻型应用程序 ，它的工作是：不要在有大量内存的计算机上运行少数线程。

为什么？ 显然，这个神话般的应用程序将需要负载和线程负载来填充其CPU和内存的容量，并且在较低的负载周期内将浪费机器资源。

对于占用大量CPU和内存的应用程序 ，请勿在CPU和内存最少的计算机上使用大量线程。

为什么？ 显然，这种应用程序的挫败将大部分时间用于线程争用和垃圾回收开销。

对于中型应用程序 ，不要在一个很小的容器上运行单个线程。

为什么？ 好吧……也许这会很棒……或者也许您会认为可用的0.x％的CPU时间的大部分将花费在处理应用程序的真实性上。 操作系统开销/后台作业，在应用程序中最小线程数之间的任务切换等。

所以不要以愚蠢的开始

本质上，您需要了解应用程序中任务的大小，并对容器进行缩放以发现执行其中一项非常简单。 假设基线CPU占整个CPU的0.5，并假设基线内存为1 GB左右。 我们还假设10个线程并发。 在这样大小的计算机上不太可能有200个线程，也不太可能是1个，因此10个公平的开始。 我们还假设一旦知道一个副本可以完成多少工作，我们就可以拥有尽可能多的副本来满足性能标准。

现在，我们需要考虑应用程序的功能，并适当地移动这些控制杆。

• 是否依赖外部参考数据？ –也许我们需要一个缓存来避免不断获取数据
• 是否需要大量缓存？ –如果是这样，我们需要更多的内存
• 填充缓存是否昂贵（大量的网络时间或对下游资源的需求）？ –如果是这样，我们需要考虑减少副本，并通过增加一个实例可以处理的请求数量来获得每个缓存实例的好处
• 请求是否占用大量内存？ –通过并发线程数增加内存
• 请求是否占用大量CPU？ –更多的CPU，或更少的并发任务
• 请求对CPU的使用量很大吗？ –这有理由赞成减少并发性，而不是增加CPU。
• 服务是否依赖于受约束的下游服务？ –这表明副本数较少，每个副本并发性更高，并且在受限资源上使用连接池。
• 服务是否依赖昂贵的可缓存资源？ –这建议使用缓存服务，而不是内置缓存。 缓存服务意味着您可以拥有更多副本，而不会增加下游资源的负载。

利用上述经验法则，您可以上下乘以CPU，内存，副本等的初始值，并进行一些初始调整……这些规则将为您提供一个起点……也许……

但是更多，比这更多？

当我开始写这篇文章时，我考虑过我可能会尝试输入一些有用的数字。我想我什至可能会说一些类似的事情： 如果CPU占用过多，则将CPU占用15％，如果内存占用过多，将并发数除以3…

但是……发明数字实在没有任何意义。 您需要做的就是以恒定的高负载（不中断）运行应用程序，并查看其性能。 监视CPU和堆。 如果它们正在运行，请冷却应用程序或添加资源。 考虑开销与有价值的工作的吞吐量之比，并加以考虑。

我希望这有帮助。

翻译自: https://www.javacodegeeks.com/2019/09/tuning-parallel-processing-containers.html

容器docker并行计算