环境:
软件信息:
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)的内存,看到这个结果后,无语了。