性能问题

[轻舟已过万重山]

问题：
当并发访问到达300人左右，系统有时候很慢很慢，经常数据库连接都打不开，ASP报ODBC错误，ASP.NET报连接超时错误。此时去监控Web服务器和DB服务器，其实资源消耗都不大，最多也就是50%。

尝试过的解办法：数据库服务器允许的连接数设置为0了，理论上无限制。
把ASP.NET的连接池加大到512，貌似由此ASP的应用程序打不开连接的情况更多了。

用SQL Trace确实发现有很多执行非常慢的SQL，但是否理论上某个执行很慢的SQL不会影响到其他用户正常访问应用程序?除非这些执行很慢的SQL把表都锁住了？但通过Select * from sysprocesses where blocked<>0基本没发现有锁死的情况。

初步认为还是：Web Server到DB Server的数据库连接是不是有限制？

欢迎指导。


应用程序性能问题，猜和连接有关。

[轻舟已过万重山]

引用 37 楼 liuchaolin 的回复:

数据库太大就搞分区存储表呗,还有在就是程序上采用异步加载,用ajax分几次从数据库中读取数据储存到Session,然后控件再绑定Session

表分区也是要考虑的了。 SQL Server 引入的表分区技术，让用户能够把数据分散存放到不同的物理磁盘中，提高这些磁盘的并行处理性能以优化查询性能，主要是提高其I/O的效率吧？现在的磁盘是放到了通过光纤连接的存储上面，不知道这个时候分区与存储的关系，还会放到多个不同的物理磁盘中吗?连接了存储，好像都是一个磁盘了？

[md5e]

分区表以某以字段(一般是顺号或时间)为索引和分区条件,将相同属性的数据划分到一起,以提高查找效率 打个比方如果我们以a\b\c\d\e...来划分,我们想要找a的数据,我们只用读取a就可以了,其它b,c,d,e我们都不管

[足球中国]

打开profiler。。 记录下来。 重复的cache一下。 大数据量的分页。 无聊的刷着玩的关了。

[战灬龙]

看到前面各种高手的回答，我也借这个帖子问一个问题。 我这边有一个程序 是对SQL进行插入操作的。因为是在定时服务里 每次执行这个服务 CPU的使用率都会达到60%以上。应该是哪方面的原因。

[發糞塗牆]

引用 56 楼 skytear 的回复:

引用 46 楼 DBA_Huangzj 的回复: 1、数据库设计是重中之重。 2、如果你不知道哪里慢，要做监控，可以猜测，但是要有数据的支持，死锁会报错，很容易就发现，但是阻塞并不一定会暴露出来。在你觉得慢的时候，看看select * from sys.sysprocesses where blocked<>0有没有运行时间很久的进程。阻塞往往才是慢的原因。当然还有其他原因 3、这种情况下需……

先定位阻塞的原因，然后改sql，再改索引。但是作为试探性操作，也可以尝试先更改索引。但是要知道是什么原因造成阻塞，是资源不足？如tempdb太小、磁盘空间不足、IO、网络等。还是说因为语句的低效，导致了资源不足，然后产生阻塞。

[轻舟已过万重山]

在sys.dm_exec_query_status中查出来的Wait Type发现78.%的是CXPACKET，所以修改了: sp_configure 'max degree of parallelism', 16; --cpu 32核，原来是0，没有限制。 看起来允许的并发数降低了，同时降低了太多并发可能带来更多死锁机会，昨天一天，系统相对正常，仅仅有一次有人直接到数据库服务器导出大量数据的时候造成了一次整个应用程序连接不能打开的情况。

[xuan.ye]

300个用户卡死的可能性，应该就是4#说的原因了

[發糞塗牆]

1、数据库设计是重中之重。 2、如果你不知道哪里慢，要做监控，可以猜测，但是要有数据的支持，死锁会报错，很容易就发现，但是阻塞并不一定会暴露出来。在你觉得慢的时候，看看select * from sys.sysprocesses where blocked<>0有没有运行时间很久的进程。阻塞往往才是慢的原因。当然还有其他原因 3、这种情况下需要查看前端程序是否有频繁连接断开数据库的操作、网络是否有瓶颈。需要定位瓶颈。而不是随意加资源。300并发并不是什么大问题。

[开着拖拉机泡妞]

一直都在讨论死锁 但都没提到阻塞！ 那么多执行慢的SQL语句 为何不考虑阻塞？死锁SQL Server有自己的处理方式 但是阻塞 不行。

[开着拖拉机泡妞]

--查询阻塞

SELECT	A.request_session_id,
		B.blocking_session_id,
		B.resource_address,
		B.wait_type,
		B.wait_duration_ms,
		A.resource_associated_entity_id,
		A.resource_type,
		A.request_type,
		D.[text],
		G.request_type,
		F.[text]
FROM	SYS.dm_tran_locks AS A INNER JOIN
		SYS.dm_os_waiting_tasks AS B ON A.lock_owner_address=B.resource_address INNER JOIN
		SYS.dm_exec_requests AS C ON B.session_id=A.request_session_id CROSS APPLY
		SYS.dm_exec_sql_text(C.sql_handle) AS D LEFT JOIN 
		SYS.dm_exec_requests AS E ON E.session_id=B.blocking_session_id OUTER APPLY
		SYS.dm_exec_sql_text(E.sql_handle) AS F LEFT JOIN
		SYS.dm_tran_locks AS G ON E.session_id=G.request_session_id

[發糞塗牆]

通过Select * from sysprocesses where blocked<>0基本没发现有锁死的情况。 这个不是拿来查死锁的，是看阻塞用的。

[發糞塗牆]

sp_configure 'max degree of parallelism', 16 这个是告诉SQLServer每一个语句最多只能用16核，而不是说并发只能到16，SQLServer依然会使用32核的

[riskyvall]

建議查查大型數據表結構是否有索引index 和 where 是不有LIKE 等模糊查詢 ，如果有請修改 我是深有體會

[昵称被占用了]

没有仔细看之前的回复，可能有些说法有重复 1、服务和数据库部署在一起很可能出现资源争用，特别是内存资源和I/O资源，内存一般需要设置SQL SERVER的最大内存数，以保证数据库不占用服务和程序的内存 2、既然发现很多SQL长时间，必然需要解决，SQL长时间运行主要不是占用资源，而是形成诸塞和死锁，解决方法除了SQL优化外，需要考虑索引优化

[轻舟已过万重山]

引用 47 楼 TravyLee 的回复:

一直都在讨论死锁 但都没提到阻塞！ 那么多执行慢的SQL语句 为何不考虑阻塞？死锁SQL Server有自己的处理方式 但是阻塞 不行。

是的，是阻塞。SQL效率太低，需要优化SQL语句，优化数据库索引。

[开着拖拉机泡妞]

引用 53 楼 skytear 的回复:

引用 47 楼 TravyLee 的回复:一直都在讨论死锁 但都没提到阻塞！ 那么多执行慢的SQL语句 为何不考虑阻塞？死锁SQL Server有自己的处理方式 但是阻塞 不行。 是的，是阻塞。SQL效率太低，需要优化SQL语句，优化数据库索引。

有需要可以私聊 估计你那也不是一两个语句的问题！ QQ 812792011 现在对优化的问题比较感兴趣

[轻舟已过万重山]

引用 50 楼 DBA_Huangzj 的回复:

sp_configure 'max degree of parallelism', 16 这个是告诉SQLServer每一个语句最多只能用16核，而不是说并发只能到16，SQLServer依然会使用32核的

在sys.dm_exec_query_status中查出来的Wait Type发现78.%的是CXPACKET，所以修改了: sp_configure 'max degree of parallelism', 16; --cpu 32核，原来是0，没有限制。 改这个参数也是没搞清楚具体的用法，参考了博客： http://blog.sqlauthority.com/2011/02/06/sql-server-cxpacket-parallelism-usual-solution-wait-type-day-6-of-28/

[轻舟已过万重山]

引用 46 楼 DBA_Huangzj 的回复:

1、数据库设计是重中之重。 2、如果你不知道哪里慢，要做监控，可以猜测，但是要有数据的支持，死锁会报错，很容易就发现，但是阻塞并不一定会暴露出来。在你觉得慢的时候，看看select * from sys.sysprocesses where blocked<>0有没有运行时间很久的进程。阻塞往往才是慢的原因。当然还有其他原因 3、这种情况下需要查看前端程序是否有频繁连……

是的，阻塞是大问题，连接打不开的时候能发现很多的阻塞。 解决阻塞最直接的就是改SQL，建索引吧？

[Scorip]

看了半天，学习下。推荐楼主去 MSSQL 版块去看看。牛人很多。。自己没事的时候也喜欢往 MSSQL 跑。

[轻舟已过万重山]

得到很多的帮助，非常感谢！