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）的内存，看到这个结果后，无语了。
文章来源：http://blog.csdn.net/liufeng1980423/article/details/6070502