理解进程管理的三种模式
固定模式在启动时就把固定数量的进程创建好，没有派生开销，适合流量稳定且内存充足的场景。进程数写死，扩容只能改配置后重启。
动态模式按负载在最小与最大之间伸缩，是多数站点的默认选择。空闲进程会被回收，代价是流量突增时创建进程有延迟。
按需模式在请求到来时才创建进程，空闲时不占资源，适合低频访问的站点或后台服务。请求间隔长时表现好，高频场景下反复创建销毁得不偿失。选择哪种模式还要看部署方式，容器环境下频繁创建进程的代价会被放大。
进程数量怎么估
关键约束是内存。用单进程的常驻内存乘上最大进程数，不能超过可用物理内存，还要给系统和其他服务留出余量，否则会触发交换甚至被系统杀掉。
在压测中观察进程池是否长期打满。长期运行在最大进程数说明配置偏小，但如果此时处理器已经饱和，加进程只会加剧上下文切换。
不要为了降低单次响应时间无限制加进程。每个进程是单线程模型，进程数超过可用核心数十倍上百倍后，调度开销会吞掉收益。压测时逐步增加并发，记录响应时间开始明显上升的拐点，那里就是容量边界。
排队、超时与上游配合
请求排队长度决定突发情况下有多少请求能等待而不被拒绝。设得太小，突增流量会直接返回错误；设得太大，用户等到超时也没有意义。
执行超时要和上游的网关、负载均衡超时形成梯队，内层必须小于外层，否则外层断开后内层还在空转，白白占用进程。
慢请求日志要开启并设一个合理阈值。定位到底是哪类请求拖住了进程池，比单纯加大进程数更有价值。
与上游的连接方式、缓冲区大小、超时都要匹配。缓冲区过小会导致大响应体被截断或走临时文件，增加磁盘压力。部署切换时用平滑重载而不是直接重启，让正在处理的请求先结束。
长连接与外部依赖
数据库、缓存的连接数由进程数放大。每个进程各持一条连接时，最大进程数就是最大连接数，容易击穿下游的连接上限。
使用连接池中间件可以把连接与进程解耦，但要确认事务和会话状态在复用连接上是干净的，否则会出现串数据这类严重问题。
耗时任务不要占用网页进程，交给队列异步执行。同步的导出、大批量写入、外部接口聚合，都是拖垮进程池的典型场景。
观测什么指标
进程池的活跃进程数、空闲进程数、队列长度、达到上限的次数，这几项能覆盖大部分容量问题。定期看趋势比出问题再查更有效。
把慢请求按地址归集，找出最耗时的接口。优化一个高频慢接口对整体容量的贡献，往往大于反复调整进程参数。把指标按天留存，容量规划时才能看出增长趋势而不是只看当下水位。
