CMS参数优化，数优说白了就是化步跟服务器讨价还价。你给它太多活儿，流程它撂挑子；你让它闲着，数优又浪费钱。化步我调过一台WordPress站，流程日均两万PV，数优MySQL默认配置下，化步每秒查询数飙到80，流程CPU直接红温。数优后来只改了三个参数，化步查询数降到15，流程页面加载时间从3.2秒缩到0.8秒。数优这事让我明白，化步优化不是流程玄学，是算账。

第一步，先看内存。别急着改任何配置，先跑`free -m`和`top`。你机器有8G内存，PHP-FPM占掉4G，MySQL占掉2G，剩下2G给系统和其他服务。这时候你非要把`innodb_buffer_pool_size`设成6G，那不是优化，是自杀。我见过太多人上来就抄网上大神的配置，结果内存爆了，Swap狂转，网站比蜗牛还慢。正确做法是，buffer pool设为物理内存的50%到60%，但要留出余量给PHP和Nginx。比如8G内存，MySQL拿3G到4G，PHP-FPM限制在1.5G以内，剩下1G给系统缓存。

第二步，查慢查询日志。这一步很多人跳过，觉得麻烦。但你不看日志，怎么知道瓶颈在哪？打开MySQL的`slow_query_log`，设个阈值，比如2秒。跑一天，看看哪些查询拖后腿。我遇到过一个案例，某个插件每五分钟跑一次全表扫描，查询要4秒。你光调参数没用，得先治这个病。要么优化SQL，加索引，要么直接砍掉这个插件。参数优化是锦上添花，不是雪中送炭。病根不除，调什么都是白搭。

第三步，动PHP-FPM的进程数。这个参数跟你的服务器CPU核心数直接相关。假设你有4核CPU，每个PHP进程处理一个请求，大概占20M内存。那么`pm.max_children`设成20到30就差不多了。设太多，内存不够；设太少，并发一高就排队。我习惯用`pm = dynamic`模式，设`pm.start_servers`为CPU核心数的两倍，`pm.min_spare_servers`为一半，`pm.max_spare_servers`为核心数的三倍。这样系统能根据流量自动调整，不会一下子被冲垮。

第四步，处理Nginx的缓冲区。CMS站点经常有大的响应头，比如Cookie或者自定义header。默认的`proxy_buffer_size`只有4K或8K，不够用的话，Nginx会报502或者504。我调过一台服务器，每次用户登录就报错，查了半天，就是缓冲区太小，存不下完整的响应头。改成16K后，问题秒解。同理，`client_max_body_size`如果默认是1M，你上传大图片或者附件就会失败，改成10M或20M比较稳妥。

还有个容易忽略的点，是PHP的`memory_limit`。CMS的插件和主题经常吃内存，尤其是一些页面构建器，跑一次就要几十M。默认的128M可能不够，调到256M甚至512M都行，但别盲目调高——内存是有限的，你给PHP多了，给MySQL的就少了。我一般先看error log，如果频繁出现`Allowed memory size exhausted`，才去调这个值，调到刚好不报错为止，不给自己留太多余量。

最后，别忘了一个最基础的参数——`max_execution_time`。CMS后台经常有批量操作，比如更新插件、导入数据。如果默认30秒超时，任务跑到一半就断了，数据可能损坏。我习惯设成300秒，前台请求基本用不到这么长，但后台操作能安稳跑完。代价是，如果真有个死循环，得等5分钟才被掐死——所以还得配合`max_input_time`一起设，别让用户那边等太久。

这些参数调完，记得压测。别用浏览器刷新，那不算数。用`ab`或者`wrk`，模拟100个并发，跑个30秒，看平均响应时间和错误率。我调完参数后，通常会观察一周，看CPU和内存的负载曲线。如果峰值时内存用了80%以上，就再降一点；如果CPU一直闲在20%以下，说明还有余量，可以加大并发处理能力。参数优化不是一锤子买卖，是动态平衡。你网站流量涨了，或者装了新插件，就得重新算一遍账。