某ArcSDE问题排查过程
分享
环境：
OS:AIX5.3
ArcSDE9.2+SP4
DBMS:Oracle10.2.0.4
问题描述：
AIX中/tmp文件夹下产生了160多万个随意命名的临时文件，文件大小都为0,系统监测软件发现了问题，
对系统性能影响极大。请相关的技术人员现场分析得出来的结论是：
结果是sde连接oracle的进程产生的。至于是sde自身的gsrvr进程产生的，还是gsrvr连接Oracle，oracle产生的server进程，谁都不清楚。
得到这个消息我很吃惊，本来以为是sde的bug，但是也不太可能，我们的SDE部署在AIX系统上不是一台两台了，从来没有碰到过这种问题，故跑到现场看了看。
现场：
今天比较幸运，系统管理员在，虽然不让亲自操作机器（所以也没有任何的截图），但是人家的水平的确是非常高，比咱亲自操作的水平高。
管理员使用Engineer当时操作的命令：fuser –c filename进行操作，filename为其中的一个临时文件，的确是查出来了很多的process id， 然后将所有的process id的进程名打印出来，发现大部分的进程都是sde连接oracle后，oracle产生的server进程，当然还有一些别的进程，比如weblogic什么的。
接着在/tmp目录中创建了一个新的文件，这个文件没有任何人使用，但是使用fuser -c命令查看和刚才的临时文件查找出来的结果是一模一样的，这就不正常了。
结论：
实际上问题是出在Engineer身上，fuser 命令使用的是正确的，但是参数选择错了，不应该加-c，-c的意思是：
-c Same as -m option, used for POSIX compatibility.
-m name specifies a file on a mounted file system or a block device that is mounted. All processes accessing files onthat file system are listed. If a directory file is specified, it is automatically changed to name/. to use any file system that might be mounted on that directory.
正确的命令应该使用-u选项或者不加参数，以下是我在linux上做的测试结果：
1:
192.168.100.228 [root tmp]$ fuser -c /tmp/s.esri_sde.iomgr
2:
/tmp/s.esri_sde.iomgr: 1rce 2rc 3rc 4rc 5rc
3:
6rc 7rc 8rc 9rc 10rc 47rc 52rc 53rc
4:
54rc 215rc 216rc 219rc 221rc 295rc 296rc
5:
297rc 298rc 299rc 300rc 446rc 456rc 490rc
6:
491rc 492rc 496rc 497rc 498rc 499rc 503rc
7:
516rc 531rc 557rc 590rce 1539rc 1831rc 1868r
8:
1869rc 2246rc 2247rc 2248rc 2354rc 2898rce
9:
2900rce 2931rce 2935rce 2976rc 2977rc 3016rce
10:
3047rc 3048rc 3056rce 3090rce 3115rce 3140rce
11:
3146rce 3170rc 3218rce 3233rce 3247rce 3248rce
12:
3256rce 3266rce 3274rce 3277rce 3280rce 3284rce
13:
3306rce 3332rce 3354rce 3359rce 3377rce 3391rce
14:
3410rce 3543rce 3545rce 3547rce 3549rce 3551rce
15:
3553rce 3555rce 3557rce 3559rce 3561rce 3563rce
16:
3565rce 3567rce 3583rce 3602rce 3606rce 3609rce
17:
3615rce 3630rce 3644rce 3683rce 3710rce 3741rce
18:
3742rce 3773rce 3777rce 3778rce 3789rce 3791rce
19:
4017rce 4309rce 4311rce 18745rce 18747rce 27644rce
20:
27646rce 27649rce
fuser -u
1:
192.168.100.228 [root tmp]$ fuser -u /tmp/s.esri_sde.iomgr
2:
/tmp/s.esri_sde.iomgr: 18745(sde)
3:
192.168.100.228 [root tmp]$ ps -ef|grep 18745|grep -v grep
4:
sde 18745 1 0 Dec14 ? 00:00:00 /opt/sde/sdeexe93/bin/giomgr /opt/sde/sdeexe93 esri_sde
5:
192.168.100.228 [root tmp]$
文章来源：http://blog.csdn.net/liufeng1980423/article/details/6079147
OS:AIX5.3
ArcSDE9.2+SP4
DBMS:Oracle10.2.0.4
问题描述：
AIX中/tmp文件夹下产生了160多万个随意命名的临时文件，文件大小都为0,系统监测软件发现了问题，
对系统性能影响极大。请相关的技术人员现场分析得出来的结论是：
结果是sde连接oracle的进程产生的。至于是sde自身的gsrvr进程产生的，还是gsrvr连接Oracle，oracle产生的server进程，谁都不清楚。
得到这个消息我很吃惊，本来以为是sde的bug，但是也不太可能，我们的SDE部署在AIX系统上不是一台两台了，从来没有碰到过这种问题，故跑到现场看了看。
现场：
今天比较幸运，系统管理员在，虽然不让亲自操作机器（所以也没有任何的截图），但是人家的水平的确是非常高，比咱亲自操作的水平高。
管理员使用Engineer当时操作的命令：fuser –c filename进行操作，filename为其中的一个临时文件，的确是查出来了很多的process id， 然后将所有的process id的进程名打印出来，发现大部分的进程都是sde连接oracle后，oracle产生的server进程，当然还有一些别的进程，比如weblogic什么的。
接着在/tmp目录中创建了一个新的文件，这个文件没有任何人使用，但是使用fuser -c命令查看和刚才的临时文件查找出来的结果是一模一样的，这就不正常了。
结论：
实际上问题是出在Engineer身上，fuser 命令使用的是正确的，但是参数选择错了，不应该加-c，-c的意思是：
-c Same as -m option, used for POSIX compatibility.
-m name specifies a file on a mounted file system or a block device that is mounted. All processes accessing files onthat file system are listed. If a directory file is specified, it is automatically changed to name/. to use any file system that might be mounted on that directory.
正确的命令应该使用-u选项或者不加参数，以下是我在linux上做的测试结果：
1:
192.168.100.228 [root tmp]$ fuser -c /tmp/s.esri_sde.iomgr
2:
/tmp/s.esri_sde.iomgr: 1rce 2rc 3rc 4rc 5rc
3:
6rc 7rc 8rc 9rc 10rc 47rc 52rc 53rc
4:
54rc 215rc 216rc 219rc 221rc 295rc 296rc
5:
297rc 298rc 299rc 300rc 446rc 456rc 490rc
6:
491rc 492rc 496rc 497rc 498rc 499rc 503rc
7:
516rc 531rc 557rc 590rce 1539rc 1831rc 1868r
8:
1869rc 2246rc 2247rc 2248rc 2354rc 2898rce
9:
2900rce 2931rce 2935rce 2976rc 2977rc 3016rce
10:
3047rc 3048rc 3056rce 3090rce 3115rce 3140rce
11:
3146rce 3170rc 3218rce 3233rce 3247rce 3248rce
12:
3256rce 3266rce 3274rce 3277rce 3280rce 3284rce
13:
3306rce 3332rce 3354rce 3359rce 3377rce 3391rce
14:
3410rce 3543rce 3545rce 3547rce 3549rce 3551rce
15:
3553rce 3555rce 3557rce 3559rce 3561rce 3563rce
16:
3565rce 3567rce 3583rce 3602rce 3606rce 3609rce
17:
3615rce 3630rce 3644rce 3683rce 3710rce 3741rce
18:
3742rce 3773rce 3777rce 3778rce 3789rce 3791rce
19:
4017rce 4309rce 4311rce 18745rce 18747rce 27644rce
20:
27646rce 27649rce
fuser -u
1:
192.168.100.228 [root tmp]$ fuser -u /tmp/s.esri_sde.iomgr
2:
/tmp/s.esri_sde.iomgr: 18745(sde)
3:
192.168.100.228 [root tmp]$ ps -ef|grep 18745|grep -v grep
4:
sde 18745 1 0 Dec14 ? 00:00:00 /opt/sde/sdeexe93/bin/giomgr /opt/sde/sdeexe93 esri_sde
5:
192.168.100.228 [root tmp]$
文章来源：http://blog.csdn.net/liufeng1980423/article/details/6079147
0 个评论
相关问题
