网站建设全流程图,wordpress 添加 联系我们,展示图片的网站模板,网站建设合同交印花税#xff08;ChatGpt的回复再结合其它资料整理#xff0c;有任何意见欢迎指出#xff09;WordPress占用内存过高可能由多种因素引起#xff0c;以下是一些可能的原因和解决方法。总之#xff0c;为了解决WordPress占用内存过高的问题#xff0c;您需要对主题#xff0c;插…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 自动缓存插件。
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 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实际上更为妥当因为这样不需要进行额外的进程数目控制会提高效率。对于小内存的服务器动态方式会结束掉多余的进程可以回收释放一些内存。
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那么不能超过14核那么就不能超过415分钟可以代表长期5分钟代表中期1分钟代表短期所以先看15分钟。可以说它现在的平均负载接近了它的cpu总核数4需要考虑服务器配置升级
5、woocommerce建站推荐服务器配置
1CPU用高主频的3Ghz多花不了你多少钱但对后台速度有能感知的提升双核起步
2内存4G起步每G内存大致能支撑一个常规WC站短时间内5个add to cart checkout session考虑系统使用4G内存能支撑的session小于20个跑不满最好当作冗余跑不满扩展不迟
3硬盘用高性能SSDNVME架构的最好会有很明显的基础性能优势磁盘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.wn789.com/sitemap.xml
Sitemap: https://www.wn789.com/sitemap.html
Sitemap: https://www.wn789.com/sitemap_baidu.xml
5、通过修改.htaccess来限制限制不必要的搜索引擎蜘蛛爬行。添加下面代码即可
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbotyahoo.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_instances400
如果找不到这个的话直接在合适的地方加上 performance_schema off 即可。
用于监控MySQL server在一个较低级别的运行过程中的资源消耗、资源等待等情况关闭之后可以节省开销不会使server的行为发生变化。table_definition_cache400
官方解释为可以存储在定义缓存中的表定义数来自.frm文件。如果使用大量表可以创建大型表定义缓存以加快表的打开速度。与普通的表缓存不同表定义缓存占用更少的空间并且不使用文件描述符。最小值和默认值均为400。table_open_cache256
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 64Mtable_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*28table_cache1024
#物理内存越大,设置就越大.默认为2402,调到512-1024最佳innodb_additional_mem_pool_size4M
#默认为2Minnodb_flush_log_at_trx_commit1
#设置为0就是等到innodb_log_buffer_size列队满后再统一储存,默认为1innodb_log_buffer_size2M
#默认为1Minnodb_thread_concurrency4
#你的服务器CPU有几个就设置为几,建议用默认一般为8key_buffer_size256M
#默认为218调到128最佳tmp_table_size128M
#默认为16M调到64-256最挂read_buffer_size4M
#默认为64Kread_rnd_buffer_size16M
#默认为256Ksort_buffer_size32M
#默认为256Kthread_cache_size120
#默认为60query_cache_size32M
修改完毕后重启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 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
9、百度了下原因是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
PIDSps aux|grep php-cgi|grep -v grep|awk’{if($41)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
statuscurl -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
fi
4多个php-fmp进程占用cpu过高都达到100%了于是打算监听一下进程看看在执行什么操作使用 strace 命令
#监听进程 strace -o /tmp/output.txt -T -tt -F -e traceall -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 里面的一些配置参数了以及升级服务器。 参考网址
1、https://www.cnblogs.com/xiaobingch/p/16189536.html
2、
