[20180926]共享池中的NETWORK BUFFER.txt

[20180926]共享池中的NETWORK BUFFER.txt --//最近几天一直在探究SQL*Net more data from client 相关等待事件,发现SDU相关,自己也网上探究一些帖子,找到刘公的一个帖子. --//链接:http://www.askmaclean.com/archives/%e5%85%b1%e4%ba%ab%e6%b1%a0%e4%b8%ad%e7%9a%84network-buffer.html --//虽然大多少场合使用dedicated server模式，而如果采用共享服务器模式,NETWORK BUFFER将被大量使用。MOS文档[741523.1]叙述了 --//NETWORK BUFFER的主要用途: On 10.2, after upgrading from 9iR2, the following error occurs: ORA-07445: exception encountered: core dump [] [] [] [] [] [] plus Dispatcher Trace file contains an ORA-4031 Diagnostic trace, with: Allocation request for: NETWORK BUFFER …followed by… found dead dispatcher 'D000', pid = (12, 1) The amount of memory used by NETWORK BUFFERs in the shared pool has significantly grown between 9.2 and 10.2.  The side-effect is to run-out of Shared Pool memory (reporting an ORA-4031), when a large number of sessions are connecting to the server (in the order of 1000's). While a session is being established, we allocate 3 buffers each of 32k in size.  After the session is established, we use the 3 SDU-sized buffers, however we do not deallocate the 3x32k buffer we allocated initially. This issue has been logged in unpublished Bug 5410481. Additionally, there is  Bug 6907529. NS buffers are allocated based on the SDU specified by the user. The negotiated SDU could be considerably lower. The difference between these two is wasted. For example, the dispatcher specifies an SDU of 32k. Clients, by default, use an SDU of 8k. The remaining 24k is never used. Issue in Bug 6907529 is fixed in 11.2. Bug 5410481 is fixed in 10.2.0.3. As a workaround to 5410481, the ADDRESS part of DISPATCHERS parameter can be used to specify a smaller SDU size. For example: DISPATCHERS="(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp))(SDU=8192))" To implement the change; connect to the database as SYSDBA alter system set dispatchers='(address=(protocol=tcp)(host=IP-Address)(sdu=8192))(dispatchers=DispatcherCount)' scope=spfile; re-start the database --//当然这个bug在11.2.0.4下已经不复存在.但是在共享服务器模式下,NETWORK BUFFER将被大量使用,我还第一次知道,我决定测试看看: 1.环境: --//上班在11g的环境重复测试看看. SCOTT@book> @ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- -------------------------------------------------------------------------------- x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production SCOTT@book> show parameter dispatchers NAME            TYPE     VALUE --------------- -------- ------------------------------------- dispatchers     string   (PROTOCOL=TCP) (SERVICE=book,bookXDB) max_dispatchers integer SCOTT@book> show parameter shared_servers NAME               TYPE     VALUE ------------------ -------- ----- max_shared_servers integer  1 shared_servers     integer  1 SCOTT@book> select name,pool,bytes from v$sgastat where name like '%NETWORK%'; NAME                 POOL              BYTES -------------------- ------------ ---------- NETWORK BUFFER       shared pool       65576 2.建立测试脚本: $ cat b.sh #!/bin/bash for i in $(seq 100) do nohup   sqlplus -s scott/book@192.168.100.78:1521/book:shared <<EOF > /dev/null 2>&1 & select sysdate from dual ; host sleep 60 quit; EOF done 3.测试: SCOTT@book> select name,pool,bytes from v$sgastat where name like '%NETWORK%'; NAME                 POOL              BYTES -------------------- ------------ ---------- NETWORK BUFFER       shared pool      477176 $ source b.sh SCOTT@book> select name,pool,bytes from v$sgastat where name like '%NETWORK%'; NAME                 POOL              BYTES -------------------- ------------ ---------- NETWORK BUFFER       shared pool     4628744 --//4628744-477176 = 4151568 --//4151568/100/1024 = 40.54kb 4.继续测试,修改SDU=32768. --//修改sqlnet.ora加入,安装刘工文章介绍,最大32767. DEFAULT_SDU_SIZE=32768  SCOTT@book> select name,pool,bytes from v$sgastat where name like '%NETWORK%'; NAME                 POOL              BYTES -------------------- ------------ ---------- NETWORK BUFFER       shared pool      436016 $ source b.sh SCOTT@book> select name,pool,bytes from v$sgastat where name like '%NETWORK%'; NAME                  POOL              BYTES --------------------- ------------ ---------- NETWORK BUFFER        shared pool    16916464 --//16916464-436016 = 16480448 --//16480448/100/1024  = 160.94k 5.思考: --//http://www.askmaclean.com/archives/%e5%85%b1%e4%ba%ab%e6%b1%a0%e4%b8%ad%e7%9a%84network-buffer.html 你可能会问SDU是什么？Oracle NET缓存的数据以SDU为基本单位，SDU即 session data unit，一般默认为8192 bytes。当这些数据单元 被写满，或被client读取时，他们将被传递给Oracle Network层(oracle network layer)。譬如Data Guard环境中redo传输的每个Chunk 往往要大于8192 bytes，那么默认的SDU就不太适用。当有大量重做数据要传输到standby库时，增大SDU buffer的大小可以改善Oracle的 网络性能。你可以很方便的通过修改sqlnet.ora配置文件来修改SDU,如在该文件内加入以下条目: DEFAULT_SDU_SIZE=32767 /*修改全局默认SDU到32k*/ 当然你也可以在tnsnames.ora中定义服务别名时个别指定SDU，下文我们会用到。 如上文所述在版本10.2.0.3以前当会话建立时，Oracle会以dispatchers参数定义的SDU为单位，分配3个单位的NETWORK  BUFFER，而实际 上client端可能并未指定和dispatchers一致的SDU，若dispatchers中定义的SDU为32k，而client使用默认的8k SDU,则一个会话可能要浪 费3*32-3*8=72k的NETWORK BUFFER。 为什么共享服务器模式下会用到共享池中的NETWORK BUFFER，而独享服务器模式下没有呢？因为在独享服务器模式下每个会话所分配的三 个SDU是从PGA中获取的；当使用共享服务器模式时会话与服务进程形成一对多的映射关系，这三个SDU 的NETWORK BUFFER同UGA一样转移 到了SGA中。 --//这样如果缺省设置很大,不管共享还是专用模式,导致内存消耗增加. --//共享服务器模式消耗在共享池,如果大量连接使用这个模式,消耗也很大.而且这样配置要求共享池要设置大一些. --//专用服务器模式消耗在PGA.也会导致内存的消耗.