NTVDM Memory Usage (AREV Specific) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]


==== NTVDM Memory Usage (AREV Specific) ====
=== At 11 MAR 2003 06:35:55PM Victor Engel wrote: ===
 
{{tag>"AREV Specific"}}
 
<QUOTE>
We have a process that is converting legacy database records via PDISK for eventual loading into the new application. In the process, about 10,000 documents (generated using pdisk and print routines) are processed at a time, each gzipped, the lot (10,000 GZ files) zipped into a single archive using Winrar. The archive is then ftp'd to the destination computer.



At first I was worried about the potential problem previously reported here were file handles become scarce when using pdisk repeatedly. This didn't evidently pose a problem, since executing several tens of thousands of pdisk commands did not seem to have any stability problems.



However, now I'm wondering about this, because I just noticed that NTVDM memory used steadily rises at the rate of about 1 Mb per hour. I have seen the number grow to about 100 MB. Since Arev does not itself address that much memory, I figure the memory leak is elsewhere, but I don't know where.



I'm thinking of exploring what is happening, but I'd like some pointers on how to tackle this. Is it possible to dump the memory somewhere? Do you think it is pdisk doing this (we're exploring using capture instead)?



Another possibility is that either gzip, winrar, ftp, or some batch file might be causing the problem. I consider this unlikely, though, since these are all performed by spawning a new DOS session.
</QUOTE>
----

=== At 11 MAR 2003 08:05PM Warren wrote:  ===

<QUOTE>There's a serious memory leak in NTVDM itself.



Try opening and closing the command prompt (command.com) then looking at the task manager. NTVDM stays loaded and keeps eating up memory each time you start a session. You can kill it manually in task manager to release the memory.

</QUOTE>

----

=== At 12 MAR 2003 10:44AM Hippo wrote:  ===

<QUOTE>What is NTVDM?

</QUOTE>

----

=== At 12 MAR 2003 10:46AM Matt Sorrell wrote:  ===

<QUOTE>NTVDM is the NT Virtual DOS Machine.  Essentially, it is the process space in which all DOS applications run on NT/2K/XP machines.



msorrel@greyhound.com

[url=http://www.greyhound.com]Greyhound Lines, Inc.[/url]

</QUOTE>

----

=== At 12 MAR 2003 11:42AM Hippo wrote:  ===

<QUOTE>Thanks 

</QUOTE>

----

=== At 12 MAR 2003 11:57AM Victor Engel wrote:  ===

<QUOTE>Yes. Searching the newsgroups, it seems to be memory allocated for the initial environment which is never reclaimed. I've opted to install a memory manager that periodically reclaims this RAM. Normally, terminating the master 16-bit application is required, but such a RAM manager seems to do the trick just as effectively.

</QUOTE>

----

=== At 13 MAR 2003 06:35PM Warren wrote:  ===

<QUOTE>Which memory manager is that?

</QUOTE>

----

=== At 14 MAR 2003 12:36PM Victor Engel wrote:  ===

<QUOTE>I'm using RAM Idle Standard from http://www.tweaknow.com/

</QUOTE>

----

=== At 01 MAY 2003 10:56AM Victor Engel wrote:  ===

<QUOTE>I've decided this program is not useful for my purposes. The way it functions is to temporarily request large blocks of RAM from Windows. Windows responds by moving other application RAM to the swap file, but it's not actually reclaimed as I thought it was. After Windows moves application data from RAM to swap file, the large block requested by RAM Idle is released, and the utility reverts back to idle monitoring mode.



Running our conversion PCs for several weeks straight confirms this. After several weeks, Windows reports that it has to increase virtual memory. Had no disk space been available to do this, we no doubt would have received a fatal memory-related error of some sort.

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=0FCA30F2698920BD85256CE6007C234E|View this thread on the  forum...]]