![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Cannot restore archive - run out of memory Topic Summary: Created On: 10-Mar-2006 14:48 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: This problem went away when I migrated the database from DOORS 7.1 to 8.2. An archive with baselines now restores in about an hour. Thanks for all the suggestions. Ken. | |
![]() |
|
When I attempt to restore a full archive (with baselines), this takes an extremely long time (more than 8 hours) and the process eventually runs out of memory and crashes. Telelogic are not able to reproduce this problem using my archive file, the same DOORS version (7.1), O/S (Win 2000 with SP4) and memory (1GB). Archive file size is 500MB. I am able to successfully restore an archive with no baselines (50MB file). Apart fom increasing the memory on the server, is there anything else that might be causing the problem. How much memory do others have on their servers? Thanks, Ken.
|
|
![]() |
|
![]() |
|
Ken,be sure to restore the archive using a locally mapped drive ( Ok, I mean from the C:\ drive ) restoring from another mapped dive has caused me a few crashes in the past.
Rgds
Andrew.
------------------------- Andrew Tagg Thales Air Systems, Melbourne Australia. andrew.tagg@thalesatm.com |
|
![]() |
|
![]() |
|
You are running DOORS from your client machine restoring some Project Archive? Your speed will certainly be a function of the network pipe between your client and the server; but I'm too ignorant to suppose how a "bad" network will cause you extra memory allocation problems on your client.
Anyway, you could run Task Manager look at the Processes tab and slect the Mem Usage column; this will tell you which processes are taking up your memory. Perhaps its not actually the "doors.exe" process. Also anyway, try restoring big projects from the DOORS server machine itself; that will certainly be faster. - Louie Brain Storm: Run this code from your client: print (getenv("defopenlinkmode")) "\n". If its blank or default or "SHARED" that MAY cause you excessive memory when opening modules. I'd change that to "READ_ONLY" in your registy, perhaps at location: [HKEY_Local_Machine\Software\Telelogic\DOORS\7.1\Config] value "defopenlinkmode". While there, chage "defopenmode" to "READ_ONLY" as well. |
|
![]() |
|
![]() |
|
Sorry, I only just noticed you had replied. However, I am already restoring from a local drive, not a mapped network drive, so this is not the problem. Thanks for the suggestion, Ken.
|
|
![]() |
|
![]() |
|
Sorry, I only just noticed you had replied.
I am running the restore from a client on the same machine as the server, so the network is not the problem. I checked the task manager, and it is indeed doors.exe that is using up all the memory. I checked on the two registry keys and they were not defined (would default). I set them both to READ_ONLY and re-ran the restore, but it still ran out of memory as before. Thanks for the suggestions, Ken. |
|
![]() |
|
![]() |
|
I faced the similar situation last year... then I increased the virtual memory to maximum size with 1GB RAM where the DOORS client was running... but didnt work as well!
As a work around, I opened the archive file but didnt restore the whole bunch together rather I selected some projects and restored until I got all the projects restored in my DOORS DB. Rony ============== Iftakher Uddin (Rony) HOOD Group |
|
![]() |
|
![]() |
|
Iftakher,
I have increased my RAM to 2GB and the VM is now a massive 5.5GB - so I don't think that is the problem. Telelogic support were able to restore my database on their server with only 1GB of RAM so the problem lies elsewhere. There must be something wrong with the configuration of my server or there is some other process running that is eating it up. DOES ANYONE HAVE ANY OTHER IDEAS??? I may try your suggestion of restoring only parts of the database; however, mine is all one project, so I may need to partition the restore carefully if I do it selectively. Thanks, Ken. |
|
![]() |
|
![]() |
|
The problem is probably on the network between your client and the server. Lots of data xfers back and forth and it wouldn't surprise me that an inferior network will trigger DOORS problems, usually timeouts.
You could test this out by installing a DOORS database on your client, and installing the project in it. Should work. Try to restore the project while using DOORS on the server. - Louie |
|
![]() |
|
![]() |
|
Thanks for the suggestion, but the client and server are already on the same machine.
|
|
![]() |
|
![]() |
|
Ken,
Try an entirely new environnment. "new" m/c, "new" server s/w, "new" client s/w. All Patches.... It is not a solution but it may take you noe step closer if it works... John ------------------------- John Arges P. Eng. |
|
![]() |
|
![]() |
|
This problem went away when I migrated the database from DOORS 7.1 to 8.2. An archive with baselines now restores in about an hour. Thanks for all the suggestions.
Ken. Edited: 9-Jan-2008 at 16:27 by Ken McNair |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.