解决 WordPress 占用内存不断上升的问题（非常有效果的GC调优）
安装好 WordPress后，在浏览器中操作一段时间后，便无法再使用 WordPress，并出现了错误提示信息。在服务器后台开启 WordPress 的调试模式后，刷新浏览器，得到了更详细的错误信息，分析后得知是无法连接数据库的问题。在服务器中一看，MYSQL 数据库不知什么时候挂掉了。查看系统内存使用情况，发现总共 1G 的内存，现在使用了九百多兆。在一看系统并没有交换分区。原因一下就很清楚了，是系统内存不足导致 MYSQL 崩溃。为系统添加了 1G 的交换文件作为虚拟内存后，数据库是不崩溃了，但 WordPress 使用一段时间后反应就相当慢，并且服务器的 SSH 连接也几乎不能使用。综合前面的情况可知，现在的问题是 WordPress 使用过程中占满了系统内存，系统开始使用交换文件，而交换文件性能不足导致。
在控制台重启服务器后，继续在浏览器中使用 WordPress，并且在后台实时监控系统内存的使用情况。发现进行更换主题，安装插件等一些操作时，系统内存使用量会大量增长，并且很快会超出物理内存大小，造成访问缓慢的问题。多方查找资料后，发现是 php-fpm 的问题。
php-fpm 的 FastCGI 进程一旦加载就不会释放，当其工作完成后，并不会释放给系统内存，而是休眠于 FastCGI 系统池中，等待下一次被唤醒。就造成了内存不断上升的问题。我一直用的是 php-fpm 默认配置，这个配置对于我来说可能有点不合适，需要修改配置文件。
php-fpm 的相关参数
-
pm：表示使用那种方式，有两个值可以选择，就是static（静态）或者dynamic（动态），默认为dynamic。
-
pm.max_children：静态方式下开启的php-fpm进程数量。
-
pm.start_servers：动态方式下的起始php-fpm进程数量。
-
pm.min_spare_servers：动态方式下的最小php-fpm进程数量。
-
pm.max_spare_servers：动态方式下的最大php-fpm进程数量。
区别：
如果pm设置为 static，那么其实只有 pm.max_children 这个参数生效。系统会开启设置数量的 php-fpm 进程。
如果pm设置为 dynamic，那么 pm.max_children 参数失效，后面 3 个参数生效。系统会在 php-fpm 运行开始的时候启动 pm.start_servers 个 php-fpm 进程，然后根据系统的需求动态在 pm.min_spare_servers 和 pm.max_spare_servers 之间调整 php-fpm 进程数。
php-fpm 参数调整
对于内存大的服务器（8G）以上，指定静态的max_children实际上更为妥当，因为这样不需要进行额外的进程数目控制，会提高效率。对于小内存的服务器，动态方式会结束掉多余的进程，可以回收释放一些内存。
我在这选择动态模式，调整后的配置如下：
pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 10
pm.max_requests = 300
然后重启 php-fpm，系统内存使用在二百多兆。操作 WordPress 一段时间后，系统内存使用量不断增长，最终稳定在四百多兆。问题得以解决。
