在 Docker 下运行时出现奇怪的服务性能下降答案

【问题标题】：Strange service performance degradation when running it under Docker在 Docker 下运行时出现奇怪的服务性能下降
【发布时间】：2023-01-08 04:13:26
【问题描述】：

在分布式 API 的上下文中，我正在处理一个“Giga”服务，它消耗大约 15 Gb 的内存并且至少需要四个 CPU。在引导过程中，服务必须加载四个文件才能可用。

在我的笔记本电脑上，当我在没有 docker 的情况下运行该服务时，我的意思是，当我从 shell 运行它时，该服务需要大约 9 秒才能激活。服务激活后，对该服务的 240 次调用大约需要 7 秒。

现在，当我在笔记本电脑上运行完全相同的服务时，但这次是在 Docker 容器下，加载文件并激活需要大约 6 分钟。当我准确执行上述 240 次调用时，服务大约需要 5.5 分钟！！！！

这是我第一次发现类似的问题，而且由于我不是 Docker 大师，我想知道是否有人可以给我提供有关可能发生的事情的线索。

这是 Dockerfile 的内容：

FROM alpine:3.16 as dag_build

RUN apk add g++ make protobuf protobuf-dev grpc-dev \
    pkgconfig git gsl-dev tclap-dev

RUN mkdir -p /usr/src/dag_service
WORKDIR /usr/src/dag_service
    
COPY model_services/protos/dag.proto /usr/src/protos/dag.proto

COPY model_services/dag/*.H /usr/src/dag_service/
COPY model_services/dag/dag_service.cc /usr/src/dag_service
COPY model_services/dag/Makefile /usr/src/dag_service
    
RUN cd /usr/src/dag_service; make dag_service

COPY model_services/dag/nfl_graph_q[1234]_130.txt.bz2 /usr/src/dag_service/

RUN cd /usr/src/dag_service; bunzip2 nfl_graph_q[1234]_130.txt.bz2

COPY model_services/dag/q[1234].Tree /usr/src/dag_service/

##################################################
# Run the dag service
FROM alpine:3.16 AS dag_runtime

RUN apk add protobuf-dev grpc-dev 
    
COPY --from=dag_build /usr/src/dag_service/nfl_graph_q[1234]_130.txt /bin/
COPY --from=dag_build /usr/src/dag_service/q[1234].Tree /bin/
COPY --from=dag_build /usr/src/dag_service/dag_service /bin/dag_service

WORKDIR /bin/

RUN mkdir -p /tmp
EXPOSE 6003
RUN chmod a+x dag_service

CMD ["./dag_service", "-s", "1 0 900 75 -1 3 3", "-s", "2 0 900 75 -1 3 3", "-s", "3 0 900 75 -1 3 3", "-s", "4 0 900 75 -1 3 3", "-d", "nfl_graph_q1_130.txt", "-d", "nfl_graph_q2_130.txt", "-d", "nfl_graph_q3_130.txt", "-d", "nfl_graph_q4_130.txt", "-p", "q1.Tree", "-p", "q2.Tree", "-p", "q3.Tree", "-p", "q4.Tree", "-m", "3e-8", "-l", "0.99"]

该服务是用 C++ 编写的。

我的笔记本电脑运行 Linux，Ubuntu 22.04

【问题讨论】：

你在什么平台上使用 Docker？您是否在使用虚拟机实现的平台上使用它？例如。操作系统，视窗。
谢谢你的关注。我正在使用 Linux，具体来说是 Ubuntu 22.04。我在帖子中没有提到的一件事，问题也出在运行 K8S 的 AWS 中
这是自我管理的 kubernetes，还是 ECS，还是别的？ Docker 版本的运行方式与非 Docker 版本的运行方式有何不同？
我们使用ECS。独立服务就像命令行一样运行，类似于 shell 中的 /dag_service -s "1 0 900 75 -1 3 3" -s "2 0 900 75 -1 3 3" -s "3 0 900 75 -1 3 3" -s "4 0 900 75 -1 3 3" -d nfl_graph_q1_130.txt -d nfl_graph_q2_130.txt -d nfl_graph_q3_130.txt -d nfl_graph_q4_130.txt -p q1.Tree -p q2.Tree -p q3.Tree -p q4.Tree -m 3e-8 -l 0.99

标签： docker

【解决方案1】：

最后，我找到了问题的原因，或者至少是它的症状：问题出在 Alpine 上。我用取自 docker 库的名为 grpc/cxx:latest 的图像替换了 Alpine 图像，一切开始按预期工作。性能类似于裸流程执行。

了解 Alpine 做了什么或拥有什么导致如此显着的性能下降会很有趣。另外，为什么有人，至少在这个论坛上，遇到过类似的问题？

【讨论】：

Alpine 使用 musl libc，它的构建是为了优化紧凑性和正确性而不是性能，而 glibc 优化性能而不是代码大小（添加许多特定于体系结构的优化等）。要确定为什么这对您的案件如此重要，这将是一项非常注重事实的调查；像 oprofile 这样的工具可能是我可以到达的地方。
也就是说，Stack Overflow 不是一个论坛。我们不欢迎“类似经历”的请求——我们的目标是提出具有规范答案的狭窄、具体的问题。将其归结为一个更具体的问题可能需要使用探查器进行调查以确定 Alpine（以及可能是其 libc）中的哪个特定调用速度慢，构建一个 minimal reproducible example 以及一个微基准测试来执行该调用，并询问该问题更狭义。