SNA Server Processes Show Huge Virtual Byte Size in PerfMon

ID: Q142497


The information in this article applies to:
  • Microsoft SNA Server, versions 2.0, 2.1, 2.11, 3.0
    on the following platforms: NT


SUMMARY

When viewing the virtual byte size of any SNA Server service or Win32 application which uses the SNA Server API's, Windows NT Performance Monitor shows the Win32 process' virtual byte size to be larger than 154MB.

SNA Server reserves a 154MB contiguous region in the process' virtual address space, though only 64KB of physical memory is initially allocated or committed. Additional physical memory is allocated only when needed. Also, this memory is shared between all SNA Server processes running on the computer, and only one copy is allocated even if there are several SNA applications running.

Since this large virtual memory area is not actually allocated out of available physical memory, other processes running on the computer are not be affected, nor does it affect the Windows NT page file. The committed memory can be found by viewing the "working set" size of each process.


MORE INFORMATION

SNA Server processes running locally on a Windows NT computer communicate with each other using a shared memory region. Each SNA Server process (that is, SnaBase, SNA Server, link services, and applications which use the SNA API's) communicate with other SNA Server processes on the computer by writing to buffers in this memory region which is then available for other SNA Server processes to access.

When SnaBase is started, it reserves this shared memory region as a Windows NT virtual memory mapped file. The size of this file is determined by the size of all possible SNA Server internal communication buffers which can potentially be allocated (on SNA Server 2.11, this is 154,300,416 bytes). However, out of this large potential size, the initial allocation size is less than 64KB (16KB for process headers, 32KB for elements and 8KB for headers).

SNA Server logs event 684 and 685 to indicate changes in the buffer pool memory allocation. Event 684 is logged when over half of the maximum number of buffer pools has been allocated. Event 685 is logged if Windows NT has returned an error to our VirtualAlloc call, or if the maximum number of buffer pool extensions have been allocated. Full internal tracing on the component logging these events indicates the cause of the 685 error. The text for these events are included below:


   Event 684
   A buffer pool audit has been triggered by a pool extension.

   EXPLANATION

   This audit contains information about the size of the buffer pool,
   how many headers and elements each process is using, etc.

                   Pool      Free     Alloced      Max

   Trusted Hdrs
   Trusted Elts
   Non-Trusted Hdrs
   Non-Trusted Elts

   Comname    Pid    Trusted   Hdrs   Elts

   SnaBase
   SnaServr
   SnaDlc1
   ...


   ACTION

   None, unless there is some other problem. In that case, report
   this log along with any others.



   Event 685

   An attempt was made to extend a buffer pool, but the related pool
   had reached its maximum size. The affected component is terminating,
   and an audit of the buffer pools just before termination is attached

   EXPLANATION
   This error is almost always due to either an SNA component (including
   possibly an emulator) losing buffers or a slow emulator (or RUI
   application) using a session without pacing.

   ACTION
   Contact your support personnel.

   Excessive logging of this event may indicate that an SNA Server process
   running on the machine is not releasing buffers properly, which could
   indicate a potential memory leak. 

Additional query words: prodsna

Keywords : kbnetwork ntnetserv
Version : WINDOWS:2.0,2.1,2.11,3.0
Platform : WINDOWS
Issue type :


Last Reviewed: September 27, 1999
© 2000 Microsoft Corporation. All rights reserved. Terms of Use.