其实这是一篇技术文章。

最近比较忙,通宵干活也逐渐平常起来,BLOG更新也少了,其实想写的东西挺多的。

闲话少扯,切入正题。

■ Poor connection management can cause poor response times and unreliable
systems.
----摘自《Oracle Database Performance Tuning Guide 10g Release 2 (10.2)》”Understanding Scalability--Factors Preventing Scalability“一节.

■ Good Database Connection Management
Connecting to the database is an expensive operation that is highly unscalable.
Therefore, the number of concurrent connections to the database should be
minimized as much as possible. A simple system, where a user connects at
application initialization, is ideal. However, in a Web-based or multitiered
application, where application servers are used to multiplex database connections
to users, this can be difficult. With these types of applications, design efforts
should ensure that database connections are pooled and are not reestablished for
each user request.

----摘自《Oracle Database Performance Tuning Guide 10g Release 2 (10.2)》”Application Design Principles--SQL Execution Efficiency“一节.

1. Bad Connection Management
The application connects and disconnects for each database interaction. This
problem is common with stateless middleware in application servers. It has over
two orders of magnitude impact on performance, and is totally unscalable.

----摘自《Oracle Database Performance Tuning Guide 10g Release 2 (10.2)》”The Oracle Performance Improvement Method--Top Ten Mistakes Found in Oracle Systems“一节.

以上的内容,全部是关于连接管理(connection management)的,也就是应用系统连接到数据库的方式,其中之一就是,是使用长连接还是短连接。其实在以前,我看到如上所述的内容,并没有引起重视的,甚至可以说是不以为然。因为现在的使用Oracle数据库的大型的高并发的应用系统,在连接数据库上,一般都是使用了连接池,连接管理基本上都不存在什么问题。

然而事实证明,我错了。就在前不久,遇上一套系统,Oracle数据库的会话数保持在4000以上的高并发系统,一个关键的应用居然用的短连接。不幸的是,这个应用连接数据库的速率非常的快,而创建一个数据库的连接耗时非常的长,闲时都在150ms以上。在业务高峰期,连接数据库的排队已经非常高,Listener已经不能够及时处理连接请求,连接数据库通常需要1s以上,甚至数秒,严重影响了系统的性能。就算使用两个Listener都已经承受不了压力。

解决这个问题的根本办法还是修改应用,使用连接池。

看起来真是“只有想不到,没有做不到”,一切皆有可能啊。

Trackback

15 comments untill now

  1. “通宵干活也逐渐平常起来”——注意身体!

    [回复]

    老熊 回复:

    @cui hua, 谢谢。驻场就是这样子的。

    [回复]

  2. 不是生活所迫,没有人愿意做DBA!

    [回复]

    老熊 回复:

    @ztg, 延伸一点说,不是生活所迫,谁愿意搞IT啊。

    [回复]

  3. “这个应用连接数据库的速率非常的快,而创建一个数据库的连接耗时非常的长,闲时都在150ms以上。在业务高峰期,连接数据库的排队已经非常高,Listener已经不能够及时处理连接请求,连接数据库通常需要1s以上,甚至数秒”
    熊哥,你这些信息是通过什么方法观察的?

    [回复]

    老熊 回复:

    @OoNiceDream, 我是通过如truss、tusc这样的工具跟踪的。

    [回复]

  4. 老熊 Reply:

    6月 15th, 2009 at 2:59 下午

    @ztg, 延伸一点说,不是生活所迫,谁愿意搞IT啊。

    再延伸一下,不是生命所迫,谁愿意做人啊

    [回复]

    老熊 回复:

    @boypoo, 老大,你太有才了。

    [回复]

  5. 都不容易.

    [回复]

  6. 想请教一个问题,你在文章里提到该系统在闲时连接耗时在150MS以上,是在什么平台上?
    最近在测试过程中发现,使用JDBC建立Dedicate连接,在Solaris上一般耗时都在130MS以上,在WIndows上只有30MS左右,这个应该认为是正常现象么?

    [回复]

    老熊 回复:

    @Ford, 在HP IA64,11.31上。那个时间有些不正常,但不会离谱很多。
    Windows使用的是多线程模式,而UNIX使用的是多进程模式,相对来说Windows起一个Dedicate连接会快点。连接耗时跟不同的系统和系统负荷有关系。

    [回复]

    老熊 回复:

    @Ford, 关于你的问题,可以参考一下:http://milek.blogspot.com/2008/11/oracles-listener-performance.html

    [回复]

  7. […] 那问题出在哪?我首先观察到内存的使用率相当地高,达到99%。但是从操作上看,速度还没受到影响。不过很快想到,这个系统某些模块,用了短连接,难道是监听太慢引起的?这个库启了6个监听(详见《一切皆有可能》,分别TNSPING这几个监听,有个别监听非常慢,重启监听后,查询功能比较慢的问题得到解决。 […]

  8. 熊哥,有点奇怪

    如果我想跟踪SQLPLUS登陆,我会使用
    truss -/tmp/a.out sqlplus “/as sysdba”但是我这个是直接登到服务器直接跟踪,我很奇怪你说的慢是指用户通过客户端登陆慢,如何使用truss进行跟踪的?

    [回复]

  9. 熊哥,问个问题:在数据库中,我怎么能看出一个连接是长连接、短连接还是通过连接池连接的呀?

    [回复]

Add your comment now