如何找出导致 Laravel 项目 CPU 使用率过高的原因

发布于 2025-01-17 21:46:59 字数 988 浏览 1 评论 0原文

我已经建立了一个相对复杂的系统（CMS），该系统由两个项目组成 - 管理站点和用户站点。在管理站点上，我们创建内容并将其添加到页面中。用户站点反映了这些页面。我面临的问题是，某些事情正在导致100％的CPU使用峰值，我不知道那是什么。我已经在系统的关键部分上实施了数据缓存，在我看来，这是最渴望资源的，但这只是有所帮助，仍然遇到100％的CPU使用情况，并且整个网站都无法处理请求，并且整个网站都会下降。。我们每天大约有300个用户，这不是Laravel应用无法处理的IMO。我正在使用刀片模板，因此它的服务器端渲染（认为整个Vue前端的返工可能会解决但不确定）。也许有人可以指导我正确的方向，以确定我的代码中哪些功能引起了这些问题。我已经尝试使用Laravel Debugbar，但我不知道哪些参数被认为是“可满足的”。我已经尝试在MySQL中启用长时间的查询日志，但没有提供任何结果。 We're hosting on a dedicated server

CPU Intel(R) Xeon(R) Gold 6150 CPU @ 2.70GHz (4 core(s)).

OS Almalinux 8.4。

8GB RAM

I have a full control over the server but I'm not a qualified system administrator so I'm not sure if there's anything I can do to figure this out by running some terminal commands.我已经尝试运行“ TOP”命令，它只是将MySQL和PHP-FPM显示为消耗所有CPU资源的过程，但这对我没有帮助。

我怀疑某处可能有内存泄漏，但是我怎么能找到它？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

勿忘初心 2025-01-24 21:46:59

每秒速率 = RPS

针对 my.cnf [mysqld] 部分要考虑的建议
（使用SET GLOBAL变量名=值；可以设置这些动态变量
并且不需要停止/启动实例）

read_rnd_buffer_size=64*1024  # from 256K to reduce handler_read_rnd_next RPS of 284,967
max_write_lock_count=16  # from ~ 4 billion to allow ReadData after nn locks
innodb_io_capacity=400  # from 200 to use more of available IOPS for your HDD
innodb_buffer_pool_size=1*1024*1024*1024  # from 128M to reduce innodb_data_reads RPS of 3
innodb_adaptive_max_sleep_delay=10000  # from 150000 for 1 second vs 15 second delay when busy

如有任何疑问，请联系。 CPU 压力应该会显着降低。存在更多提高绩效的机会。

观察结果，A) handler_rollback 平均每 220 秒 1 次——例如昂贵的操作。 B) 状态报告中的 innodb_secondary_index_triggered_cluster_reads 显示 251 RPS，可能是由于频繁使用没有 PRIMARY KEY 的表造成的。 C) select_scan 平均 5 RPS - 表示缺少索引，这将提高查询性能。 D) Slow_query_log 仅在 ON 且 long_query_time 小于 10 秒时有用。

Rate Per Second = RPS

Suggestions to consider for your my.cnf [mysqld] section
(use of SET GLOBAL variable_name=value; may SET these dynamic variables
and not require stop/start of instance)

read_rnd_buffer_size=64*1024  # from 256K to reduce handler_read_rnd_next RPS of 284,967
max_write_lock_count=16  # from ~ 4 billion to allow ReadData after nn locks
innodb_io_capacity=400  # from 200 to use more of available IOPS for your HDD
innodb_buffer_pool_size=1*1024*1024*1024  # from 128M to reduce innodb_data_reads RPS of 3
innodb_adaptive_max_sleep_delay=10000  # from 150000 for 1 second vs 15 second delay when busy

If any questions, please make contact. CPU stress should be significantly reduced. Many more opportunities exist to improve performance.

Observations, A) handler_rollback averages 1 every 220 seconds - expensive operation for instance. B) innodb_secondary_index_triggered_cluster_reads in status report shows 251 RPS and is likely caused by frequent use of a table with no PRIMARY KEY. C) select_scan averages 5 RPS - indicates index(s) missing that would improve performance of queries. D) slow_query_log is ONLY useful when ON and when long_query_time is less than 10 seconds.

回复收藏 0 原文

~没有更多了~