SNA LUXLNS CREATES LOTS OF KPROCS
ITEM: RTA000038990
AIX 3.2.4, RS6k Model 970B. 25-30 users logged onto the system.
Normal process listings show approx. 705 total processes with
397 of them being kprocs. Is this an unusual amount of kprocs
running? Please explain to me why this many kprocs need to be
running.
---------- ---------- ---------- --------- ---------- ----------
A: This is an unusual number of kprocs.
Kprocs are kernel processes that run on the behalf of some
device driver. With some products it is normal to see a
large number of kprocs. This is known to occur with
SNA services and some databases. But for 30 users this
sounds out of line.
I would advise rebooting the machine, and occasionally checking
"ps avx". If you notice the number of kprocs ever growing there
may be a problem with one of these device drivers not terminating
their kprocs properly. If this is the case you need to report
the problem to Software Services at 1-800-237-5511.
---------- ---------- ---------- --------- ---------- ----------
The guilty culprit is luxlns. He has spawned 405 out of 417 kprocs.
Please advise on action to take to fix this.
---------- ---------- ---------- --------- ---------- ----------
A: Luxlns creates one kproc for each active CP-LU or LU-LU session.
This process is used to provide the data path for all of the
SNA layers below the application layer for an active session.
As such I can understand there being many such kprocs, but
405 still sounds out of line. I assume many are defunct.
Please contact Software Services at 1-800-237-5511 for investigation.
---------- ---------- ---------- --------- ---------- ----------
Upon further investigation I believe this is not an unordinary
number of kprocs for our system. We have 130 LU6.2 connections
that get started up. Each connection allocates multiple sessions
and the way I understand it, each session starts a kproc. Is
this a dangerous amount of kprocs? What I mean is could this
cause any type of system problem?
---------- ---------- ---------- --------- ---------- ----------
A: I had the SNA responders review your statement, and they agree.
Each connection can create several sessions; each session
will have a kproc. They also mentioned they hope this workload
is spread over multiple attachments.
From the system performance point of view, these kprocs are
just like all other normal processes, and 800 processes is not
an unusual workload for a 970B. The only performance impact that
large numbers of processes have, is the scheduler has a larger
process table to scan looking for a process to run, so more
overhead is taken in process scheduling. But with 800 - 1200
processes this is not a problem.
If you have configured more connections than you need and are
wondering about the overhead of the additional connections, and
what you could save if they were reduced:
issue the command svmon -Pau > filename
Look at the detailed memory segment report (second half of output).
Each occurance of these kproc's will list a shared library
segment, a code segment, a kernel segment, and others.
Notice that many different processes all list these same
memory segments. Discard them from analysis, they are shared,
and don't count for our purposes.
Notice each of these kprocs has a private segment, and its
memory Segid number is unique. This memory segment is not
shared. Notice the pages of memory "inuse" and "pinned".
--> This is the real, tangible overhead of the extra kproc.
The pinned memory is a particularly sensitive resource since
pinned memory cannot be paged out when inactive.
Let me anticipate the next question:
When you see a line of output like
33b9 pers /dev/hd2:20554
This is the inode number 20554 in the hd2 filesystem.
You can determine exactly what resource is referenced with
the command: ncheck -i
such as: ncheck -i 20554 /dev/hd2
Run "vmstat 1 10". If the fre column is above the lowwater mark
then you have memory you aren't even using. With 128 MB memory
your lowwater mark is 120. If the fre column is at the
lowwater mark, and pi, po, fr, and sr are mostly 0 then
you are using all your memory, but aren't overextended.
To the extent pi, po, fr, and sr are consistently non-zero,
your system could use more memory.
---------- ---------- ---------- --------- ---------- ----------
Could you please xfer the sna config. issue (having this many
connections on an attachement) to the SNA responders.
My question to them is this too many connections and/or sessions for
for one attachment to efficiently handle?
---------- ---------- ---------- --------- ---------- ----------
A: Given the total number of connections and sessions do not exceed the
limits as defined in SNA Node profile, 160 LU6.2 connections per
single attachment is acceptable and should pose no additional
performance considerations other than memory allocation as outlined
in Item# BRPKC and appropriate bandwidth consumption required
for transmission between the nodes.
Referencing Item# BRPKC, the session memory allocation is detailed
as follows:
____________________________________________________________________
The following are the sizes of space MALLOCed by SNA Services when it
is started or when a connection is started.
STARTUP ---
Size of malloc space at startup: This is required whether or not
the connections or attachments are stopped due to inactivity.
RCBSIZE (160K) * total conversations (from sna node profile) +
KCCBSIZE (188K) * total connections (from sna node profile) +
CIDSIZE (124K) * total connections (from sna node profile)
Per Half Session --
The HS space is required whenever a new Half Session is created
(result of ACTLU or BIND) and is freed when a HS is deleted
(DACTLU, UNBIND, DACTPU, or link failure)
Size of malloc space per HS =
HS IDX + HS TBL + HSCB = 536
Per Connection --
The connection space is required whenever a connection is started
either from an open command or due to receipt of ACTLU (dependent)
or BIND (independent).
Size of malloc space per connection (at start connection) =
KSCBSIZE (268K)* total sessions (from sna node profile) +
KMODESIZE (140K) * total modes (from connection profile) +
KRTPSIZE (168K)* total Remote TPN (from connection profile)
NOTE: A Dependent connection (LU1,2,3 or LU6.2 ) will have 2 HS
(sscp-lu and (lu-lu)
LU1,2,3 will have 2 modes per connection (sscp-lu and lu-lu) but no
RTPN
Parallel connection will have an additional mode, session and RTPN
for the CNOS support.
____________________________________________________________________
Our recommendation to distribute session traffic, and thus the
connections, over multiple attachments is advised when the bandwidth
of the transmission media becomes a factor in bottleneck analysis.
Commonly, this is monitored with a "sniffer" or simply by slow
user response time as a result of sessions competing for the
communication adapters bandwidth resource. By providing additional
adapters (i.e. attachments), one effectively increases the
bandwidth available for these sessions to flow and the bottleneck
is resolved.
---------- ---------- ---------- --------- ---------- ----------
This item was created from library item Q652963 8SBMW
Additional search words:
ARISC CREATES CUSTORG IX JAN94 KPROCS LOTS LUXLNS OZNEW RISC SNA
8SBMW
WWQA: ITEM: RTA000038990 ITEM: RTA000038990
Dated: 11/1996 Category: RISCSNA
This HTML file was generated 99/06/24~12:43:15
Comments or suggestions?
Contact us