mssql数据库占用CPU过高

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可以更好的支持高并发调用。

修改mycnf，添加如下参数并重启

[mysqld_safe]malloc-lib=tcmalloc

上周五早上7点执行的 *** 作，到现在超过72小时，期间该实例没有再出现cpu长期飙高的情形。

以下是修改前后cpu使用率对比

没啥办法，SQL Server 自带的那些性能分析工具绝大部分都是从 2003 以后的版本才开始提供的。

但绝大部分 CPU 飙升都是因为错误的索引或者没有索引导致的查询效率降低。

网上一搜一堆的脚本。使用sysdatabases和sysdm_exec_sessions,sysdm_exec_connections三个DMV进行关联就可以。语句你自己去网上找吧，希望你能靠自己学会解决问题。

简单地说，由于SQL2000太老了，2000年那时候还没有那么多CPU，所以最多只能认到16个。建议还是上SQL Server 2005或2008企业版。具体SQL Server支持的最大CPU，内存等信息在SQL Server帮助文件的安装需求里面都有。例如下面的链接是SQL Server 2008R2支持的最大CPU和内存等数量。可以看到，即使是SQL Server 2008R2这样最新的数据库软件，企业版最多支持的CPU也只是8个。你可以装一个SQL Server 2008 试试看，如果还是不能全部认出，就需要数据中心版的SQL Server了。

>

以上就是关于mssql数据库占用CPU过高全部的内容，包括:mssql数据库占用CPU过高、SQL Server2000中如何查询CPU占用高的SQL语句、SQLServer一个实例有很多数据库，如何查询该实例所有数据库的消耗CPU占Top50的SQL脚本等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！