tns连接非常慢

Yong Huang

truss -fdD is good. You can check the truss output first. Identify the big timestamp jumps. If there's none, then it's hard to say where the bottleneck is. It could simply be that the tnslsnr process is stressed in general. If the process virtual memory is indeed > 2G (see 老熊's message #24), that's almost certainly a problem. My listeners on various servers have at most 140 M. This one is 11gR2:

$ ps -ef | grep [t]ns
oracle   26945     1  0 Aug08 ?        00:00:19 /u01/app/grid/bin/tnslsnr LISTENER -inherit
$ ps -o vsz 26945
   VSZ
142736

Keep checking yours to see if the size always goes up. If it does, search for "listener memory leak" on MOS.

Yong Huang

magic007

正如HUANG版所说，如果在TRACE中没有明显的时间上的跳跃，那就是监听工作相对较慢。这种慢不是那么明显。从整体时间上来说，假如正常时监听50ms处理一个连接，现在100ms处理一个连接，慢了整整一倍，但是从TRACE的时间上你不一定能够分析出什么问题，很难看到有明显的跳跃。

9208下监听的内存泄露的问题很普遍，常见的BUG是5576565。

你的监听用的内存超过了2G，这2G应该是由很多细小的内存片构成，而不是由大块的内存构成，这对单个进程来说，管理如此多的内存碎片会是一个严重的负担。

huanhuanlove

用了2g多 很大了啊。。。

BTxigua

原帖由 magic007 于 2010-8-13 11:15 发表
正如HUANG版所说，如果在TRACE中没有明显的时间上的跳跃，那就是监听工作相对较慢。这种慢不是那么明显。从整体时间上来说，假如正常时监听50ms处理一个连接，现在100ms处理一个连接，慢了整整一倍，但是从TRACE的时间上你不一定能够分析出什么问题，很难看到有明显的跳跃。

9208下监听的内存泄露的问题很普遍，常见的BUG是5576565。

你的监听用的内存超过了2G，这2G应该是由很多细小的内存片构成，而不是由大块的内存构成，这对单个进程来说，管理如此多的内存碎片会是一个严重的负担。

出差了一个星期。

我重启了监听程序，从这些日子的情况来看，貌似问题解决了。
在我重启监听程序之后，监听能够处理的连接请求也不再是原来的每秒1个了，而变成22个了。
可能就是你所说的内存碎片太多了。整体处理效率比较低了。

[ 本帖最后由 BTxigua 于 2010-8-19 13:08 编辑 ]

Yong Huang

I'm curious, what components take the biggest chunk of the memory? On AIX, try

procmap <listener pid>

Record the output over the period of memory leak (perhaps a few weeks) and check which part is growing in size.

Yong Huang

BTxigua

$ ps -ef | grep tns
  oracle  970762 1048850   0 19ʱ24·Ö07Ãë  pts/1  0:00 grep tns
  oracle 2060506       1   0        8ÔÂ19      -  2:26 /oracle/app/oracle/product/9.2.0/bin/tnslsnr LISTENER -inherit
$ procmap  2060506
2060506 : /oracle/app/oracle/product/9.2.0/bin/tnslsnr LISTENER -inherit
100000000      10243K  read/exec         tnslsnr
1100003f0        619K  read/write        tnslsnr
9fffffff0000000        41K  read/exec         /usr/ccs/bin/usla64
9fffffff000a72a         0K  read/write        /usr/ccs/bin/usla64
9000000002ce280         2K  read/exec         /usr/lib/libcrypt.a[shr_64.o]
9001000a0295760         0K  read/write        /usr/lib/libcrypt.a[shr_64.o]
90000000089efb8         4K  read/exec         /usr/lib/libc.a[aio_64.o]
9001000a032d988         0K  read/write        /usr/lib/libc.a[aio_64.o]
900000000785040        84K  read/exec         /usr/lib/libodm.a[shr_64.o]
9001000a0323588        35K  read/write        /usr/lib/libodm.a[shr_64.o]
90000000072c000         0K  read/exec         /usr/lib/libdl.a[shr_64.o]
9001000a0322000         0K  read/write        /usr/lib/libdl.a[shr_64.o]
90000000074d000       222K  read/exec         /usr/lib/libpthreads.a[shr_xpg5_64.o]
9001000a0296000       559K  read/write        /usr/lib/libpthreads.a[shr_xpg5_64.o]
900000000046220      2571K  read/exec         /usr/lib/libc.a[shr_64.o]
9001000a01cf008       788K  read/write        /usr/lib/libc.a[shr_64.o]
   Total       15176K

jsmssc:[/]#svmon -P 2060506

-------------------------------------------------------------------------------
     Pid Command          Inuse      Pin     Pgsp  Virtual 64-bit Mthrd  16MB
2060506 tnslsnr          88229    65584        0    78464      Y     N     N

     PageSize      Inuse        Pin       Pgsp    Virtual
     s   4 KB      14501          0          0       4736
     m  64 KB        512          3          0        512

    Vsid      Esid Type Description              PSize  Inuse   Pin Pgsp Virtual
       0         0 work kernel segment (lgpg_vsid=0) L     16    16    0    16
  1870b0  90000000 work shared library text          m    507     0    0   507
  2a3acc         - pers large file /dev/lv03:8892    s   6159     0    -     -
   e8e1f        10 pers text data BSS heap,large fil s   3589     0    -     -
                        /dev/lv03:114878                                       
    8001  9ffffffd work shared library               s   2294     0    0  2294
   9d204        11 work text data BSS heap           s   2194     0    0  2194
  3702ec  90020014 work shared library               s    139     0    0   139
   1c99a f00000002 work process private              m      5     3    0     5
  3a7a63  9001000a work shared library data          s     67     0    0    67
   30086  9ffffffe work shared library               s     17     0    0    17
  3982f1  9fffffff pers USLA text,/dev/hd2:10564     s     14     0    -     -
  2818ca  ffffffff work application stack            s     12     0    0    12
  1d9eab  80020014 work USLA heap                    s      8     0    0     8
  2007cd  8fffffff work private load data            s      5     0    0     5
  368def         - pers large file /dev/lv03:49199   s      3     0    -     -
  26aadb  fffffff8 work application stack            s      0     0    0     0
  15c53f  fffffff5 work application stack            s      0     0    0     0
  1a8e37         - pers large file /dev/lv03:49171   s      0     0    -     -
  27105e  fffffff2 work application stack            s      0     0    0     0
   8b108  fffffffb work application stack            s      0     0    0     0
   8081e  fffffff1 work application stack            s      0     0    0     0
    bd90  fffffffc work application stack            s      0     0    0     0
  17e73d  fffffff4 work application stack            s      0     0    0     0
   ec613  fffffff6 work application stack            s      0     0    0     0
  3117ef  fffffff7 work application stack            s      0     0    0     0
  3f58f3  fffffffa work application stack            s      0     0    0     0
  312d73  fffffff3 work application stack            s      0     0    0     0
  13b4af  fffffffd work application stack            s      0     0    0     0
   7a618  fffffff9 work application stack            s      0     0    0     0
  1c06bd  fffffffe work application stack            s      0     0    0     0
  3580f1  fffffff0 work application stack            s      0     0    0     0

BTxigua

原帖由 Yong Huang 于 2010-8-20 02:45 发表
I'm curious, what components take the biggest chunk of the memory? On AIX, try

procmap

Record the output over the period of memory leak (perhaps a few weeks) and check which part is growing in size.

Yong Huang

thanks.
先记录一个，以后再来对比。

thompsun

不错,学习了

lei

这个帖子要顶，刚好遇到9208的这个费解问题，9207连接很快，监听启动了三个多月，结果hpux glance内存是700多MB，原来是bug。

rolleaway

遇到同样的问题，楼主怎样解决的？