性能问题

2013-03-20 09:30:08 1k 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

Oracle 性能问题排查 Oracle 性能问题排查应用程序层面代码逻辑问题：检查应用程序的代码逻辑，看是否存在不合理的查询语句或者频繁的数据库操作。例如，是否有不必要的嵌套查询、循环中多次执行相同的 SQL 语句等。可以使用代码审查工具或者日志记录来定位问题代码。连接池配置：确认应用程序的数据库连接池配置是否合理。如果连接池的最大连接数设置过小，可能会导致应用程序在高并发情况下等待数据库连接，从而影响响应时间。可以调整连接池的参数，如最大连接数、最小连接数、连接超时时间等。阅读详情

问题：
当并发访问到达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的数据库连接是不是有限制？

欢迎指导。

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

...全文

对Java的性能问题的一些思考《Java性能优化全流程指南》摘要：本文系统化介绍了Java性能问题的诊断与优化方法。首先详细阐述了问题定位环节，包括常用工具集（JConsole、MAT、Arthas等）和诊断流程（CPU、内存、GC等维度分析）。其次针对五大典型性能瓶颈（CPU过高、内存泄漏、GC频繁、线程阻塞、I/O瓶颈）给出具体优化方案，涵盖代码重构、JVM参数调优、并发控制等关键技术。最后提出架构级优化方向（水平扩展、异步化等）和优化原则（数据驱动、平衡取舍）。强调性能优化应遵循"先诊断后优化"原则，通过工具定阅读详情

轻舟已过万重山

.NET社区 62,271 成员 668,968 内容

+ 关注 + 加入社区

切换为时间正序

轻舟已过万重山 2013-04-04

打赏
举报

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

Scorip 2013-04-03

打赏
举报

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

轻舟已过万重山 2013-04-03

打赏
举报

引用 46 楼 DBA_Huangzj 的回复:

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

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

轻舟已过万重山 2013-04-03

打赏
举报

引用 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/

开着拖拉机泡妞 2013-04-03

打赏
举报

引用 53 楼 skytear 的回复:

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

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

轻舟已过万重山 2013-04-03

打赏
举报

引用 47 楼 TravyLee 的回复:

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

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

昵称被占用了 2013-04-03

打赏
举报

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

riskyvall 2013-04-03

打赏
举报

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

發糞塗牆 2013-04-03

打赏
举报

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

發糞塗牆 2013-04-03

打赏
举报

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

开着拖拉机泡妞 2013-04-03

打赏
举报

--查询阻塞

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

开着拖拉机泡妞 2013-04-03

打赏
举报

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

發糞塗牆 2013-04-03

打赏
举报

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

ye.xuan 2013-04-03

打赏
举报

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

轻舟已过万重山 2013-04-03

打赏
举报

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

發糞塗牆 2013-04-03

打赏
举报

引用 56 楼 skytear 的回复:

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

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

战灬龙 2013-04-03

打赏
举报

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

足球中国 2013-04-02

打赏
举报

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

md5e 2013-04-02

打赏
举报

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

轻舟已过万重山 2013-04-02

打赏
举报

引用 37 楼 liuchaolin 的回复:

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

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

加载更多回复（39）

性能问题

相关推荐