Revit Memory error (TMP) RST2008

[Jshaver]

There is a memory error that is haulting the save to central (over a network) on one of our current projects. The central file is close to 60-70MB. After working in the local file for an hour or so and attempting to save to central will result in an error stating that there is not enough memory on the C: drive to complete the save. According to the computer settings there is plenty of room. Upon digging further we discovered there is a revittemp file located in the C:\Documents and Settings\user\Local Settins\Temp folder that is growing to enormous sizes. With the same 60-70MB local file this templ file will swell up to over a gig in size.
The temp files name is revittemp_6MAA19IO6194JQMFQPADOK9HGI79 (or similar)

Has anyone else experienced this error, or can you explain why in the world Revit needs such a huge temp file for such a small model?

This error is prohibbitting saving to central and work is being lost everytime it arrises. I have tried purging the files in this temp folder, removing all journal files, Auditing/purging the central, and recreating the local file.

[Tom Weir]

Hi,
Egads, we seem to be experiencing the same problem on one project today as you describe. We ae going to try purging the temp folder. No answers yet.

Tom Weir
Los Angeles

[Jshaver]

Following up on this issue:
We are only experiencing this when there is a large amount of worksharing going on. (Around 5-7 people) If there are only a couple users accessing the model this issue is not as drastic.
We may have to result splitting the model up even further into seperate models for each floor .

[adb]

I just spent 15 minutes serching for a thread that I just read yesterday on this issue. I'm sorry I can't locate it but here is what I can remember....

The revit temp file looks for the largest contiguous space on the hard drive. If the drive is 120G but the largest contiguous space is 1G then revit will only see the 1G space to use it for the temp files. If the temp file needs to be larger than the 1G available then you get the error message. The suggestion for this one is to defrag.

Also, one of the revit developers commented in the thread that I could not locate that he was researching how Revit was reporting memory in its temp files. I think they were looking into errors as to how memory was being reported.

The issue that I have personally run into when one of my useres can't STC is when my users have not closed out of revit and re-opened it to release memory. We have a very large project that after purging and compacting is just under 200M. If our users keep Revit open all day without ever closing it they will get an error message that revit is out of memory at about the 6th or 7th hour and they will not be able to STC.

The solution is to save local and close revit. Save without relenquishing if need be. Note that I said close revit (not simply getting out of the project!) From the same computer and user, reopen the local file, "relenquish all mine", "save local", then "save to central".

The issue is how Revit handles memory. It handles memory separately than the windows settings that we are all use to seeing (virtual memory settings etc.) Revit does not release all of its memory that it uses and therefore will eventually run out after hours of use on a large file. The only way to release this memory is to close revit and start fresh.

Take a look at your journal files sometime and search for "memory". You will see as the log file gets older and older that the memory usage keeps increasing. In my case I can go back into the log file and see the exact time that revit started having issues with memory and started giving the user warning messages about running out of memory. The user kept right on working and ignoring the warnings. After 7 hours of working in the file they tried to STC and got the error message you described.

Again, sorry I could not locate the thread. If someone else can find the thread I am referring to please add it to this one.

[Jshaver]

adb,
Thanks for the great reply.
Typically I delete all my journal files and local files at the beginning of everyday. If I wait a week or more they grow to 180mb+.

I could not locate the specific thread I thought you were referring to but I had previously noted the same issue with Revit not giving back the memory it has used until after the program closes. (Back with RS2 IIRC)

A large portion of the "memory" threads turned up in the search mentioned using the 3gig switch to resolve their memory issues but unfortunately that is not an option for us as it reaked havoc on our systems some time ago.

A few other threads also recommended defragging on a regular basis. Is it possible to defrag constantly while running Revit? or will performance be hindered by this process.

[adb]

I have not tested what you suggest but it seems to me that there would be a HUGE hit on performance if you were trying to do both at the same time....if you even can.

[darickb]

Autodesk has this in the Revit 2010 Model Performance Technical Note

http://images.autodesk.com/adsk/file..._tech_note.pdf

chapter 1, Page 6, Memory, Management


Management
Revit-based applications maintain model data in memory and hard disk caches to increase performance
against repeated data access; however, as a consequence of extended model manipulation, Revit platform
performance may benefit from an application restart once or twice a day, and especially before triggering
the following memory-intensive tasks:
■ Printing
■ Rendering
■ Exporting
■ Upgrading models to the current Revit-based application version
In addition, before performing any of the operations listed above, performance can be increased by reducing
memory use through the following tactics:
■ Close other applications
■ Turn off shadows for all printed views if not absolutely necessary.
■ Detach local copies from central before printing and exporting to limit network resources and reduce
project chatter between local and central files. Use this tactic with caution because changes subsequent
to detachment cannot be saved to the central file.