盾已经到 LGD 基地了，八王能不能给 XinQ Sama 来个炸弹人-.-

1. 先根据机器内存设置一个 pm.max_children （ memory/20m ）
2. 压测，观察 php-fpm 的 active 和 idle 进程数 及 机器的 cpu，看哪个指标先成为瓶颈，再根据具体目标调整配置继续优化。

@Maco 谢了，终于明白为啥出现这种情况了-.-。 告警和恢复只能用同一个 description 的消息模板吗，有方法区分开吗。告警时显示当前 cpu 值，恢复了就显示 cpu 已恢复加个 grafana link 。

@scarletass 峰值？ 这个{{ printf "%.2f" $value }} 也是 expr 算出来的值啊。

@cdlixucd 嗯，好文。这里有提到 scrape 和 evaluation 不一致产生的问题，但 send resolve 通知应该不受这个影响。既然发出通知来，一定是判定至少 2 个周期（我这边 scrape 和 evaluation 都是 30s ）值低于 90 。恢复通知上的值肯定低于 90 才对。

@lipd 嗯，这个比较好划分。但直接面向用户的业务呢，是怎么划分的？

@monkeyWie 每个项目组一个？ 你们每个项目组手下也是负责多个服务吗？ ns 如何命名的？

@ohoh 在资源充足的情况下，不同的环境应该对应不同的集群吧（ dev,fat,uat,pro ）？ 同一个环境集群内的 ns 怎么划分呢？

@binux 可以举个例子吗？ 业务的粒度大概是指？

@iwuzhuo 好的，thx

@iwuzhuo 感谢。那方便问一下 pm=10 的基准下，cpu 的 requests 和 limits 是怎么限制的吗？

@iwuzhuo 嗯，是 laravel。我现在设的就是 10，考虑对于生产环境会不会偏小？ 以 10 为基准的话，感觉一个业务高峰期的 pod 数量需要横向扩大很多倍。单个容器的配置和数量之间怎么比较好的取得一个平衡？

加油，会一直关注

@realpg 哈哈，其实我也觉得... 但短时间内重构又不太现实，所以只能先从架构上看看了。

@yzhfd thx，性能分析这块确实要做。每次并发量上来，php-fpm 一定是 cpu 100%的。缓存目前涉及到的有 cdn, lua, opcache, redis。

@realpg 谢谢理解，您说的对。想看看大家遇到这类问题时会怎么考虑，每一句话都可能是一个新的思路。

@myvyang thx, 我也觉得集群模式方便管理及扩缩容。服务器上基础组件的版本都是一致且运行了很长时间的，所以 bug 这个问题就不在考虑范围内了。

@jowan thx，从语言框架上优化性能短期可能不会考虑。部署的思路上面有推荐吗？

@Varobjs 哈哈，只是想拓宽一下思路，看看大家怎么做的，取长补短。