如何加快Docker run与Docker exec命令执行速度？耗时问题排查求助

Let’s break this down clearly: your user and kernel time (0.02s each) only measure the actual command execution inside the container—the 0.5s total lag is almost certainly coming from Docker’s overhead for setting up/tearing down container resources or external system bottlenecks. Here’s how to diagnose and fix this:

First: Pinpoint Where the Time is Going #

Before optimizing, let’s narrow down the root cause with these quick tests:

1. Distinguish docker run vs docker exec Overhead #

• If you’re using docker run every time (creating a new container each time), run:

  time docker run --rm your-ubuntu-image echo "test"
  

• Then start a long-running container once, and test docker exec:

  docker run -d --name reusable-container your-ubuntu-image sleep infinity
  time docker exec reusable-container echo "test"
  

If the exec time drops significantly (e.g., to 0.1s or less), the problem is the container creation/teardown overhead—this is the biggest culprit for most cases. If exec is still slow, we’ll dig into other factors.

2. Test Network Overhead #

Docker’s default bridge network adds overhead for creating network namespaces, configuring iptables rules, and assigning IPs. Test if this is the issue:

time docker run --rm --network none your-ubuntu-image echo "test"

If this runs faster, network setup is a major contributor to the latency.

3. Check Storage/IO Bottlenecks #

Even if your image size doesn’t affect latency, container storage setup (mounting layers, writing to log files) can lag on slow disks. Test with a tmpfs to bypass disk writes:

time docker run --rm --tmpfs /tmp your-ubuntu-image echo "test"

Also, verify your storage driver with docker info | grep "Storage Driver"—ensure you’re using overlay2 (the most efficient default for Ubuntu).

4. Trace Docker Client/Server Operations #

Use strace to see exactly which system calls are taking time:

strace -tt -o docker_trace.txt docker run --rm your-ubuntu-image echo "test"

Open docker_trace.txt and look for lines with large time gaps (e.g., delays connecting to the Docker daemon, waiting for network setup, or disk I/O).

Optimizations to Reduce Latency #

Once you know the cause, here are the most impactful fixes:

1. Reuse Containers (Biggest Win) #

Instead of creating a new container for every command, keep a single long-running container and use docker exec to run commands inside it. This eliminates all overhead of creating network/storage/IPC namespaces each time. For example:

# Start once and keep running
docker run -d --name persistent-container your-ubuntu-image sleep 86400
# Run commands as needed
docker exec persistent-container your-command

This can cut latency from 0.5s to under 0.1s in most cases.

2. Optimize Network Configuration #

• If you don’t need network access for your command, use --network none to skip network setup entirely.
• If you need host network access, use --network host to avoid creating a separate network namespace.
• For recurring containers, create a custom bridge network upfront (instead of using the default bridge)—Docker caches network setup for custom networks, reducing overhead.

3. Tweak Docker Daemon Settings #

Edit /etc/docker/daemon.json (create it if it doesn’t exist) to disable unnecessary features:

{
  "ipv6": false,
  "log-driver": "local",
  "storage-driver": "overlay2"
}

• Disabling IPv6 skips configuring IPv6 rules for containers.
• The local log driver is faster than the default json-file for short-lived containers (avoids immediate disk writes for logs).
• Restart Docker after changes: systemctl restart docker.

4. Fix System-Level Bottlenecks #

• Disk IO: Use iostat 1 to check if your disk is under heavy load. Slow spinning disks or overloaded SSDs can delay container setup.
• Memory: Ensure your system isn’t swapping (free -h). Swap usage can drastically slow down Docker operations.
• Docker Daemon Load: Check docker stats to see if the Docker daemon is using excessive CPU/memory. Restarting the daemon (systemctl restart docker) can sometimes resolve accumulated overhead.

5. Use a Minimal Base Image (Optional) #

While you noted image size doesn’t affect latency, using a slimmer base image like ubuntu:minimal or alpine (if compatible with your workload) can reduce minor overhead for layer mounting. This is less impactful than reusing containers, but worth trying if you need extra gains.

Final Notes #

The 0.5s latency you’re seeing is typical for fresh docker run commands due to all the resource isolation steps Docker performs. Reusing containers is by far the most effective way to cut this down to acceptable levels. If docker exec is still slow after that, dig into the strace logs or check for system-level bottlenecks like disk IO or daemon performance.

内容的提问来源于stack exchange，提问作者Karol Pokorski