Slow Save to Central Time

[Ascott-mpa]

Has anyone come across any issues when working on a large project 170mb or larger and about 7-12 people working on it, with the save to central times taking 5+ mins and getting errors saying that revit has run out of memory. The computers are properly set up so that they should not run into this issue and the network speed is fast enough to handle this. Is there any work around? maybe splitting up the model even more.

Any ideas would be helpful.

[kpaxton]

Ascott,
Afternoon! Actually, this is a common issue that can crop up in larger models, especially with larger crews. We typically 'think' that everything is setup properly, but sometimes we miss the little things. Sometimes it's also hardware issues, sometimes it's the users doing certain things. As you describe the issue, I tend to want to ask a few questions....

1. Are users, when attempting to save, doing this close together time-wise? Increased times can be seen when multiple users are trying to save concurrently. Describe a schedule to your staff to avoid the overlap.
2. Are users trying to Save-to-Central with large intervals between? We've found that with large amounts of data created, Revit has to load, compare, check, verify, etc. which can increase save times.
3. Because of the nature of the 'under-the-hood' functions in Revit, you'll want to look at using a 4-step process when saving with large files & large teams.
   1. Save to local (prior to saving to Central) - This saves your work so there are no losses if there is a network issue/crash.
   2. Reload Latest (File > Reload latest or RL=keyboard shortcut). - This pulls any New information from the Central File first and reconciles that with your model.
      1. example: if 8 people are working for 1-hour and create a lot of content, that's 8-hours of content. If all try to STC, then 8 hours have to be reconciled and coordinated in a short time- then pushed back to the central.
   3. Save to Local (see #1 above) - you're file in memory is now more current than your Local File.
   4. After RL - then Save-to-Central. Using the File pulldown, so that users can add comments AND click the Save-to-Local checkbox at the bottom.

Other items to look at:

1. Are users using the same Build # of Revit (absolutely critical with worksets)
2. how much Ram & what kind of OS are you using? (I know, you said 'everything is fine' - but you never specified... which is why i'm so vague here....)
3. Is there a "Limpet" on the system? This is a term I use to describe a user on the team (typically a Project manager), who has an older computer or laptop that is 'limited' with 1 mb ram, but only wants to get into a file to print, look etc. We've found that this type of unit can affect the performance of STC's without even being in the model to touch it. Revit still sees this user and wants to check and reconcile, etc.

I hope this helps, but without looking directly at the file... well, you get the picture.

Regards,
kyle

[bwbarch]

We have recently dealt with a slowdown in STC times as well. As a "preventative maintenance" measure, you may also want to consider purging the project file using the Purge command. This clears out any unused families, and unused types within otherwise used families. However, I would recommend you do this on a planned interval, and review your loaded families first to make sure you aren't going to purge something you still want to use. The purge command gives you the option to purge only selected items if so desired. Purging can remove a lot of "bloat" that can creep in as you add and modify families. Doing so will reduce the project file size, and reducing the file size will speed up STC times.

You may also want to consider using the "audit" option by opening the project file through the Open File dialog (not the "Recent Files" window). Again, I would do this only on a planned interval.

To quote the Revit Help File for the "Audit" option:

If desired, select Audit to scan all elements in the project.The Audit option can detect and fix corrupt elements in the project. However, it can greatly increase the time required to open files. Use this option only for periodic maintenance of large workset-enabled files or when you are preparing to upgrade.

We have come to realize that Periodic Maintenance is really not an option, but rather is a necessity, when working on large files with several team members involved.

[dbaldacchino]

Make sure that "Limpets" (as Kyle puts it!), always open a detached copy of the project if all they want to do is poke around and print. One huge thing is also to close ALL your views before STC'ing and leave only a simple drafting view open. I've solved STC issues by doing this on several occasions. We used to get errors, crashes, out of memory errors during STC. Then we started closing everything and leaving an empty drafting view as the only open view when (read this tip somnwhere on the AUGI forums or on a blog out there) and it really helps.

[Chad Smith]

In regards to changing to a simple drafting view when you STC, this view is also handy for conveying some project information to uses, and we even have one guy here who puts a daily funny on it, like a comic strip or joke .

[dbaldacchino]

Good way to motivate people I guess

Here's how some other firms are using this "splash screen" if you will:

http://irevit.blogspot.com/2008/05/t...come-page.html

[Chad Smith]

Very good link. Thanks for that.

[cl.134735]

I know I'm a bit late here but maybe it'll help somebody else out. We found that the culprit on our system was the RAID server. Before we had the RAID we would be able to save a 25 mb test file in less than 10 seconds. We switched to a NAS because of lack of space and that sent the save times up to 50 - 75 secs. Couldn't figure it out. We finally got fed up and updated our server to internal RAID and went to gigabit lan and high memory, same OS; we thought it would solve the problem. Still long save times. Our peer-peer saves were almost as low as local, so the lan was fine. Had a hunch and installed the RAID software and turned on drive caching. We're back to low save times (5 secs). I'm assuming it is because the RAID gathers the information in a temp file and sends an OK that it got it back to the workstation instead of saving to multiple drives and then sending the OK back to workstation. The only problem might be if you have a power outage right when you're saving but that should be helped with a UPS. I hope this helps - it was a real pain for us for a year or more.