服务拖垮整台主机容器共享主机的CPU、内存和I/O。若一个服务出现线程风暴、缓存膨胀或内存泄漏，它可能挤占其他容器和系统进程的资源。资源限制可以缩小故障影响范围，但限制过低也会制造节流、OOM和重启。应根据真实工作负载设置边界，并用指标判断边界是否合适。⚖️
CPU通常通过份额、权重或配额控制竞争资源时的分配。限制并不意味着应用可以稳定获得对应算力：当容器持续触碰配额时，进程可能在一个周期内被节流，造成尾延迟升高。内存限制则常作为硬边界，容器超限时内核可能触发OOM终止进程。CPU和内存不可用同一套平均值估算。
主机容量规划还要为操作系统、容器运行时、监控代理、日志采集和磁盘缓存保留余量。容器限制总和若接近物理资源，多个服务同时达到峰值时仍可能出现争抢。应按节点可用容量和副本分布计算上界，而不是把主机标称资源全部分配出去。🧮
内存观测不能只看某一瞬间的总使用量。要区分匿名内存、可回收文件缓存、应用工作集和短暂峰值，并关注OOM事件与容器重启。若应用常驻工作集长期接近硬限制，任何流量峰值、垃圾回收或后台任务都可能触发OOM。设置上限时，应覆盖代表性峰值并保留安全空间，同时确认应用在压力下能够降载或失败得可控。
CPU方面要同时看使用量、节流时间、请求延迟和队列长度。只看CPU使用百分比可能忽略容器已被配额限制；节流持续上升且尾延迟同步变差，是配额偏紧的重要信号。只读命令docker stats可快速查看容器CPU和内存实时用量，但不替代历史趋势和主机级指标。📊
先在正常流量、峰值时段和批处理任务期间采集基线，再进行可控压力测试。记录每类请求的吞吐、延迟分位数、CPU节流、内存工作集、GC暂停、队列长度和错误率。设定限制后逐步提高负载，观察性能退化点，而不是把实验室最优值直接用于生产。
应用进程可能根据主机可见内存自动配置堆大小或线程数；若它看不到容器限制，可能按宿主机资源过度分配。要确认运行时是否正确识别容器边界，并为本地缓存、线程栈、原生库和内存映射预留空间。堆上限不等于进程总内存上限。🧠
单容器的安全限制还要乘以同节点最大副本数，并叠加系统与守护进程的需求。若服务有突发流量，自动扩缩容期间新副本会暂时增加资源需求；若节点上多个服务同时扩容，单服务看似合理的限制也可能超过主机容量。应确定节点保留量、调度时的资源声明和运行时硬限制如何对应。
遇到OOM时检查容器退出原因、内核事件、内存曲线及业务请求规模，区分泄漏、缓存无界增长、单次大请求和配置变化。CPU高则观察线程数、队列和热点路径；CPU低但延迟高，可能是I/O等待、锁竞争或CPU节流导致的执行间隙。🔎
容易误判：降低容器上限不等于优化了资源效率。如果吞吐下降、队列增长或重启增加，故障只是从主机资源争用变成应用性能退化。🛡️
