(ChatGpt的回复再结合其它资料整理,有任何意见欢迎指出)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 自动缓存插件。
用Alex Rabe开发的 WP-Memory-Usage插件来了解WordPress中的内存运用状况。Heiko Rabe开发的WordPress System Health插件会为咱们供给更全面的信息
查找可能占用资源的插件:通过禁用某个插件而表现得更好,如该项功能是必须的,看看您是否可以找到提供相同功能的替代插件 。
消除 Gravatar 评论页面加载延迟
Gravatars 很棒。它们让您的用户展示自己的个性,增添真实感,而且很多人都可以通过他们独特的头像轻松识别。但是,如果您收到大量评论,在您的网站上使用它们就会出现问题。每条评论都会向 Gravatar 的服务器发送一个请求。因此,如果您在一个页面上有很多评论,那么您将有很多请求来回传输,从而使该页面加载速度变慢。使用 FV Gravatar Cache 插件消除这种情况。FV Gravatar Cache 将在本地缓存这些图像,这将减少具有许多评论的页面的加载时间……
只使用你绝对需要的热门插件
注意:在停用和删除插件之前,请查找任何卸载功能或自述文件。某些插件具有特殊的卸载程序,可以将它们从您的站点中完全删除。
中断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');
二、数据库:
数据库的大小和性能也可能导致WordPress占用过高的内存。确保优化数据库,删除不必要的数据和记录,并使用缓存插件来减少对数据库的访问。
配置数据库
三、缓存: 如果您的网站没有启用缓存,则每次加载页面时都会生成新的HTML代码,这可能会导致占用过高的内存。启用缓存插件可以减少对服务器的请求,从而降低内存占用。
一般来说 wordpress 程序中安装opcache、memcached 这两个扩展组件的其中之一即可,如果程序不要求,别的都不用安装。如果是非 wordpress 程序,只安装 opcache 这个缓存扩展。
502这个错误:这样频繁报错完全是因为我在拓展中开启了两个缓存器opcache和Memcached,而Memcached又没进行设置,于是出现了某种冲突,导致频繁502。我利用水煮鱼的插件开启了Memcached,删除了opcache拓展,网站瞬间满血复活
使用缓存插件:缓存插件将有助于更快地加载最近提供的内容。一般来说,当有人访问您的 WordPress 站点时,他们的浏览器会获取 HTML 文件,这需要运行 PHP 脚本或从 WordPress 数据库中获取数据。好在如今大多数浏览器都足够智能,可以通过浏览器保留访问过的站点的“记忆”。这是缓存。WordPress 插件将保存提供的 HTML 文件,以便浏览器可以更快地加载它们,而无需运行脚本或从数据库中获取信息。
一些流行 WP 缓存插件有:W3 Total Cache。WP Super Cache。WP Rocket。Comet Cache。WP Fastest Cache
四、PHP版本和配置:
使用旧版本的PHP可能会导致内存占用过高。确保您正在使用最新版本的PHP,并优化php.ini文件以最大程度地减少内存使用。
安装了多个PHP版本,甚至把 php 5.3、5.4、7.0、7.3 等全都安装上了,这会严重增加系统负载和内存使用率。建议只保留一个,卸载掉其它版本。
php-fpm占用大量cpu使用率,导致php挂起
pm = dynamicpm.max_children = 20pm.start_servers = 5pm.min_spare_servers = 2pm.max_spare_servers = 10pm.max_requests = 300
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 进程数。
对于内存大的服务器(8G)以上,指定静态的max_children实际上更为妥当,因为这样不需要进行额外的进程数目控制,会提高效率。对于小内存的服务器,动态方式会结束掉多余的进程,可以回收释放一些内存。
登录宝塔面板——软件管理——PHP设置——性能调整,按照上方的线路,找到相应的PHP,进行调整即可。
注意重新配置之后要重启服务器。
五、服务器资源、硬件问题:
如果您的服务器资源不足,则可能会导致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无压力。
php-fpm日志:
日志文件:/usr/local/php/var/log/php-fpm.log
多个版本管理php-fpm :/etc/init.d/php-fpm8.1 reload
单个版本管理:lnmp php-fpm reload
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 命令,从/ 根目录开始挨个目录进行查找。
硬件问题: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;需要考虑服务器配置升级!
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 可以将静态文件缓存在全球分布的服务器上,以提高网站的加载速度和减少服务器负载。
七、优化图片和媒体文件:将图片和媒体文件进行压缩,缩小文件大小,删除不必要的文件,以减少内容占用。
八、其它问题
wordpress 此站点遇到了致命错误:主题和插件更新导致的不兼容,建议直接恢复默认主题,停用插件观察,如果通过WP_DEBUG可以直接定位到问题,那么也可以根据错误提示找到问题所在,针对性的解决。
官方排错链接:FAQ Troubleshooting – WordPress.org Documentation
关闭文章撰写的定时发布功能及自动保存草稿问题。这几个功能可以通过修改wp-cron.php内的数据来实现,我们在里面添加下面代码即可
define(‘DISABLE_WP_CRON’, true);define (‘WP_POST_REVISIONS’, 0);define(‘AUTOSAVE_INTERVAL’, 600);
通过修改robots.txt来限制搜索引擎蜘蛛不必要的站点文件。我们在里面添加下面代码即可:
User-agent: *Crawl-delay: 10Allow: /wp-content/uploads/Disallow: /cgi-bin/Disallow: /wp-login.phpDisallow: /wp-login.php*Disallow: /wp-register.phpDisallow: /wp-register.php*Disallow: /xmlrpc.phpDisallow: /template.htmlDisallow: /wp-admin/Disallow: /wp-includes/Disallow: /wp-content/pluginsDisallow: /wp-content/themesDisallow: /page/Sitemap: https://www.wn789.com/sitemap.xmlSitemap: https://www.wn789.com/sitemap.htmlSitemap: https://www.wn789.com/sitemap_baidu.xml
通过修改.htaccess来限制限制不必要的搜索引擎蜘蛛爬行。添加下面代码即可:
RewriteEngine OnRewriteCond %{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} ^ZeusRewriteRule ^.* – [F,L]
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=256MySQL每打开一个表,都会读入一些数据到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 = 4Mthread_stack = 256Ktable_cache = 128Ksort_buffer_size = 6M#查询排序时所能使用的缓冲区大小。所以,对于内存在4GB左右的服务器推荐设置为6-8M。read_buffer_size = 4M#读查询操作所能使用的缓冲区大小。和sort_buffer_size一样,该参数对应的分配内存也是每连接独享。join_buffer_size = 8M#联合查询操作所能使用的缓冲区大小,和sort_buffer_size一样,该参数对应的分配内存也是每连接独享。myisam_sort_buffer_size = 64Mtable_cache = 512thread_cache_size = 64query_cache_size = 64M#指定MySQL查询缓冲区的大小。。tmp_table_size = 256Mmax_connections = 768#指定MySQL允许的最大连接进程数。如果在访问论坛时经常出现Too Many Connections的错误提示,则需要增大该参数值。max_connect_errors = 10000000wait_timeout = 10#指定一个请求的最大连接时间,对于4GB左右内存的服务器可以设置为5-10。thread_concurrency = 8#该参数取值为服务器逻辑CPU数量*2,在本例中,服务器有2颗物理CPU,而每颗物理CPU又支持H.T超线程,所以实际取值为4*2=8table_cache=1024#物理内存越大,设置就越大.默认为2402,调到512-1024最佳innodb_additional_mem_pool_size=4M#默认为2Minnodb_flush_log_at_trx_commit=1#设置为0就是等到innodb_log_buffer_size列队满后再统一储存,默认为1innodb_log_buffer_size=2M#默认为1Minnodb_thread_concurrency=4#你的服务器CPU有几个就设置为几,建议用默认一般为8key_buffer_size=256M#默认为218,调到128最佳tmp_table_size=128M#默认为16M,调到64-256最挂read_buffer_size=4M#默认为64Kread_rnd_buffer_size=16M#默认为256Ksort_buffer_size=32M#默认为256Kthread_cache_size=120#默认为60query_cache_size=32M
修改完毕后,重启mysql服务,service mysql restart。通过这种方法确实可以降低mysql的内存占用,但我这只是通过降低性能来换取内存罢了,如果对吞吐量要求比较高的情况,那肯定是不能这样直接修改的,得根据实际请求进行调整才行。
How to Fix WordPress 502 Bad Gateway Error
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 8Fatal 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 74
百度了下,原因是PHP的内存不够大。网上大部分都是让改php.ini配置文件:但是发现改完了,也没用,报同样的错误,于是就想用PHP自带的unset()函数去处理,在做foreach()的时候,用完就unset变量,然后就不报错了,数据也能正常写入新的表
How to fix Error “/wp-json/wp/v2/ Failed to load resource” on Wordpress
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/shPIDS=`ps aux|grep php-cgi|grep -v grep|awk’{if($4>=1)print $2}’`for PID in $PIDSdoecho `date +%F….%T`>>/data/logs/phpkill.logecho $PID >> /data/logs/phpkill.logkill -9 $PIDdone
检测php-fpm进程
#!/bin/bashnetstat -tnlp | grep “php-cgi” >> /dev/null #2&> /data/logs/php_fasle.logif [ "$?" -eq "1" ];then #&& [ `netstat -tnlp | grep 9000 | awk '{ print $4}' | awk -F ":" '{print $2}'` -eq "1" ];then/usr/local/webserver/php/sbin/php-fpm startecho `date +%F….%T` “System memory OOM.Kill php-cgi. php-fpm service start. ” >> /data/logs/php_monitor.logfi
通过http检测php执行
#!/bin/bashstatus=`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 restartecho `date +%F….%T` “php-fpm service restart” >> /data/logs/php_monitor.logfi
4)多个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 里面的一些配置参数了,以及升级服务器。
参考网址:
https://www.cnblogs.com/xiaobingch/p/16189536.html
来源地址:https://blog.csdn.net/lyb8010/article/details/129285183