Conference decwet::nt-developers

3195.0. "a NT memory management question" by HYDRA::CHIN () Tue Feb 25 1997 12:03

    Hi,

    An Partner has sent me a lengthy description with questions on
    NT memory management areas.  For those who have experiences in
    this area, would you care to provide some insight?

    Thanks in advance,
    Miller


Overview by ECRM:
We are evaluating a memory intensive third party product on a number of =
different
intel based platforms running nt 4.0 server and we are experiencing =
problems of
memory availability. We believe the problem is related to the size of the =
non-paged
memory pool. What we are seeking is an opinion from you regarding the =
safety
and advisability of altering its size from the default value of 0.

Problem
The immediate cause of the problem is a buffered devIOCtl call to =
transfer data
to a scsi device made to our device class driver. The buffer size is less
than or equal to 1MB. The class driver simply sets up an irp and does a =
call
to the next lower driver using IoCallDriver. As I understand it the =
applications
buffered call causes the OS to copy the data into non-paged system memory =
and a
reference is created and placed in the AssociatedIrp.SystemBuffer field. =
In any
case this information is packaged up in the irp and sent downward and =
outward.

What we have seen is the following:

1. We experience no problems whatsoever on inhouse pentium 90/133's
and buffer sizes up to the maximum 1MB either immediately or over
many hours of heavy use. Everything works perfectly and the data
appears in our scsi device correctly.

2. On two inhouse pentium pros we find that under the default memory
condition we can only submit a job to our device with buffer sizes
far less than 1 MB (sometimes only as low as 64K). Normally this would
not be a problem. We would simply look for the system 'out of resources'
error at the application level and inform the user to reduce his buffer =
size.
The problem arises when we decrease the buffer size and are successful at
outputing a job. If we continue to submit jobs at some point (sooner or
later) we experience the low resources error again. At this point our
application disables output but continues to perform other background
activity not directly related to our scsi device but involving heavy
scsi disk i/o. After the failure one of three things may occur.

a. we reenable output to our device and the queued jobs output normally
and everything looks fine
b. we must exit then reenter the application and any leftover queued up
output proceeds normally and everything looks fine
c. we need to completely reboot the pc then things appear normal

What we have found is that by altering the registry entry
'HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Session Manager/
Memory Management/NonPagedPoolSize' from the default '0' to an arbitrary
size of 8MB the problem does not appear at least over the duration of our =
tests.
By making it large enough (16MB) we can use buffer sizes up to the =
maximum
1MB with no appearent problem.

Initially it almost appears that there is some process taking some
inordinate amount of time to release memory resources and/or is simply
irretrievably leaking memory resources. However if this is true then =
failure
should occur on non-pentium pros which it does not.

We are hesitant to recommend setting this registry value to anything but =
the
default '0'. Do you have any opinion or recommendation in this regard.

I have attempted to present the situation as simply as possible. If =
additional
detail is required I will be more than happy to supply it. I believe all =
I
really need is some information as to when and why I would need to juggle =
the
'Memory Management' parameters and to what value I should adjust them to. =


thankyou for your time.