如何诊断和解决CPU高度消耗(100%)的数据库
发布网友
共3个回答
懂视网
1<System.__Canon>) 000000000e6bc160 000007fe99238ec6 System.Data.Entity.Infrastructure.Interception.DatabaseLogFormatter.ReaderExecuting(System.Data.Common.DbCommand
2.进一步分析，二代龄要回收的对象太多。
Heap 0 generation 0 has 35 finalizable objects (000000000f312ec0->000000000f312fd8) generation 1 has 4 finalizable objects (000000000f312ea0->000000000f312ec0) generation 2 has 48152 finalizable objects (000000000f2b4de0->000000000f312ea0) Ready for finalization 0 objects (000000000f312fd8->000000000f312fd8) ------------------------------ Heap 1 generation 0 has 12 finalizable objects (000000001165a780->000000001165a7e0) generation 1 has 3 finalizable objects (000000001165a768->000000001165a780) generation 2 has 49727 finalizable objects (00000000115f9570->000000001165a768) Ready for finalization 0 objects (000000001165a7e0->000000001165a7e0) ------------------------------ Heap 2 generation 0 has 19 finalizable objects (00000000115a4c30->00000000115a4cc8) generation 1 has 9 finalizable objects (00000000115a4be8->00000000115a4c30) generation 2 has 42725 finalizable objects (00000000115514c0->00000000115a4be8) Ready for finalization 0 objects (00000000115a4cc8->00000000115a4cc8) ------------------------------ Heap 3 generation 0 has 18 finalizable objects (000000000f36a9b8->000000000f36aa48) generation 1 has 14 finalizable objects (000000000f36a948->000000000f36a9b8) generation 2 has 44483 finalizable objects (000000000f313b30->000000000f36a948) Ready for finalization 0 objects (000000000f36aa48->000000000f36aa48)
且这些对象大都是EF相关的。
MT Count TotalSize Class Name 000007fef694bb40 3162 2276 System.Reflection.Emit.DynamicResolver 000007fef68e76d0 36109 866616 System.WeakReference 000007fe987e9f40 35941 4887976 System.Data.Entity.Core.EntityClient.EntityConnection 000007fe987d75f0 37157 5053352 MySql.Data.MySqlClient.MySqlConnection 000007fe987e7d58 35952 6615168 System.Data.Entity.Core.Objects.ObjectContext 000007fe98814690 35952 8053248 System.Data.Entity.Internal.LazyInternalContext
3.如上来看，疑点还是在仓储这块。
跟踪堆栈，来看MySqlConnection的话，考虑XDbContext : IDisposable的销毁方式是不是不够直接彻底。
这里读的连接没有销毁，印证了上述推断，再让他们检查一下该服务中有没有正确使用该仓储即可。
是不是有点成就感...我是不是应该先去找个妹子、结束单身才是正事啊??
高CPU、数据库无法读写的真凶
标签：ast windbg mysql structure tin res sys style dynamic
热心网友
oracle的性能判断需要综合数据库的多个运行指标来判断： 1、进程数量和占用cpu：这个主要看有没有长时间占用cpu的进行。通常会判断大出sql，需要优化；这个可以用执行计划或者awr报告查看； 2、内存占用：主要用系统命令查看ora_占用和系统
热心网友
CPU占用过高诊断思路
mpstat -P ALL 1，查看cpu使用情况，主要消耗在sys即os系统调用上
perf top，cpu主要消耗在_spin_lock
生成perf report查看详细情况
CPU主要消耗在mutex争用上，说明有锁热点。
采用pt-pmp跟踪mysqld执行情况，热点主要集中在mem_heap_alloc和mem_heap_free上。
Pstack提供更详细的API调用栈
Innodb在读取数据记录时的API路径为
row_search_for_mysql --》row_vers_build_for_consistent_read --》mem_heap_create_block_func --》mem_area_alloc --》malloc --》 _L_unlock_10151 --》__lll_unlock_wait_private
row_vers_build_for_consistent_read会陷入一个死循环，跳出条件是该条记录不需要快照读或者已经从undo中找出对应的快照版本，每次循环都会调用mem_heap_alloc/free。
而该表的记录更改很频繁，导致其undo history list比较长，搜索快照版本的代价更大，就会频繁的申请和释放堆内存。
Linux原生的内存库函数为ptmalloc，malloc/free调用过多时很容易产生锁热点。
当多条 SQL 并发执行时，会最终触发os层面的spinlock，导致上述情形。
解决方案
将mysqld的内存库函数替换成tcmalloc，相比ptmalloc，tcmalloc可以更好的支持高并发调用。
修改my.cnf，添加如下参数并重启
[mysqld_safe]malloc-lib=tcmalloc
上周五早上7点执行的操作，到现在超过72小时，期间该实例没有再出现cpu长期飙高的情形。
以下是修改前后cpu使用率对比
