环境搭建踩坑记

测试环境选了3台阿里云ECS（4核8G），装Docker 20.10社区版时遇到内核兼容问题。解决方法其实简单：①centos系统要升级到7.9以上 ②关闭selinux ③安装cgroup驱动补丁。关键是要配置daemon.json里的资源参数：

性能测试三板斧

基准测试耍了个花招

用docker stats监控时发现数据有延迟，后来改用cAdvisor+Prometheus组合。在容器启动参数里加入--memory=2g --cpus=1.5后，某个Python服务的QPS从1200提升到2100，原因是限制了CPU时间片争夺。

网络性能的玄学

用iperf3测试桥接网络时，发现MTU值严重影响吞吐量。在docker-compose里显式设置network_mode: "host"后，延迟从3ms降到0.8ms。但宿主机模式要注意安全隔离，我们在预发环境实测时误操作差点引发ARP风暴。

存储性能的坑

最开始用默认的overlay2存储驱动，随机写性能只有32MB/s。后来给MySQL容器挂载direct-lvm卷，配合wirteback缓存策略，IOPS直接翻了三倍。关键要记得在mount参数加上noatime。

实战中的骚操作

压测SpringBoot应用时遇到个诡异现象：容器内JVM的GC时间比物理机长3倍。最后发现是Docker的CPU调度策略问题，在docker run里加入--cpu-shares=1024 --cpuset-cpus=1-3后，YoungGC时间从180ms降到60ms。还有个经验是别在容器里跑jstat，这玩意在cgroup环境里读数不准。

监控要用组合拳

我们最后搭的监控方案：cAdvisor收集容器指标+NodeExporter抓主机数据+Grafana做看板。特别要关注的是容器内存使用率（包括cache和rss）与宿主机OOM Killer的关联性。有次Redis容器被突然杀灭，就是因为在alertmanager里没配置memory.failcnt阈值。

总结的血泪教训

别相信默认配置，尤其是网络和存储驱动

Swarm集群模式下要特别注意跨节点通信成本

Java应用务必设置-XX:+UseContainerSupport参数

分布式压力测试时记得同步时钟，我们曾因ntp偏差导致20%的异常请求

现在我们的CI流水线里集成了docker-bench-security扫描，所有镜像打包时都必须通过delly性能测试套件。最近还在试验使用ebpf跟踪容器系统调用，这套方案确实比传统虚拟机环境复杂，但一旦趟过坑，后续的运维效率能提升好几个量级。