php MySQL占用了500%的CPU,导致网站速度变慢

xlpyo6sf  于 2023-02-07  发布在  PHP
关注(0)|答案(2)|浏览(175)

我有一个虚拟机,有64个vCPU和256GB内存,最近我决定对这个虚拟机上运行的网站进行一些压力测试,整个VM只针对这个网站。
我运行的第一个测试是每秒20,000个用户,平均响应时间约为1400毫秒,在测试期间,网站无法使用。

在那之后,我决定检查顶级进程以确定问题的根源。以下是测试期间的进程及其CPU利用率:

top - 10:30:19 up 1 day, 34 min,  0 users,  load average: 8.39, 3.04, 1.46
Tasks: 711 total,   2 running, 709 sleeping,   0 stopped,   0 zombie
%Cpu(s):  6.0 us,  9.8 sy,  3.8 ni, 79.2 id,  0.2 wa,  0.0 hi,  0.9 si,  0.0 st
MiB Mem : 257925.6 total, 219425.1 free,   3658.2 used,  34842.3 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used. 252346.8 avail Mem 

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                        
218159 mysql     20   0 6911232  96204  19792 S 491.4   0.0   4:24.99 mysqld                                         
139405 nobody    20   0   54948  34196   6128 D  44.9   0.0   0:52.17 litespeed                                      
218251 obl74+  21   1  347708  29228  19328 S  40.9   0.0   0:20.83 lsphp                                          
218402 obl74+  21   1  347708  29152  19264 S  40.9   0.0   0:22.35 lsphp                                          
218955 obl74+  21   1  273004  21336  12472 D  40.9   0.0   0:22.39 lsphp                                          
218957 obl74+  21   1  273004  21336  12472 D  40.9   0.0   0:22.22 lsphp                                          
218961 obl74+  21   1  273004  21336  12472 S  40.9   0.0   0:22.37 lsphp                                          
218963 obl74+  21   1  273004  21328  12468 S  40.9   0.0   0:22.31 lsphp                                          
218252 obl74+  21   1  347708  29228  19328 D  40.5   0.0   0:22.42 lsphp                                          
218407 obl74+  21   1  347708  29152  19264 D  40.5   0.0   0:22.30 lsphp                                          
218956 obl74+  21   1  273004  21332  12472 S  40.5   0.0   0:20.73 lsphp                                          
218959 obl74+  21   1  273004  21336  12472 S  40.5   0.0   0:22.13 lsphp

有趣的是,尽管网站在测试中表现不佳,但CPU和内存使用率都不是特别高。此外,在测试中,CyberPanel显示CPU使用率为19%,内存使用率为2%。因此,我得出结论,服务器没有遇到任何资源限制,因为它没有利用所有的CPU和内存。但由于某种原因,它仍然滞后。
然后,我决定从执行压力测试的页面中删除与MySQL相关的组件,结果要稳定得多。

top - 10:43:54 up 1 day, 47 min,  0 users,  load average: 0.87, 1.23, 1.41
Tasks: 705 total,   5 running, 699 sleeping,   0 stopped,   1 zombie
%Cpu(s):  2.8 us,  1.0 sy,  0.4 ni, 95.2 id,  0.0 wa,  0.0 hi,  0.5 si,  0.0 st
MiB Mem : 257925.6 total, 218249.7 free,   3910.0 used,  35765.9 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used. 252098.9 avail Mem 

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                        
139416 nobody    20   0   53200  32480   6128 S  18.3   0.0   0:47.00 litespeed                                      
139402 nobody    20   0   52928  33308   7204 S  16.6   0.0   0:44.40 litespeed                                      
139409 nobody    20   0   54900  34136   6188 S  16.6   0.0   0:46.38 litespeed                                      
139410 nobody    20   0   49904  29156   6128 S  16.6   0.0   0:35.43 litespeed                                      
139414 nobody    20   0   51688  30936   6128 R  16.6   0.0   0:45.46 litespeed                                      
139415 nobody    20   0   55492  35280   6680 R  15.9   0.0   0:46.24 litespeed                                      
139412 nobody    20   0   52112  31420   6188 S  15.6   0.0   0:45.05 litespeed                                      
139404 nobody    20   0   50396  29644   6128 S  15.3   0.0   0:44.83 litespeed                                      
139413 nobody    20   0   44700  23816   6128 S  15.3   0.0   0:21.83 litespeed                                      
139406 nobody    20   0   50752  30004   6128 S  15.0   0.0   1:05.25 litespeed

根据CyberPanel,在新测试期间,CPU使用率为4%,内存使用率为2%。
因此,很明显MySQL有问题。我目前使用CyberPanel提供的默认my. cnf配置,但我尝试了互联网上找到的各种其他配置,但没有任何改善性能,甚至一点点。我也尝试了MySQL Tuner之类的东西,但它没有改变性能。
我在第二个测试中删除的MySQL部分是一个包含7行的表的基本查询,它验证用户的IP地址以确定他们是否在IP白名单上,这个操作应该不会造成严重的问题。
正如在两个测试中所观察到的,我在开始时检测到一个阈值或瓶颈,超过这个阈值,站点的延迟会急剧增加。尽管有足够的可用内存和CPU,但似乎存在一些限制因素。
有些人可能会说每秒20,000个用户的速度太高了,而且不现实,但是,即使我在每秒只有250个用户的情况下进行测试,结果也是一样的:网站运行速度非常慢,无法使用。

在这一点上,我完全迷失了方向。我不知道我的努力集中在哪里,以及下一步采取什么步骤来减少平均响应时间。我将非常感谢您可能有任何有见地的评论或建议,我提前感谢您的时间和考虑。

  • 更新 *

我已经重新安装了操作系统和CyberPanel,看起来问题已经解决了。虽然我不确定之前出了什么问题,但我怀疑是不正确的设置造成的。

vtwuwzda

vtwuwzda1#

CloudSQL配置要考虑的建议

innodb_buffer_pool_size=8G  #  from ~ 192G because current data is less than 1G
innodb_io_capacity=500  #  from 200 to utilize more of your SSD IOPS
innodb_lru_scan_depth=100  # from 1024 to conserve 90% CPU cycles used every second for function
key_buffer_size=20M  # from ~ 128M needed for tmp tbl management, NO MyISAM tbls
sql_log_bin=0  # from ON unless you have a need for this specific log

请查看个人资料以获取联系信息。其他性能增强可用。

eqqqjvef

eqqqjvef2#

对于每秒2万个用户,您需要多台服务器和交换机在他们前面。句号。讨论结束。
好吧,好吧,我会进一步讨论的。
当MySQL面对大量“并发”用户时,它会公平地对待他们--每个用户都被赋予对所有资源的平等访问权。这在它福尔斯下悬崖之前是很好的。这是当大多数处理都在处理资源共享时。所有线程最终都会完成,但每个线程都将花费很长时间,而你(DBA)会认为它崩溃了,并拔掉插头。
一个简单的解决方法是 * 降低 *(是的,降低)max_connections的值。结果发现,“悬崖”在几十个连接处。
在基准测试中,一个人向服务器扔尽可能多的东西,直到服务器崩溃。通常是几十个。
在真实的生活中,网页并不是100%地进行数据库操作,而是让用户做出React,构建页面等。因此,几百个max_connections是现实的。
一旦到达悬崖,latency 就会突破屋顶。你可能会期望 throughput 也会增加,但它会略有下降。我相信这是因为线程之间的冲突太多了。想想任何“cache”(buffer_pool、open_tables、table_definitions等)--如果“太多”线程在运行,缓存可能会变得无效。
想象一个购物者众多的市场,他们大部分时间都在和其他人周旋,如果他们能阻止购物者在“满座”时进入市场,那么每小时就能有更多的购物者通过市场。

需要索引

ALTER TABLE table_name ADD INDEX(zone);
ALTER TABLE table_name ADD INDEX(IPPool);

(Then参加一个关于索引(又名“KEY”)好处的速成班。)

相关问题