Listener监听器问题分析
Listener监听器问题分析2节点RAC数据库，版本为9.2.0.6。问题现象为当监听器LISTENER运行超过一定时间后(例如12小时)，LISTENER会出现HANG/SLOW的现象，导致CLIENT登陆数据库连接超时。
对于上述问题目前采取了定期重启监听并清理日志方式Workaround该问题。
由于缺少 LISTENER SLOW/HANG时的TRACE以及STACK CALL等信息，无法定位到具体的问题或BUG。 建议根据文档How to Diagnose Slow TNS Listener / Connection Performance 所介绍的方法，设置LISTENER NET TRACE并利用OS跟踪工具获得问题发生时的STACK CALL和SYS CALL。
{mac1} /oracle/app/oracle/product/9.2.0/network/admin> ps -ef|grep tns
oracle 13161910 24196452 0 15:24:51 pts/3 0:00 grep tns
oracle 15840688 1 3 13:37:00 - 3:21 /oracle/app/oracle/product/9.2.0/bin/tnslsnr LISTENER -inherit
{mac1} /oracle/app/oracle/product/9.2.0/network/admin> ps vg|grep 15840688
15840688 - A 3:24 2 18256 20552 xx 9327 2296 0.0 0.0 /oracl
{mac1} /oracle/app/oracle/product/9.2.0/network/admin> ps vg|grep 15840688
15840688 - A 3:24 2 18268 20564 xx 9327 2296 0.0 0.0 /oracl
..........................
{mac1} /oracle/app/oracle/product/9.2.0/network/admin> ps vg | grep 15840688 ; vmstat
15840688 - A 4:00 2 19568 21864 xx 9327 2296 0.0 0.0 /oracl
通过ps vg命令可以看到监听器进程tnslsnr的RSS内存使用量在约半个小时内增长了1300*4k=5M。该内存增长的现象与已知的Bug 5576565 - Small listener memory leak per connection (Doc ID 5576565.8)较为相似，但该BUG仅确认在版本9.2.0.8上发生。且由于缺少必要的LISTENER NET TRACE和STACK CALL，所以无法确诊为该BUG。
Bug 5576565 Small listener memory leak per connection
This note gives a brief overview of bug 5576565.
The content was last updated on: 03-APR-2009
Click here for details of each of the sections below.
Affects:
Product (Component) Oracle Net Services
Range of versions believed to be affected Versions >= 9.2.0.8 but BELOW 10.1
Versions confirmed as being affected • 9.2.0.8
Platforms affected Generic (all / most platforms affected)
It is believed to be a regression in default behaviour thus:
Regression introduced in 9.2.0.8
Fixed:
This issue is fixed in • 9.2.0.8 Patch 1 on Windows Platforms
Symptoms: Related To:
• Leak (Memory Leak / Growth)
• Network
Description
A small memory leak occurs in the listener process per connection.
The leak is small and so may go unnoticed for a long time unless
the system has very high connect rates.
Workaround:
Restart the listener periodically.
3. 建议
针对以上监听器问题，可以考虑以下三种方法绕过该问题：
1. 定期重启监听器(当前使用)
2. 配置多个监听器LISTENER，针对不同的应用模块使用不同的监听器，以便多个监听能够均衡负载连接，降低该问题出现的概率
3.使用版本10.2.0.5的监听器(建议在充分测试的前提下)，需要安装一个版本10.2.0.5的ORACLE_HOME，并将Instance/Service注册到10.2.0.5的监听上，Metalink文档<Which Listener To Use For Multiple Version Oracle Database Instances ? >介绍了10gR2的监听器可以与9iR2实例一起正常工作：
A version 10g listener is required for an Oracle Database 10g database. Previous versions of the listener (e.g.8i, 9i) are not supported for use with Oracle Database 10g instance(s). However, the following combinations are supported:
The 10gR1 listener will work with database versions 8i through 10gR1.
The 10gR2 listener will work with database versions 9i through 10gR2.
建议在测试环境中充分测试应用通过10gR2 Listener建立连接的具体表现后考虑该方案
页:
[1]