在我们由Google Cloud管理的MySQL实例上,我们遇到以下问题。
...从图片中可以看出,CPU使用率100%已超过5小时。这是不正常的。
尝试
-通过Google Cloud Shell连接到MySQL实例。执行show full processlist;
和show processlist
...那里没什么有趣的。
-已执行SHOW ENGINE INNODB STATUS\G;
。我没问题。
-Google Stackdriver Monitoring没有提供任何我可以使用的额外信息。相同的CPU使用率图表。
总的来说,我看不到MySQL实例本身是不好的。在MySQL实例上具有数据的服务通常会执行。
那么我如何获取有关MySQL托管实例上实际使用CPU的信息?
我当然可以重新启动实例,问题可能会再次消失,但是我想深入了解这里的情况。
信息: -MySQL v5.7
非常感谢您。
更新181206
SHOW GLOBAL STATUS;
,在这里找到它-> https://pastebin.com/M67FD5Vk SHOW GLOBAL VARIABLES;
,在这里找到它-> https://pastebin.com/cvsytBMY db-n1-standard-1
。此处更多-> https://cloud.google.com/sql/docs/mysql/pricing#2nd-gen-instance-pricing SHOW FULL PROCESSLIST;
,在这里找到它-> https://pastebin.com/XNPgcBms 答案 0 :(得分:0)
尝试restarting the instance,看看是否有帮助。
答案 1 :(得分:0)
每秒速率= RPS-有关您的Google Cloud Database标志的建议
log_error=/mysql/logs/error.log # from default of stderr will allow you to view your entries and take corrective action
max_connections=512 # from 4000 to conserve RAM and your max_used_connections was 110 in 6 days
thread_cache_size=100 # from 48 to reduce threads_created of 204 (for CPU busy reduction)
innodb_flush_neighbors=0 # from 2 you have SSD and should be using 0 per refman
innodb_lru_scan_depth=100 # from 2048 to reduce CPU busy every second
innodb_page_cleaners=4 # from 1 to expedite cleaning and reduce innodb_buffer_pool_pages_dirty of 791
open_files_limit=10000 # from 1,048,576 will conserve RAM and be adequate
query_cache_size=0 # from 1M to conserve RAM - you are NOT using QC
query_cache_limit=0 # from 1M to conserve RAM - you are NOT using QC
需要进行研究以探索为什么 A)6天之内有56,133个aborted_clients B)com_stmt_prepare比com_stmt_close大213,这意味着完成后6天之内资源没有释放213次 C)是否有必要在您的标志中启用innodb_log_compressed_pages? 这会导致系统每14分钟轮换一次您的日志文件,从而每1/2小时产生1GB日志记录的一部分。
使用名为findfragtables.sql的实用程序脚本,可以帮助您确认表是否已压缩,因此可以使用CPU对每个活动进行解压缩。在innodb_compression_level = 6时,您花费大量的CPU时间进行压缩。 删除,插入,更新平均每天6538次,连续6天似乎很忙。
您可以在我的个人资料“网络”个人资料中找到我的联系信息。