应用数据库典型的三大类性能问题(笔记)
2015-06-16 14:50
218 查看
1、过量的数据库调用
问题:常见的性能瓶颈来自过量的数据库调用,引发这些问题不一定是SQL查询的Execute()或Update(),而是应用程序与数据库的交互有关,例如,ResultSet操作,常见的问题是指定了过于精细的查询条件,然后使用ResultSet.Next()详细搜寻返回的数据。
解决办法:从数据库中大量取得所要求的数据,避免应用程序反复回掉数据库。
2、数据库连接池问题
问题1:连接池资源泄露。
虽然可以通过WebLogic自带工具、Jprofiler工具或自编工具检测到数据库连接池资源泄露,但是很难再应用程序代码本身准确定位泄露的源头。
解决办法:仔细分析程序代码,是否没有close()连接?是否遗漏了finally块?或者尽管有close()但并没有成功。
问题2:连接池大小。
连接池过小会导致连接池满后,新的客户无法连接上系统,在日志中出现错误信息。一般的解决方法是增大连接池。但另一方面,连接池过大会造成资源无效损耗,可能会出现新的性能问题。那么连接池调到多大比较合适呢?
解决办法:
经验法则1:设置最初池大小=最大池大小。
经验法则2,数据库连接池数=线程池数*每个线程需要连接数据库的平均数*1.1(1.1的含义是增加10%的峰值期负载),通常每个线程需要连接数据库的平均数是1,即当线程数为120时,数据库连接池数就是132.
3、SQL语句及其索引或锁定属性问题
问题:SQL语句及其索引或锁定属性不合理可能引发DISKIO过忙(磁盘读/写数据)或者CPU过忙(在内存中索引排序),造成执行时间过长,阻塞线程的执行,最终引发系统挂起或者执行超时引发系统挂起。
解决方法:优化SQL语句及其索引或锁定属性。
问题:常见的性能瓶颈来自过量的数据库调用,引发这些问题不一定是SQL查询的Execute()或Update(),而是应用程序与数据库的交互有关,例如,ResultSet操作,常见的问题是指定了过于精细的查询条件,然后使用ResultSet.Next()详细搜寻返回的数据。
解决办法:从数据库中大量取得所要求的数据,避免应用程序反复回掉数据库。
2、数据库连接池问题
问题1:连接池资源泄露。
虽然可以通过WebLogic自带工具、Jprofiler工具或自编工具检测到数据库连接池资源泄露,但是很难再应用程序代码本身准确定位泄露的源头。
解决办法:仔细分析程序代码,是否没有close()连接?是否遗漏了finally块?或者尽管有close()但并没有成功。
问题2:连接池大小。
连接池过小会导致连接池满后,新的客户无法连接上系统,在日志中出现错误信息。一般的解决方法是增大连接池。但另一方面,连接池过大会造成资源无效损耗,可能会出现新的性能问题。那么连接池调到多大比较合适呢?
解决办法:
经验法则1:设置最初池大小=最大池大小。
经验法则2,数据库连接池数=线程池数*每个线程需要连接数据库的平均数*1.1(1.1的含义是增加10%的峰值期负载),通常每个线程需要连接数据库的平均数是1,即当线程数为120时,数据库连接池数就是132.
3、SQL语句及其索引或锁定属性问题
问题:SQL语句及其索引或锁定属性不合理可能引发DISKIO过忙(磁盘读/写数据)或者CPU过忙(在内存中索引排序),造成执行时间过长,阻塞线程的执行,最终引发系统挂起或者执行超时引发系统挂起。
解决方法:优化SQL语句及其索引或锁定属性。
相关文章推荐
- android searchView的关闭事件
- 数据中心和云未来的十二大趋势
- 使用 Iisext.vbs 删除应用程序依存关系的实现方法
- Delphi实现检测并枚举系统安装的打印机的方法
- Sql Server 应用程序的高级Sql注入第1/2页
- CMD命令行中以管理员权限启动应用程序实现方法
- 计算机信息处理
- asp数据库连接rs("user.id")
- 解析MYSQL显示表信息的方法
- rails创建应用程序实例
- C#检测远程计算机端口是否打开的方法
- C#实现回文检测的方法
- asp连接SQL和Access数据代码(asp里的随机函数)
- C#检测DataSet是否为空的方法
- 实现android应用程序自动化测试的批处理脚本
- UTF-8 编码中BOM的检测与删除
- SqlServer强制断开数据库已有连接的方法
- C#检测是否有u盘插入的方法
- 使用 iisext.vbs 添加应用程序依存关系的实现方法
- Lua检测数组(tabble)中是否包含某个值