Linux容器资源调优需设内存、CPU、IO和网络限制以保障稳定：内存用-m和--memory-swap=0防OOM；CPU优先用--cpus控制配额，高要求场景辅以--cpuset-cpus绑定核心；IO与网络需限速兜底；所有配置须通过docker stats、inspect及cgroup文件验证，并结合压测持续优化。
Linux 容器（如 Docker）默认会尽可能使用宿主机资源，不加限制可能导致服务争抢、系统不稳定甚至宕机。性能调优的核心不是“压榨极限”，而是通过合理设置资源边界，保障关键服务稳定、提升资源利用率，并避免单个容器失控影响全局。
内存限制：防止 OOM 和内存抖动
Docker 默认不限制内存，容器可无节制申请，一旦触发宿主机 OOM Killer，可能误杀重要进程。必须显式设置 -m 或 --memory，并建议同时配置 --memory-swap=0（禁用 swap）以避免延迟不可控。
- 设为略高于应用常驻内存（如 Java 应用堆+元空间+本地内存总和的 1.2~1.5 倍），留出缓冲空间
- 配合
--oom-kill-disable=false（默认开启），让内核在超限时主动 kill 容器主进程，而非随机选进程 - 观察
docker stats中MEM USAGE / LIMIT和MEM %，持续接近 90% 说明需扩容或优化应用内存使用
CPU 限制：控制抢占与保障响应
CPU 限制分两种逻辑：CFS 配额（--cpus）适合稳态负载，CPUset（--cpuset-cpus）适合绑定物理核心、降低跨核开销。生产环境推荐优先用 --cpus，更易量化与弹性伸缩。
-
--cpus=1.5表示该容器最多使用 1.5 个逻辑 CPU 的时间片（非固定核心），适用于大多数 Web/API 服务 - 高吞吐批处理或低延迟服务（如实时音视频转码）可结合
--cpuset-cpus="0-1"绑定专用核心，减少上下文切换 - 避免设置过低（如
--cpus=0.1）导致任务积压；也避免设过高（如--cpus=8在 4 核机器上）引发调度竞争
IO 与网络：隐性瓶颈不容忽视
磁盘 IO 和网络带宽虽不如 CPU/内存直观，但在数据库、文件服务、微服务间高频调用场景中极易成为瓶颈。Docker 提供基础限速能力，适合做兜底控制。
- 块设备限速：
--device-read-bps /dev/sda:10mb --device-write-bps /dev/sda:5mb控制读写吞吐，防止慢盘拖垮整机 - 网络限速需借助
tc+ 自定义网络驱动或运行时注入规则，简单场景可用docker network create --opt com.docker.network.driver.mtu=1400间接影响传输效率 - 对 I/O 密集型容器（如 PostgreSQL），建议挂载 hostPath 或使用 local volume，并关闭
copy-on-write层（如用overlay2的volatile模式）减少写放大
监控与验证：调优闭环的关键一环
所有限制都需配套可观测性，否则等于“盲调”。不依赖第三方工具也能快速验证效果：
- 实时查看：
docker stats --no-stream <container></container>获取当前 CPU、内存、网络、IO 使用率 - 查限制配置：
docker inspect <container> | jq '.[].HostConfig.Memory, .[].HostConfig.NanoCpus, .[].HostConfig.CpuPeriod'</container> - 查内核 cgroup 状态：
cat /sys/fs/cgroup/memory/docker/<cid>/memory.limit_in_bytes</cid>（内存）、cat /sys/fs/cgroup/cpu/docker/<cid>/cpu.cfs_quota_us</cid>（CPU 配额） - 压力测试对比：用
stress-ng或业务流量压测前后，观察延迟 P95、错误率、宿主机 loadavg 变化
资源限制不是越严越好，也不是设完就一劳永逸。它需要结合应用行为建模、真实负载压测和持续指标反馈来动态调整。一次合理的调优，往往比盲目升级硬件更能解决稳定性问题。
