宝塔：流量几乎为零，CPU使用率100%

koko

之前许多人建议用宝塔，入坑后才发现并不像说的那么好。


- ?0 y* B' s* H# J0 x1 \2 F跌跌撞撞学安装使用了宝塔，并安装了常见必需的几种软件：
Memcached
Redis
1 }! d, A8 S, ]. c( L  o& \以及PHP/ MYsql / phpMySQL 等，
另外还有Node Pure-Ftpd Nginx SSH终端,，也不知道是不是默认安装的。

7 T. r; X- F' z/ l9 H& \+ V上网站之后发现资源使用率极高，负载、CPU、内存等，经常上100%的，然后又摸索着做了些优化，包括：


2 N8 B: k  X/ k& m# C' \' J
$ N* M+ \; a2 z/ C& L; E! a
3 Z. B  }: ^6 H# N) E以及关掉日志。
9 ?5 d3 I: g) K
) D$ }) N( A3 K% ^* ~4 v% W7 _
网上的优化方案似乎也只有这几个地方，但是优化之后情况并没有好多少，偶尔还是会达到100%：


查看了一下，主要是php-fpm的问题：

4 Q5 N( S% G0 r3 g: z: y
, G7 f! \2 n  x. n' G2 H0 j可是问题是，这几个网站根本没什么流量，而且时间是在国内下午的时间，流量可以说是零，为什么会出现那么高的消耗？

该如何解决？
% }( T# c; v+ A5 A) W# z
恳请各路高人赐教~~~！
! i1 `- Z, d+ A2 n4 D9 H6 _+ S4 _
+ `/ f9 n  y* T% i% z: U- m+ D

河小马

你看下mysqld， mysqld 的参数调整一下，如果是innodb的话就有可能出现这种情况
8 Q7 K6 ~" A0 j" u
3 N' j5 q5 p2 `3 Z: f另外你的网站如果是wordpress的话，估计也有可能被人滥用了

你打开一下nginx 的 access log，仔细看一下应该就能解决了
0 g9 W% l* F7 k
/ g0 t- U7 N( X- g/ B* K! P和redis 之类的没什么关系
; s2 R$ e$ V, w9 w0 ~  y/ ^

惰惰

redis卸载掉应该就好了

koko

卸载Redis了，但似乎没什么卵用，负载反而更高了，而流量如图，几乎是没有

惰惰

koko 发表于 2023-2-23 22:58
1 i3 @0 L. I, _4 n$ s卸载Redis了，但似乎没什么卵用，负载反而更高了，而流量如图，几乎是没有
0 Q  A' U0 e, r% c* M5 p" v$ @

你难道没发现至少CPU不红了吗？

koko

惰惰 发表于 2023-2-23 23:25
你难道没发现至少CPU不红了吗？

( }0 A$ y' N3 r$ W3 x+ Y& U4 y# Y负载是每秒更新的，红本来也只是偶尔才出现。但是网站本身几乎没有流量，有也不过几十K，这怎么看不正常啊

ensky

点击监控，观察最近7天的平均值，或者看一下服务器官方的cpu统计，宝塔这个cpu频率显示和Linode后台的不一样

koko

河小马 发表于 2023-2-24 07:35
你看下mysqld， mysqld 的参数调整一下，如果是innodb的话就有可能出现这种情况
$ l* }: x$ L6 v/ G- N& Q' r' d
: x- W# u9 T' E% \) g另外你的网站如果是wordpr ...

" x3 F! ~, q) Q6 }. Q+ z+ W% J你看下mysqld， mysqld 的参数调整一下，如果是innodb的话就有可能出现这种情况
3 z: w/ D% f) j( n; j( C, [( J
+ i, o; K% @6 D% z* q7 [---Mysqld占用的内存资源的确比其它的多，但没占用什么CPU资源。如图，CPU几乎全是php-fpm占用的。
# G6 W* e/ Y* ^+ |另外，的确是innodb的，可以不用这个Innodb吗？（这个可能就是问题）



另外你的网站如果是wordpress的话，估计也有可能被人滥用了
" @2 h' e" D& J2 ]
7 L5 x  S4 U6 n! n4 L------全是WP的站点，有一些spam的comments，但也不该至此。关了comments也没有什么变化。也装了wordfence,扫描了一下没什么问题。
; s5 E$ I, P9 r& U4 }
# e3 {% ^+ {1 o! M$ U1 _/ `" q你打开一下nginx 的 access log，仔细看一下应该就能解决了
8 H( T8 E; O. }  T4 |* E------- 只有错误日志(空的)，没有access log???
, F- u, e1 e6 G
刚刚从文件管理那里查看了accesslog：

154.89.5.117 - - [24/Feb/2023:04:12:47 +0800] "GET / HTTP/1.1" 403 146 "-" "-"
8 _0 F! [6 P. ~, S* w, H$ N0 l198.235.24.184 - - [24/Feb/2023:06:07:18 +0800] "GET / HTTP/1.1" 403 146 "-" "Expanse, a Palo Alto Networks company, searches across the global IPv4 space multiple times per day to identify customers' presences on the Internet. If you would like to be excluded from our scans, please send IP addresses/domains to: [email protected]"

（昨天清空过）貌似没有什么问题？

) f) w: z" c5 W  [; W2 J
9 K4 l, w# Q! r4 f; v3 H! Y3 ~4 }

3 ~0 k1 u7 X# c& }; o

sead

' p9 i& S7 s* I0 n
PHP应该有消耗性能的代码，比如读写大型日志文件，看进程像是PHP代码产生的，如果是mysql问题cpu会高

sead

这里关键数据没有，实际需要看日志请求状况，主要查并发情况，有专门的日志维护脚本查。如果日志里面记录少，那么这个问题就有点难查了

newcb

wp内容太多，爬虫太多了吧？

河小马

koko 发表于 2023-2-24 08:06
" Q& {- {3 z- N% T# L! @6 l/ C你看下mysqld， mysqld 的参数调整一下，如果是innodb的话就有可能出现这种情况

---Mysqld占用的内存资源 ...

" y' b. l' f7 b) E' G/ J现在基本都是innodb引擎，这个可以放到最后再查
$ ]  ]3 }. b# l  C! C7 o3 q
2 o7 P! u" Y4 Y你这个一般就这么几个问题:
% j' l" z3 A5 \; L2 u3 L
' c& W) x$ x6 ]; H+ g4 X1) 楼上有人说的对，只有单一进程的php-fpm占用CPU，应该是日志过大，你仔细看下服务器上的php log 以及nginx log
这个的可能性是最大的
2 |8 _' U. g( I5 F3 i6 @" S
2) 临时打开nginx 的 access log，也仔细看下是不是有人在abuse，但是这种情况会造成多个php-fpm进程的
( N# K$ g5 o. G2 J: K

koko

河小马 发表于 2023-2-24 10:03
5 A) n% K2 S: x* k$ k( v; U( }9 d9 m现在基本都是innodb引擎，这个可以放到最后再查

$ N* t9 U, |+ r4 S+ S' ~/ l你这个一般就这么几个问题:

1) 楼上有人说的对，只有单一进程的php-fpm占用CPU，应该是日志过大，你仔细看下服务器上的php log 以及nginx log

百度有说是日志过大读写慢，已经清理过，的确快了些，但很快又死灰复燃，而且日志并没有多大，现在只有200k左右。

: r, z3 t$ n6 A: v2) 临时打开nginx 的 access log，也仔细看下是不是有人在abuse，但是这种情况会造成多个php-fpm进程的

  i) \) t" Q, n2 h6 _. G0 _php-fpm如上图，只有几个进程。

河小马

koko 发表于 2023-2-24 10:41
7 ]/ N' {9 B( G+ r2 H( G4 {$ g1) 楼上有人说的对，只有单一进程的php-fpm占用CPU，应该是日志过大，你仔细看下服务器上的php log 以及n ...

' A2 {5 }7 b) I# B. Q你仔细看下php 的各种日志吧，用一些php debug 工具

: [7 F/ T7 z; \其实有时间debug，早就切换到lnmp去了

xxz6513

软件一般运行不会错，宝塔的自动化安装的参数基本上也没问题，既然用wordpress了，多半是装了不少插件，一看日志，请求量大不大，是否爬虫高频爬取，二看php慢日志，是否有异常进程占用，三看数据库是否有慢查询导致堵塞，这个应该可能性比较小，程序和插件一般都做好优化了，而且看你这也没多大数据量。最后才是vps本身的问题。