已关闭此问题为not about programming or software development。它目前不接受回答。

这个问题似乎不是关于a specific programming problem, a software algorithm, or software tools primarily used by programmers的。如果你认为这个问题与another Stack Exchange site的主题有关，你可以留下评论，解释在哪里可以回答这个问题。
9天前关闭
Improve this question
我最近在一台服务器上遇到了网络问题，我们客户的网络团队解决了这个问题。然而，在这些网络问题之后，我们的两台服务器中的一台在运行各种Docker命令时开始出现严重的延迟，包括docker info，docker stats，docker pull和docker exec。一切都是令人难以置信的滞后。当我尝试执行以下命令时：

curl --unix-socket /var/run/docker.sock http:/v1.41/version

我在大约2分钟后收到回复。/var/run/docker.sock上的权限与以前相同。
我已经使用systemctl reload在Docker守护进程上启用了调试日志（因为重启不是一个选项）。令人惊讶的是，正在运行的容器没有延迟。Docker守护进程与containerd或Docker套接字之间的通信出现了明显的延迟。

可重复步骤：

运行上面提到的curl命令，观察响应时间是否过长。尝试运行任何Docker命令。我会花很长时间，但最终会成功的。

**错误和错误消息：**以下是一些相关的日志条目：

Oct  5 11:16:23  dockerd[3206492]: time="2023-10-05T11:16:23.199617113Z" level=debug msg="Calling GET /version"
Oct  5 11:16:34  dockerd[3206492]: time="2023-10-05T11:16:34.653406950Z" level=debug msg="Calling GET /containers/json?"
Oct  5 11:18:23 dockerd[3206492]: time="2023-10-05T11:18:23.213966222Z" level=debug msg="Calling GET /networks"
Oct  5 11:18:23  dockerd[3206492]: time="2023-10-05T11:18:23.214702025Z" level=debug msg="Calling GET /info"
Oct  5 11:20:23  dockerd[3206492]: time="2023-10-05T11:20:23.216083013Z" level=debug msg="Calling GET /version"
Oct  5 11:21:34  dockerd[3206492]: time="2023-10-05T11:21:34.658572875Z" level=debug msg="Calling GET /containers/json?"
Oct  5 11:22:23  dockerd[3206492]: time="2023-10-05T11:22:23.223637644Z" level=error msg="exit event" container=89faab1572fe13b55010b527de07f921d75a9e04df748e57475f885297446367 error="no such exec" module=libcontainerd namespace=moby process=a2c

Oct  5 10:48:23 dockerd[3206492]: time="2023-10-05T10:48:23.076483516Z" level=debug msg="Calling GET /networks"
Oct  5 10:48:23  dockerd[3206492]: time="2023-10-05T10:48:23.077129060Z" level=debug msg="Calling GET /info"
Oct  5 10:48:31  dockerd[3206492]: time="2023-10-05T10:48:31.423932065Z" level=debug msg="FIXME: Got an API for which error does not match any expected type!!!: timeout waiting for exec session ready" error_type="*errors.errorString" module=api

意见：

这个问题似乎是一致的，并影响各种Docker命令。运行容器性能良好，没有延迟。延迟似乎与Docker守护进程和containerd之间的通信有关。

环境详情：

**Operating System:** 
NAME="Oracle Linux Server"
VERSION="8.7"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.7"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.7"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:7:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.7
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.7

**Docker Version**: 
Client: Docker Engine - Community
 Version:           20.10.22
 API version:       1.41
 Go version:        go1.18.9
 Git commit:        3a2c30b
 Built:             Thu Dec 15 22:28:05 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.22
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.9
  Git commit:       42c8b31
  Built:            Thu Dec 15 22:26:16 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.15
  GitCommit:        5b842e528e99d4d4c1686467debf2bd4b88ecd86
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

**代理配置：**HTTP和HTTPS代理在系统环境变量中设置。

• 具体问题：**

为什么在Docker Unix套接字上的curl命令在网络问题后如此缓慢？我是否可以采取其他故障排除步骤来确定延迟的原因？网络问题是否会导致此延迟？如果是，如何解决？

**预期结果：**我希望通过Unix套接字的Docker命令能够迅速响应，就像网络问题发生之前一样。这是第二次发生这种情况，也是我第一次重新启动（并且解决了）Docker服务。现在它不再是一种选择。
**结论：**我需要帮助来理解和解决使用Docker Unix socket时响应慢的问题。我将感谢任何见解或指导，以进一步解决和解决这个问题。