SDE问题排查简记

环境：

软件信息：

OS: Solaris 10

ArcSDE: 9.3.1

DBMS: Oracle10.2.0.3.0

配置信息：

Physical memory: 32G

Oracle的SGA_TARGET=16G

 

症状：

使用prstat –a（linux操作系统使用top命令）命令查看操作系统的进程系统，发现arcsde（安装sde的操作系统用户）使用了16G的内存，和oracle用户使用的一样。用户怀疑是我们的ArcSDE存在问题，过多的耗费了内存，导致用户自己开发的程序（以uway操作用户）无法申请到内存。

下图的右面的截图为prstat命令的输出结果：

排查过程：

（1） sde的服务一启动，此时没有任何的用户级别的连接，arcsde的用户就会显示占有16G的内存，此时查看arcsde只包括以下几个进程：

   1:  
-bash-3.00$ ps -u arcsde

   2:  
   PID TTY         TIME CMD

   3:  
 11789 pts/5       0:00 bash

   4:  
 12263 pts/4       0:00 bash

   5:  
 12428 ?           0:00 giomgr

   6:  
 12442 pts/4       0:00 ps

 

 

跟SDE相关的进程只有giomgr，但是通过prstat –p 12428查看giomgr进程发现如下信息

 

   1:  
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP

   2:  
 12428 arcsde     74M   74M sleep   59    0   0:00:00 0.0% arcsde/1

（2）怀疑是别的进程在占有内存，接着查看跟giomgr相关的进程，利用ptree命令查看giomgr的进程树。结果如下。

 

   1:  
-bash-3.00$ ptree 12428

   2:  
12428 /export/home/arcsde/arcgis/sdeexe93/sdeexe93/bin/giomgr /export/home/arcs

   3:  
  12429 oraclenoap (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

   4:  
 

   5:  
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP

   6:  
 12429 arcsde     16G   16G sleep   59    0   0:00:00 0.0% oracle/1

Giomgr的一个子进程的确显示占有16G的内存，但是这个进程是oracle用户的，通过进程的描述信息发现时oracle为giomgr这个session所开启的一个dedicated server进程，而这个进程是可以访问SGA区的。

由上面两条可以判断，oracle所开启的任何一个dedicated server 进程在操作系统级别上看应该都是占有16G的内存的，为了验证我的想法，随便再找一个dedicated server进程，如下：

   1:  
-bash-3.00$ ps -ef|grep ora

   2:  
  oracle 12461     1   0 11:10:31 ?           0:00 oraclenoap (LOCAL=NO)

   3:  
  oracle 12459     1   0 11:10:31 ?           0:00 oraclenoap (LOCAL=NO)

   4:  
  oracle 11346     1   0 10:00:57 ?           0:00 oraclenoap (LOCAL=NO)

   5:  
  oracle  1066     1   0  12月 22 ?           0:00 ora_q000_noap

   6:  
  oracle 11724     1   0 10:27:37 ?           0:00 oraclenoap (LOCAL=NO)

   7:  
  oracle  2690     1   0 19:30:14 ?           0:03 oraclenoap (LOCAL=NO)

   8:  
  oracle 11975     1   3 10:41:18 ?          22:49 ora_j002_noap

   9:  
  oracle 11732     1   0 10:27:47 ?           0:00 oraclenoap (LOCAL=NO)

  10:  
  oracle  3744     1   0 21:17:14 ?           0:02 oraclenoap (LOCAL=NO)

  11:  
  oracle 11344     1   0 10:00:42 ?           0:00 oraclenoap (LOCAL=NO)

  12:  
  oracle  1894     1   0 18:27:13 ?           0:04 oraclenoap (LOCAL=NO)

  13:  
  oracle 12415     1   0 11:07:15 ?           0:00 oraclenoap (LOCAL=NO)

  14:  
  oracle 12187     1   0 10:53:49 ?           0:03 oraclenoap (LOCAL=NO)

  15:  
  oracle 11276     1   0 09:56:06 ?           0:02 oraclenoap (LOCAL=NO)

  16:  
  oracle 11352     1   0 10:01:23 ?           0:00 oraclenoap (LOCAL=NO)

  17:  
  oracle  9918     1   1 07:54:15 ?          58:35 ora_j000_noap

  18:  
  oracle  1918     1   0 18:28:14 ?           0:04 oraclenoap (LOCAL=NO)

  19:  
  oracle 11947     1   0 10:39:28 ?           0:00 oraclenoap (LOCAL=NO)

  20:  
  oracle 12429 12428   0 11:07:42 ?           0:01 oraclenoap (DESCRIPTION

  21:  
 

  22:  
L=YES)(ADDRESS=(PROTOCOL=beq)))

  23:  
  arcsde 12463 12263   0 11:10:54 pts/4       0:00 grep ora

  24:  
  oracle 11998     1   0 10:42:16 ?           0:30 oraclenoap (LOCAL=NO)

   1:  
 oracle 12431     1   0 11:07:46 ?           0:00 oraclenoap (LOCAL=NO)

   2:  
  oracle  2380     1   0 19:02:51 ?           0:03 oraclenoap (LOCAL=NO)

   3:  
  oracle  2338     1   3 19:00:23 ?         915:31 ora_j001_noap

   4:  
  oracle 11931     1   0 10:38:21 ?           0:03 oraclenoap (LOCAL=NO)

   5:  
  oracle 11937     1   0 10:38:44 ?           0:00 oraclenoap (LOCAL=NO)

   6:  
  oracle 11368     1   0 10:02:10 ?           0:00 oraclenoap (LOCAL=NO)

   7:  
  oracle 11366     1   0 10:02:03 ?           0:00 oraclenoap (LOCAL=NO)

   8:  
  oracle 12453     1   0 11:09:52 ?           0:07 ora_j003_noap

   9:  
  oracle 12002     1   0 10:42:48 ?           0:00 oraclenoap (LOCAL=NO)

  10:  
  oracle 11314     1   0 09:58:22 ?           0:00 oraclenoap (LOCAL=NO)

  11:  
  oracle 11270     1   0 09:55:48 ?           0:00 oraclenoap (LOCAL=NO)

  12:  
  oracle 11964     1   0 10:41:00 ?           0:00 oraclenoap (LOCAL=NO)

  13:  
 

进程号为11998为oracle的一个dedicated server进程，使用prstat –p 11998查看结果如下

 

   1:  
PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP

   2:  
 11998 oracle     16G   16G sleep   59    0   0:00:30 0.0% oracle/1

验证了我的想法。

 

因此我给客户一个解释为：凡是有oracle连接的用户都会显示占有这么多的内存，实际上并不是进程占用了这么多的内存，而只是进程可以访问到内存的大小，因为SGA的区域的内存在操作系统级别上为共享内存，通过ipcm –m可以查看：

 

   1:  
IPC status from <running system> as of 2010年04月14日 星期三 11时12分49秒 CST

   2:  
T         ID      KEY        MODE        OWNER    GROUP      SEGSZ

   3:  
Shared Memory:

   4:  
m          1   0xdb04ea04 --rw-r-----   oracle oinstall 17179910144

所有的oracle的dedicated server进程全都有访问该内存区域的权限，所以才会出现现在这种状况。

此时客户对我的解释又提出了新的意见：用户自己的uway用户也有数据库连接可是只占有3804M内存，所以客户认为我的解释是不合理的。

为了说服用户：我又做了一次测试，测试如下：

使用uway用户登录到操作系统中，利用sqlplus连接上oracle，之后使用prstat –a命令查看，发现如下结果：

 

发现uway用户显示占用了20G（原先的4G+16G）的内存，看到这个结果后，无语了。