Nattch value > number of processes?

[Roger Baptiste]

hi,

Can the NATTCH value in ipcs output be more than the number of actual processes running in the system?? It doesn't sound logical! But, here is an eg:

#grep oracle ipcs-mopb.out
m 11282 0x84407e34 --rw-r----- oracle dba 2334 997928960 14133 20132
m 5142 0x00000000 --rw-r----- oracle dba 1556 1328545792 14133 20132

The above output shows there are atleast 2334 processes using oracle shared memory.
But, the total number of processes running on the system is:
#ps -ef |wc -l
1358

How can there be 2334 processes using oracle shared memory, when the total number of processes in the system itself is 1358?? Does NATTACH count "phantom" processes at the oracle level in its calculation?? Please note, i am not adding up all the NAttach values, but taking value from just one sharedmemory segment. So, the question of duplicate processes doesn't arise.

thanks
-raj

[John Poff]

Hi Raj,

That is weird! Have you taken a look at some of the Oracle processes in Glance? Do the Process Memory Regions show that they have the shared memory segment attached more than once? I'm not even sure if they could do that.

I wondered if 'lsof' might help, but it doesn't list shared memory segments unless they are associated with an open file.

JP

[Stefan Farrelly]

I would say its a problem with the application which attaches to the segment, its not detatching correctly, causing your NATTCH total to continually grow to the point where it now exceeds the number of processes possible running. Ive just checked some of our oracle servers and none have NATTCH values even close to the number of running processes let alone exceed it.

[Roger Baptiste]

John - I checked in glance and it shows only one attachement to the shmem per process.

Stefan:
<>

Yes, it definitely looks too large a difference here. But,on few other systems too, there is a smaller difference between the number of total *oracle* related processes and the NATTCH value. The NATTCH value is more than the total number of oracle processes.
eg:ps -ef |grep oracle |wc -l
125
ipcs -mobp |grep oracle
m 50184 0x94d3c734 --rw-r----- oracle dba 219 1232756736 14621 25820

219>125.

Any further thoughts?

thanks
raj

[Roger Baptiste]

hi,

Revisiting this issue. On further investigation, i find this to be a problem on all oracledb systems.

Specifically, the NATTCH value returned by ipcs command corresponding to oracle is *greater* than the actual number of *oracle processes* using the shared memory segment.

To confirm this, I used the "shminfo" tool, a useful utility which lists the processes using a shared memory segment. (it can be got from ftp://contrib:9unsupp8@hprc.external.hp.com/sysadmin ). I ran shminfo to see how many processes are using the sharememid and it definitely returns a lesser number than the one shown by ipcs output.

any thoughts?
-raj

[John Payne_2]

Raj,

Is that url for shminfo good? I have a problem today that this would be useful for, but I kepp getting a timeout error...

Thanks

John

[Anu Mathew]

Hi Rajman,

Based on my experience with a wrong TBL_SHMEM_AVAIL from Glance long back, I would suspect the ipcs binary installed, besides installed patches.

What is the OS?

The following is the o/p of what ipcs from my systems.

11.00 (32/64bit)
----------------
/usr/bin [15] > what ipcs
ipcs:
$Revision: 82.3.1.1 $
PATCH_11_00: ipcs.o 99/04/23

10.20
-----
# what ipcs
ipcs:
$Revision: 78.2 $

At my site, ipcs behaves well.

Hope this helps,

~AM

[Roger Baptiste]

John,

Again, This is the site:
ftp://contrib:9unsupp8@hprc.external.hp.com/sysadmin/programs/shminfo

Refer to Bill's response in this thread:


http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x1259039599eed5118ff40090279cd0f9,00.html

Am curious to see whether the output from shminfo -s |grep proc |wc -l

corresponds to ipcs -am |grep

-raj

[Roger Baptiste]

Anu,

You bring up a good point. But, i find this disparity in all systems i have checked, irrespective of their ipcs binary level.
Some of them have the ipcs binary detail as:
***
#what /usr/bin/ipcs
/usr/bin/ipcs:
$Revision: 82.3 $

#ll /usr/bin/ipcs
-r-xr-sr-x 1 bin sys 24576 Nov 7 1997 /usr/bin/ipcs
***
and few others have the exact version you have:
**
#what /usr/bin/ipcs
/usr/bin/ipcs:
$Revision: 82.3.1.1 $
PATCH_11_00: ipcs.o 99/04/23
ll /usr/bin/ipcs
-r-xr-sr-x 1 bin sys 28672 Apr 23 1999 /usr/bin/ipcs
**

But, the "problem" is there on all systems.

>>>At my site, ipcs behaves well
Can you elaborate on what you mean behaving well? The way to check this disparity is as follows:
ipcs -am |grep oracle
Note the NATTCH(9th)column values. Corresponding to the shmid (2th) column, see how many processes are actually connected to it, by running shminfo command as
# shminfo -s . This will list all the processes/pids which are using the shared memory segment. Now, you would see a difference in this values. On one of my systems, the difference is almost 2000. On many others it is a measly 50. But, that is against the logic of how it should behave.
Curiously, this is only for oracle shared memory segments and not for other ids.

(Ignore my earlier example of ps -ef |wc -l.
That was an extreme case. )

thanks
raj

[Bill Hassell]

Regading the shminfo URL, if you use Internet Exploder, you will encounter very nasty bugs with ftp. Use Netscape or Opera, or fix the bug by turning off the (stupid) "Folder View" for ftp. In IE, pull down Tools, select Internet Options, then Advanced and UNCHECK the Folder views for ftp.

And youi can always use real ftp: site=hprc.external.hp.com, login=contrib, password=9unsupp8.

ipcs may have some problems...I've never had problems with the accuracy of shminfo and it shows 10x more information than ipcs for shared memory mapping.