WordPress占用内存过高可能由多种因素引起，以下是一些可能的原因和解决方法。总之，为了解决WordPress占用内存过高的问题，您需要对主题，插件，数据库，缓存，PHP版本和配置以及服务器资源进行全面的审核和优化。
一、程序、主题、插件：
1、程序配置
// 更多内存
define('WP_MEMORY_LIMIT', '64M');
// 更多更多的内存
define('WP_MEMORY_LIMIT', '96M');
// 又好又多的内存 ?
define('WP_MEMORY_LIMIT', '128M');
假如呈现空白页面，阐明扩展容量过大，体系无法接受，内存康复32MB。 祝好运2、程序死循环、程序代码优化。程序执行可能超时，开慢日志一般就能确定具体函数或文件。
3、WordPress的主题和插件是最常见的内存占用原因。确保使用的主题和插件是最新版本，并且只使用必需的插件。禁用不需要的插件，并逐个启用它们，以确定哪个插件占用了最多的内存。
4、尽量少使占用资源较大的插件，特别是All in One SEO,Broken Link Checker,Yet Another Related Posts Plugin,NextGen Gallery最好不要使用。另外一些没有启用的插件要把插件文件都全部删除。适当使用一些优惠插件，如数据库优化Optimize Db和WP super cache 自动缓存插件。
5、用Alex Rabe开发的 WP-Memory-Usage插件来了解WordPress中的内存运用状况。Heiko Rabe开发的WordPress System Health插件会为咱们供给更全面的信息
6、查找可能占用资源的插件：通过禁用某个插件而表现得更好，如该项功能是必须的，看看您是否可以找到提供相同功能的替代插件 。
7、消除 Gravatar 评论页面加载延迟
Gravatars 很棒。它们让您的用户展示自己的个性，增添真实感，而且很多人都可以通过他们独特的头像轻松识别。但是，如果您收到大量评论，在您的网站上使用它们就会出现问题。每条评论都会向 Gravatar 的服务器发送一个请求。因此，如果您在一个页面上有很多评论，那么您将有很多请求来回传输，从而使该页面加载速度变慢。使用 FV Gravatar Cache 插件消除这种情况。FV Gravatar Cache 将在本地缓存这些图像，这将减少具有许多评论的页面的加载时间……
8、只使用你绝对需要的热门插件
注意：在停用和删除插件之前，请查找任何卸载功能或自述文件。某些插件具有特殊的卸载程序，可以将它们从您的站点中完全删除。
9、中断WordPress与官网的联系：将下面代码加到当前主题函数模板文件functions.php中
add_filter('automatic_updater_disabled','__return_true'); // 彻底关闭自动更新
remove_action('init','wp_schedule_update_checks'); // 关闭更新检查定时作业
wp_clear_scheduled_hook('wp_version_check'); // 移除已有的版本检查定时作业
wp_clear_scheduled_hook('wp_update_plugins'); // 移除已有的插件更新定时作业
wp_clear_scheduled_hook('wp_update_themes'); // 移除已有的主题更新定时作业
wp_clear_scheduled_hook('wp_maybe_auto_update'); // 移除已有的自动更新定时作业
remove_action('admin_init','_maybe_update_core'); // 移除后台内核更新检查
remove_action('load-plugins.php','wp_update_plugins'); // 移除后台插件更新检查
remove_action('load-update.php','wp_update_plugins');
remove_action('load-update-core.php','wp_update_plugins');
remove_action('admin_init','_maybe_update_plugins');
remove_action('load-themes.php','wp_update_themes'); // 移除后台主题更新检查
remove_action('load-update.php','wp_update_themes');
remove_action('load-update-core.php','wp_update_themes');
remove_action('admin_init','_maybe_update_themes');二、数据库：
1、数据库的大小和性能也可能导致WordPress占用过高的内存。确保优化数据库，删除不必要的数据和记录，并使用缓存插件来减少对数据库的访问。
2、配置数据库
三、缓存： 如果您的网站没有启用缓存，则每次加载页面时都会生成新的HTML代码，这可能会导致占用过高的内存。启用缓存插件可以减少对服务器的请求，从而降低内存占用。
1、一般来说 wordpress 程序中安装opcache、memcached 这两个扩展组件的其中之一即可，如果程序不要求，别的都不用安装。如果是非 wordpress 程序，只安装 opcache 这个缓存扩展。
2、502这个错误：这样频繁报错完全是因为我在拓展中开启了两个缓存器opcache和Memcached，而Memcached又没进行设置，于是出现了某种冲突，导致频繁502。我利用水煮鱼的插件开启了Memcached，删除了opcache拓展，网站瞬间满血复活
3、使用缓存插件：缓存插件将有助于更快地加载最近提供的内容。一般来说，当有人访问您的 WordPress 站点时，他们的浏览器会获取 HTML 文件，这需要运行 PHP 脚本或从 WordPress 数据库中获取数据。好在如今大多数浏览器都足够智能，可以通过浏览器保留访问过的站点的“记忆”。这是缓存。WordPress 插件将保存提供的 HTML 文件，以便浏览器可以更快地加载它们，而无需运行脚本或从数据库中获取信息。
一些流行 WP 缓存插件有：W3 Total Cache。WP Super Cache。WP Rocket。Comet Cache。WP Fastest Cache
四、PHP版本和配置：
1、使用旧版本的PHP可能会导致内存占用过高。确保您正在使用最新版本的PHP，并优化php.ini文件以最大程度地减少内存使用。
2、安装了多个PHP版本，甚至把 php 5.3、5.4、7.0、7.3 等全都安装上了，这会严重增加系统负载和内存使用率。建议只保留一个，卸载掉其它版本。
2、php-fpm占用大量cpu使用率，导致php挂起
pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 10
pm.max_requests = 300php-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 进程数。
对于内存大的服务器（8G）以上，指定静态的max_children实际上更为妥当，因为这样不需要进行额外的进程数目控制，会提高效率。对于小内存的服务器，动态方式会结束掉多余的进程，可以回收释放一些内存。
3、登录宝塔面板——软件管理——PHP设置——性能调整，按照上方的线路，找到相应的PHP，进行调整即可。
注意重新配置之后要重启服务器。
五、服务器资源、硬件问题：
1、如果您的服务器资源不足，则可能会导致WordPress占用过高的内存。升级到更高级别的服务器，或考虑使用云托管服务，例如AWS或Google Cloud，以确保有足够的资源来处理您的网站。
wordpress网站对主机要求比一般的网站程序要高的多，如你使用的是服务器至少需要2核心，2G内存起步的配置，单核容易在突发情况时网站很慢或卡死，如你使用较多插件（8个以上），特别是使用WooCommerce系列的插件，那你的服务器配置至少在3核心、4G内存以上配置，如乐道主机美国服务器，3核心，6G内存，80G SSD硬盘，100M宽带峰值速度，CN2线路，200元/月，详细了解，适合wordpress程序的外贸网站使用。也可使用虚拟主机，虚拟主机可用CPU相当于2核心的服务器，价格还很便宜，如1G香港虚拟主机，仅需170元/年，买2年送1年，相当于2核心的服务器，跑wordpress无压力。
2、php-fpm日志：
日志文件：/usr/local/php/var/log/php-fpm.log
多个版本管理php-fpm ：/etc/init.d/php-fpm8.1 reload
单个版本管理：lnmp php-fpm reload
3、lnmp日志：不要使用rm命令直接删除！一般系统日志在/var/log/ 下，可以ls -lh /var/log/ 看一下占用的大小。可以使用cat /dev/null > logfile 进行日志删除。
cat /dev/null > /var/log/syslog
cat /dev/null > /var/adm/sylog
cat /dev/null > /var/log/wtmp
cat /dev/null > /var/log/btmp
cat /dev/null > /var/log/secure
cat /dev/null > /var/log/maillog
cat /dev/null > /var/log/messages
cat /dev/null > /var/log/maillog
cat /dev/null > /var/log/mail.info
如果是采用LNMP一键安装包安装的环境，一下地方可能还会有日志：
mysql日志：https://www.vpser.net/manage/delete-mysql-mysql-bin-0000-logs.html
nginx日志：https://bbs.vpser.net/thread-1811-1-1.html
如果仍不能确定具体磁盘的占用情况，可以使用 du -sh 命令，从/ 根目录开始挨个目录进行查找。
4、硬件问题：top 命令，主要查看load average（平均负载），例如：这是一个4核8G内存的服务器的显示
1分钟平均负载：2.32；
5分钟平均负载：2.18；
15分钟平均负载：3.95；
load average 中3个数的含义，如果是1核cpu，那么不能超过1，4核那么就不能超过4，15分钟可以代表长期，5分钟代表中期，1分钟代表短期，所以先看15分钟。可以说它现在的平均负载接近了它的cpu总核数：4；需要考虑服务器配置升级！
5、woocommerce建站推荐服务器配置：
1）CPU：用高主频的，3Ghz+，多花不了你多少钱，但对后台速度有能感知的提升，双核起步
2）内存：4G起步，每G内存大致能支撑一个常规WC站短时间内5个add to cart + checkout session，考虑系统使用，4G内存能支撑的session小于20个，跑不满最好，当作冗余，跑不满扩展不迟
3）硬盘：用高性能SSD，NVME架构的最好，会有很明显的基础性能优势，磁盘IO容易被普通站长忽视，建议查阅sysbench，试着去benchmark硬盘读写速度比较主机后再决定买哪个，容量优先考虑你的图片存储需要，图片存储需求大致可以这么算：产品数量 * 每个产品图片量（主题，详情图），站点不同差距很大，单个产品给至少10M图片空间（一般只多不少），1000款产品大致需要10G存储空间，建议你买3-4倍的硬盘空间，留出冗余，具体要多少，你自己可以再仔细算算
4）带宽：只能根据网站实际流量状况来动态规划，虽然WC站90%+的流量都会走CDN，但太小显然也不行，你可以选一个图片（大图）最多的产品页，把它的存储容量乘以5-10倍来起步
个人用过的最好的主机是GCP，不是最便宜的。不必一步到位，需要的时候扩展即可。
主机性能只是WC站点综合性能的一个部分，全局重要性可能不到20%（我的意思也绝不是说主机就不重要，千万别误会），是高性能WC站点的必要不充分条件，后续还有很多应用层面的优化要做，但如果主机能给你的avg load time -500ms，你就能省下很多时间做更高价值的事，而不是不得不去纠结很多收益小不得不做但很难做的优化。
六、使用 CDN：使用 CDN 可以将静态文件缓存在全球分布的服务器上，以提高网站的加载速度和减少服务器负载。
七、优化图片和媒体文件：将图片和媒体文件进行压缩，缩小文件大小，删除不必要的文件，以减少内容占用。
八、其它问题
1、wordpress 此站点遇到了致命错误：主题和插件更新导致的不兼容，建议直接恢复默认主题，停用插件观察，如果通过WP_DEBUG可以直接定位到问题，那么也可以根据错误提示找到问题所在，针对性的解决。
2、官方排错链接：FAQ Troubleshooting – WordPress.org Documentation
3、关闭文章撰写的定时发布功能及自动保存草稿问题。这几个功能可以通过修改wp-cron.php内的数据来实现，我们在里面添加下面代码即可
define(‘DISABLE_WP_CRON’, true);
define (‘WP_POST_REVISIONS’, 0);
define(‘AUTOSAVE_INTERVAL’, 600);4、通过修改robots.txt来限制搜索引擎蜘蛛不必要的站点文件。我们在里面添加下面代码即可：
User-agent: *
Crawl-delay: 10
Allow: /wp-content/uploads/
Disallow: /cgi-bin/
Disallow: /wp-login.php
Disallow: /wp-login.php*
Disallow: /wp-register.php
Disallow: /wp-register.php*
Disallow: /xmlrpc.php
Disallow: /template.html
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /wp-content/plugins
Disallow: /wp-content/themes
Disallow: /page/
Sitemap: https://www.xxx.com/sitemap.xml
Sitemap: https://www.xxx.com/sitemap.html
Sitemap: https://www.xxx.com/sitemap_baidu.xml5、通过修改.htaccess来限制限制不必要的搜索引擎蜘蛛爬行。添加下面代码即可：
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot@yahoo.com [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} HTTrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} Indy\ Library [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR]
RewriteCond %{HTTP_USER_AGENT} ^larbin [OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR]
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Wget [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus
RewriteRule ^.* – [F,L]6、mysql5.6的默认配置是不适合小型站点的，win的话在my.ini里修改、linux则在/etc/my.cnf里修改performance_schema_max_table_instances参数，有就修改，没有就追加：
performance_schema_max_table_instances=400
如果找不到这个的话，直接在合适的地方加上 performance_schema = off 即可。
用于监控MySQL server在一个较低级别的运行过程中的资源消耗、资源等待等情况，关闭之后可以节省开销，不会使server的行为发生变化。
table_definition_cache=400
官方解释为：可以存储在定义缓存中的表定义数（来自.frm文件）。如果使用大量表，可以创建大型表定义缓存以加快表的打开速度。与普通的表缓存不同，表定义缓存占用更少的空间，并且不使用文件描述符。最小值和默认值均为400。
table_open_cache=256
MySQL每打开一个表，都会读入一些数据到table_open_cache缓存中，当MySQL在这个缓存中找不到相应信息时，才会去磁盘上读取。
官方解释为：所有线程的打开表数。增加该值会增加mysqld所需的文件描述符的数量。因此，您必须确保在[mysqld safe]部分的变量“open files limit”中将允许打开的文件量设置为至少4096。
mysql 性能提高配置#####################################################
skip-name-resolve
#禁止MySQL对外部连接进行DNS解析!!所有远程主机连接授权都要使用IP地址方式
back_log = 384
#back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。
key_buffer_size = 256M
#key_buffer_size指定用于索引的缓冲区大小，增加它可得到更好的索引处理性能。对于内存在4GB左右的服务器该参数可设置为256M或384M。
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 128K
sort_buffer_size = 6M
#查询排序时所能使用的缓冲区大小。所以，对于内存在4GB左右的服务器推荐设置为6-8M。
read_buffer_size = 4M
#读查询操作所能使用的缓冲区大小。和sort_buffer_size一样，该参数对应的分配内存也是每连接独享。
join_buffer_size = 8M
#联合查询操作所能使用的缓冲区大小，和sort_buffer_size一样，该参数对应的分配内存也是每连接独享。
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
#指定MySQL查询缓冲区的大小。。
tmp_table_size = 256M
max_connections = 768
#指定MySQL允许的最大连接进程数。如果在访问论坛时经常出现Too Many Connections的错误提示，则需要增大该参数值。
max_connect_errors = 10000000
wait_timeout = 10
#指定一个请求的最大连接时间，对于4GB左右内存的服务器可以设置为5-10。
thread_concurrency = 8
#该参数取值为服务器逻辑CPU数量*2，在本例中，服务器有2颗物理CPU，而每颗物理CPU又支持H.T超线程，所以实际取值为4*2=8
table_cache=1024
#物理内存越大,设置就越大.默认为2402,调到512-1024最佳
innodb_additional_mem_pool_size=4M
#默认为2M
innodb_flush_log_at_trx_commit=1
#设置为0就是等到innodb_log_buffer_size列队满后再统一储存,默认为1
innodb_log_buffer_size=2M
#默认为1M
innodb_thread_concurrency=4
#你的服务器CPU有几个就设置为几,建议用默认一般为8
key_buffer_size=256M
#默认为218，调到128最佳
tmp_table_size=128M
#默认为16M，调到64-256最挂
read_buffer_size=4M
#默认为64K
read_rnd_buffer_size=16M
#默认为256K
sort_buffer_size=32M
#默认为256K
thread_cache_size=120
#默认为60
query_cache_size=32M修改完毕后，重启mysql服务，service mysql restart。通过这种方法确实可以降低mysql的内存占用，但我这只是通过降低性能来换取内存罢了，如果对吞吐量要求比较高的情况，那肯定是不能这样直接修改的，得根据实际请求进行调整才行。
7、How to Fix WordPress 502 Bad Gateway Error
8、
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /home/wwwroot/www.###.com/wp-content/themes/neve/globals/google-fonts.php on line 8
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /home/wwwroot/www.###.com/wp-includes/class-wp-fatal-error-handler.php on line 749、百度了下，原因是PHP的内存不够大。网上大部分都是让改php.ini配置文件：但是发现改完了，也没用，报同样的错误，于是就想用PHP自带的unset（）函数去处理，在做foreach（）的时候，用完就unset变量，然后就不报错了，数据也能正常写入新的表
10、How to fix Error “/wp-json/wp/v2/ Failed to load resource” on WordPress
https://medium.com/@nguyentamdotme/how-to-fix-error-wp-json-wp-v2-failed-to-load-resource-on-wordpress-e4a204f8f698
11、PHP-FPM进程CPU 100%是怎么回事？
1）进程跟踪
# top //找出CPU使用率高的进程PID
# ll /proc/PID/fd //查看该进程在处理哪些文件
# strace -p PID //跟踪进程
查看占用内存最高的5个进程
ps aux | sort -k4nr | head -n 5
查看占用cpu最高的5个进程
ps aux | sort -k3nr | head -n 5将有可疑的PHP代码修改之，如：file_get_contents没有设置超时时间。
2）内存分配
如果进程跟踪无法找到问题所在，再从系统方面找原因，会不会有可能内存不够用？据说一个较为干净的PHP-CGI打开大概20M-30M左右的内存，决定于PHP模块开启多少。
通过pmap指令查看PHP-CGI进程的内存使用情况
# pmap $(pgrep php-cgi |head -1)按输出的结果，结合系统的内存大小，配置PHP-CGI的进程数（max_children）。
3）监控
最后，还可以通过监控与自动恢复的脚本保证服务的正常运转。下面是我用到的一些脚本：
只要一个php-cgi进程占用的内存超过 %1 就把它kill掉
#!/bin/sh
PIDS=`ps aux|grep php-cgi|grep -v grep|awk’{if($4>=1)print $2}’`
for PID in $PIDS
do
echo `date +%F….%T`>>/data/logs/phpkill.log
echo $PID >> /data/logs/phpkill.log
kill -9 $PID
done检测php-fpm进程
#!/bin/bash
netstat -tnlp | grep “php-cgi” >> /dev/null #2&> /data/logs/php_fasle.log
if [ "$?" -eq "1" ];then #&& [ `netstat -tnlp | grep 9000 | awk '{ print $4}' | awk -F ":" '{print $2}'` -eq "1" ];then
/usr/local/webserver/php/sbin/php-fpm start
echo `date +%F….%T` “System memory OOM.Kill php-cgi. php-fpm service start. ” >> /data/logs/php_monitor.log
fi通过http检测php执行
#!/bin/bash
status=`curl -s –head “http://127.0.0.1:8080/chk.php” | awk ‘/HTTP/ {print $2}’`
if [ $status != "200" -a $status != "304" ]; then
/usr/local/webserver/php/sbin/php-fpm restart
echo `date +%F….%T` “php-fpm service restart” >> /data/logs/php_monitor.log
fi4）多个php-fmp进程占用cpu过高，都达到100%了，于是打算监听一下进程，看看在执行什么操作，使用 strace 命令：
#监听进程 strace -o /tmp/output.txt -T -tt -F -e trace=all -p 7757
#查看log tail -f /tmp/output.txt
结果还没看出来什么，cpu占用率已经下来了，那几个进程已经结束了。最后通过 php慢日志 发现了端倪。
php慢日志开启条件，需要在 php-fpm.conf 配置如下：
request_slowlog_timeout = 1 #脚本超时秒数，超过1稍都算慢了
slowlog = /var/log/php.log.slow #记录慢日志路径
查看近1000条php慢日志：tail -n 1000 /var/log/php.log.slow
经查找发现了罪魁祸首，是前同事留下的一个大递归操作有问题：
然后优化代码就可以了。
这种单个php-fpm进程cpu占用过高，基本上是由于程序本身存在问题（如程序无限循环逻辑），优化程序后如果还得不到解决，那就如网上所说需要考虑 php-fpm.conf 里面的一些配置参数了，以及升级服务器。
