为什么我的优化求解器在Docker中运行速度变慢了？

Question

我对Docker非常陌生，最近编写了一个Dockerfile来容器化数学优化求解器SuiteOPT。但是，在测试几个问题的优化求解器时，我发现在docker内部的性能比外部慢。例如，一个线性规划（demoLP.py）的演示问题在我的机器上需要大约12秒才能解决，但在docker中需要大约35秒。我已经花费了大约一周的时间查看博客和stackoverflow帖子以寻找解决方案，但无论我做出什么更改，docker的计时始终为大约35秒。是否有人知道可能发生了什么，或者能否指导我正确的方向？

以下是优化求解器Docker Hub和PYPI页面的链接： SuiteOPT Docker Hub SuiteOPT PYPI 页面 < p > < em > 编辑1 ：由于@user3666197的评论，我添加了一个额外的想法。虽然我并不期望SuiteOPT在docker容器中表现得很好，但我对这个演示问题的~3倍减速感到惊讶。也许问题可以重新阐述如下：< strong > 如何确定这种减速纯粹是因为我正在执行CPU-RAM-I/O密集代码而不是由于我的Dockerfile配置存在其他问题所致？

注意：容器化的目的是为了为用户提供一种简单的方式来开始使用Python中的优化软件。虽然优化软件可在PYPI上获得，但有许多非Python依赖项可能会导致人们希望在不遇到安装问题的情况下使用该软件时出现问题。

- chrundle

---

除了使用容器为众人合理重复或大规模部署预配置的准备好的生态系统带来无疑的积极影响，以一种几乎类似COTS的方式，是什么让你认为任何这样的Docker容器技术将导致在抽象容器内执行{CPU- | RAM-I/O}-密集型代码没有任何负面影响 - 无论是运行抽象/容器化引擎的附加成本（读取速度较慢），还是可怕的浪费L1/L2/L3缓存有效重用效果，这些都不会发生在容器内？ - user3666197

您可能需要通过使用像 perf 这样的工具，通过分析您的具体情况来深入挖掘。例如在这篇文章中：Another reason why your Docker containers may be slow，性能不佳是由于用于记录日志的库而导致的。要直观地查看 perf record ... 捕获的内容，请查看 Flame Graphs 和 Netflix FlameScope。 - tgogos

始终欢迎@chrundle。正如Anastasios在上面发布的那样，极其不良的低效率来自于C组之间巨大的交叉依赖共享 - 这是[标签：分布式系统]中性能猎人最大的罪恶。让我提出一个A / B / C测试 - 在裸机上运行相同的[A] +接下来在虚拟机内部运行（可以使用VmWare工具将裸机“打包”为VM + VmWare Player供私人使用），仍然在同一台裸机设备[B]上+与容器相同[C] ---如果性能很重要，则VM隔离与Docker共享C组方法的数据将告诉您。 - user3666197

我在这里做了一些笔记：github.com/tgogos/flamescope_test。我不确定，但它们可能会有所帮助 :-) - tgogos

@user3666197 我也进行了一些实验，以查看使用docker桥接/发布端口与使用--net=host的成本差异，您可以在此问题中找到：在Docker容器中运行nginx时出现性能问题。我不得不运行测试两次，做2个不同的perf record ...并比较后来2个不同的火焰图的结果。我认为当容器拥有自己的网络堆栈时花费的额外时间在图片中是显而易见的。 - tgogos

Answer 1

Q : 如何确定这种减速纯粹是因为我在docker容器内执行了一个CPU-RAM-I/O密集型代码，而不是由于Dockerfile配置的其他问题引起的？

战场：

_{( Credits: Brendan GREGG )}

步骤0：收集有关主机端运行处理的数据：

---

 mpstat -P ALL 1 ### 1 [s] sampled CPU counters in one terminal-session (may log to file)

---

 python demoLP.py  # <TheWorkloadUnderTest> expected ~ 12 [s] on bare metal system 

---

步骤1：收集有关Docker容器内相同处理的数据

此外，还要查看在--cpus和--cpu-shares中设置的策略（如果使用了，则还可能包括--memory+--kernel-memory），以及在throttled_time中显示的影响（参见第13页）

cat /sys/fs/cgroup/cpu,cpuacct/cpu.stat
nr_periods 0
nr_throttled 0
throttled_time 0 <-------------------------------------------------[*] increasing?

请审查Docker容器的工作负载视图，从外部角度看待问题：

cat /proc/<_PID_>/status | grep nonvolu ### in one terminal session
nonvoluntary_ctxt_switches: 6 <------------------------------------[*] increasing?

---

systemd-cgtop                           ### view <Tasks> <%CPU> <Memory> <In/s> <Out/s>

步骤 2：

使用上述流程图，将观察到的指标与设置的绝对 CPU 上限 策略和 CPU 分享 策略进行比较。

- user3666197