大家好。我拥有一台配置不高的云服务器（2核4G），上面承载着多个个人网站，主要是WordPress和一些静态页面。随着站点数量增加，我开始感受到服务器资源的压力，这促使我踏上了一条系统性的服务器性能优化之路。
这篇笔记是系列文章的第一篇，将重点记录我在不触及复杂数据库调优的前提下，通过优化PHP环境，为服务器“减负”并为后续扩展“腾出空间”的完整过程。
一、优化前的服务器状况
在开始任何操作前，先盘点一下服务器的初始状态，这有助于我们明确优化的目标。
- 服务器配置：2核CPU, 4GB内存。
- 承载应用：3个WordPress网站 + 2个纯静态HTML页面。
- 软件环境：PHP 8.x + MySQL 8.x。
- 已有优化：
- WordPress后台已启用缓存插件（如WP Super Cache）。
- 启用了Redis进行对象缓存。
- 静态资源（图片、CSS、JS）通过CDN分发。
尽管已经有了一些应用层面的优化，但服务器的闲时内存占用依然不低，这让我对能否稳定增加第四个WordPress站点感到担忧。优化的核心目标非常明确：降低闲时资源占用，提升服务器运行效率，为新应用预留空间。
重要前提：在进行任何修改前，我通过服务商的控制台为服务器创建了快照。这是最重要的一步，它保证了在任何操作失误的情况下，我都能快速恢复到原始状态。
二、性能优化的第一刀：PHP-FPM进程管理器
经过分析，服务器性能瓶颈的首要怀疑对象指向了PHP-FPM（FastCGI Process Manager）。它是PHP与Web服务器（如Nginx）之间的桥梁，负责管理PHP的子进程池。它的运行模式，直接决定了服务器内存的消耗方式。
我查看了各个WordPress站点对应的PHP-FPM池配置文件（通常位于/etc/php/[版本号]/fpm/pool.d/目录下），发现了关键配置：
pm = dynamicpm代表Process Manager（进程管理器）。dynamic（动态模式）是很多系统的默认设置。在这种模式下，即使网站没有任何访问，FPM也会始终保持一定数量的“待命”子进程（由pm.min_spare_servers参数决定）。这些待命进程会持续占用内存，对于我这种访问量不大的个人站点来说，这是一种显著的资源浪费。
解决方案：切换到Ondemand（按需模式）
ondemand模式是一种更为智能的进程管理方式。它的工作逻辑是：平时不创建任何子进程，完全不占用内存；只有当第一个Web请求到达时，才会“按需”启动一个子进程来处理。处理完成后，如果该进程闲置超过一定时间，就会被自动销毁，从而释放内存。
操作步骤
备份原有的FPM池配置文件。
编辑文件，修改
pm相关的配置。修改前:
INIpm = dynamic pm.max_children = 10 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3修改后:
INIpm = ondemand pm.max_children = 10 ; 这个值暂时保留，代表最多能同时处理10个请求 pm.process_idle_timeout = 10s ; 启用此项，表示进程闲置10秒后自动关闭 ; 以下三行在ondemand模式下无效，用分号注释掉 ; pm.start_servers = 2 ; pm.min_spare_servers = 1 ; pm.max_spare_servers = 3对服务器上所有WordPress站点的FPM池配置文件重复以上修改。
执行
systemctl restart php-fpm命令重启PHP-FPM服务，使新配置生效。
效果立竿见影：重启服务后，通过free -h命令查看，服务器在无访问状态下的可用内存（available）有了非常明显的增加。这第一刀，成功地为我“挤”出了宝贵的内存资源。
三、新旧并存：为容器化应用对齐环境
在完成已有站点的优化后，我使用1Panel的一键部署功能，安装了第四个WordPress站点。这引出了新的问题：如何为这个容器化的新站点进行同样的PHP优化？
经过探索发现，容器化应用的配置管理遵循不同的哲学。我们无法直接修改其内部的FPM配置文件。但1Panel的应用模板已经做好了预设，它通过挂载一个外部配置文件的方式来让我们调整PHP的核心参数。
操作步骤
- 在1Panel的文件管理器中，找到新应用目录下的
conf/uploads.ini文件。 - 编辑此文件，将PHP的核心参数（如
memory_limit,upload_max_filesize等）与老站点进行对齐。这确保了所有PHP应用的负载模型基本一致。 - 对于FPM的进程管理模式，我们相信1Panel使用的官方WordPress镜像已经默认采用了
ondemand或一个为容器环境高度优化的模式。我们无需、也无法直接干预。 - 修改完
uploads.ini后，在1Panel的应用管理界面对该应用执行“重建 (Rebuild)”操作，使新配置生效。
四、阶段性总结与下一步
至此，第一阶段的服务器优化已全部完成。我们通过将PHP-FPM的进程管理模式从dynamic切换到ondemand，并对齐了所有新旧站点的PHP核心参数，成功地在几乎不影响网站性能的前提下，显著降低了服务器的闲时资源占用。
服务器现在处于一个更健康、更高效、负载模型更一致的状态。这为我们进行下一步更深层次的优化打下了坚实的基础。
下一步计划：让服务器以当前状态稳定运行24-48小时，以收集足够真实的性能数据。然后，我们将使用专业的分析工具，对资源消耗的另一个大户——MySQL数据库，进行一次精准、安全的性能调优。敬请期待本系列的下一篇文章！
笔记由Gemini 2.5pro整理、构建