Our server recently got tied up running backups, so all performance suffered for a morning, but it revealed some of Civil 3D's behavior that may otherwise go unnoticed. Here's relevant details:
Many, many common functions of even vanilla autocad were unreasonably slow. Why should there be a 20 second delay after clicking a hatch to grip edit? Why should there be a delay after editing a feature line (no auto rebuild)? I understand the lag with rebuilding the surface, but not the simple things. It was my understanding that AutoCAD had a system where all drawing data is been copied locally to work on, and saves go back over the network. It seems like Civil3D / AutoCAD generates a ton of unneccesary network traffic for many things which should be able to happen strictly locally. Am I missing out on a setting somewhere?
Thanks!
Hi all,
In Autocad LT 2014, my client was seeing the same millions of accesses to C:\windows\CSC with some drawings (using procmon.exe). This made it impossible to switch between viewports: "Not responding" more than 15minutes, and finally Acad either crashed or the process had to be killed.
We were able to dramatically reduce this delay by disabling the Windows Offline Folders (Start > control panel > Sync Center, see http://www.sevenforums.com/tutorials/48829-offline-files-enable-disable-use.html).
Switching between viewports now takes "only" 20-30 seconds.
The tip to disable Offline Files was suggested in an older post: http://blog.jtbworld.com/2005/02/performance-tips-when-using-ssm.html
That's good you were able to figure out your problem.
Our users though are complaining in general that things like switching viewports shouldn't take 20-30 seconds to switch, in my opinion switching viewports should only take about 5 seconds.
I still haven't heard from Autodesk explaining to me why acad.exe looks for files in places it shouldn't be looking in.
I have sent them the processmon file showing proof of what acad.exe is looking for and I haven't heard anything.
Brent
I spoke too soon on several counts.
2012 and 2013 behave the same now, that is, delays when switching between drawings when Toolspace is open, delays when expanding the trees in Toolspace, etc.
Had thought that all the WAN and hardware upgrades had done the trick. They did for a while, but everything is broken again. I try to remember to close Toolspace before CTRL-Tabbing between drawings, but in the heat of battle, I often forget, so I get the watch the whirly cursor do it's thing, and the title bar text flicker.
Yup, we have a few Vault licenses that don't get used very much, if at all. It works, but it is a pain when only a handful of people actually need it (people like me in a remote office), but most who need to access the Vault don't actually need it (the people in the home office where the main server is located.)
Thankfully, I'm retired and I am working on an hourly basis for a little supplemental income. Having to deal with this 40 hrs a week would be unbearable......
Some reponse from Autodesk at this point would be really good . I'm running 58 survey crews on an LNG construction project, and some pointers to help organise the AutoCAD setup better would be a great help. My staff are experiencing the described delays delays persistently, until now I was blaming my company's IT network for most of this, but the symptoms are very like those described in the above contributions.
Hello,
Wie have the same Problem with ACA 2014.
have you try it with a User who hase noch Server profil an no H Drive in AD.
When we deaktivate the Serverprofil an delete the Homde Drive Folder Path in AD ist works faster.
When the User ist loged on you can map the Home drive manuell.
When you delete the Profile Path an the Home Drive Path, delelte the Local profil from the User.
Restart the Computer an log on the user again.
Or create a testuser without Home Drive and Profil Path.
Markus, you make some good points.
Is there anyone out there who is not seeing slowness when user profiles look to network locations for AutoCAD paths? I think your input would help this thread.
Are any of you using dedicated servers, hosting only Autodesk content, not hosting project files, and accepting requests from no other software? If you are using a shared server, isn't it possible that other traffic is impeding AutoCAD's ability to reconcile all its paths. Something else has that server's attention. If the server only answers to Autodesk, it should respond faster to the pathing requests coming in from the users.
Tim
Hi,
Thanks for your insightful post Brent. It has really helped us in figuring out our issue. Our users had similar issues. For us it was across all Autodesk products and not just Civil3D, but Civil3D seemed to be affected the most. Like everyone, looking at CPU/RAM/Disk Latency/Network stats from the servers down to the users showed that our usage was really low with ocassional spikes to 50%-70% of resources.
For disaster recovery related purposes, I've had my DNS TTLs set to 20 mins. After changing the TTL to 24 hours for all the AutoCAD related servers (file servers hosting drawings, plotters/plot-styles/fonts/etc, license server), the issues seemed to have gone away. It's only been two days, but I am crossing my fingers.
Since Autocad connects to the search paths multiple times even when drawing a line, you can see how trying to resolve a DNS name every 20 mins or less can slow things down. I would suggest all of you check your TTLs and increase it to 24 hours or more. You can lower it back down to a reasonable number once you have figured out that's the issue.
In addition to the TTLs, other things I did are
Turned off auditing on the file servers to the AutoCAD plotters/plot styles/support paths.
Turned off Windows Search and Offline Files services on the people who have been complaining.
Set antivirus scanner to only scan on modify and not on access.
However, I am fairly coninved that it is the TTL settings that fixed the issue. I would highly suggest anyone having AutoCAD slowness issues on the network check their TTL settings.
Hope this helps someone out.
I have a Network Activity Indicator app running that shows the blinking monitors (like windows xp) with network traffic. When there's a delay with Civil 3D, i see an outgoing blip, a delay, and as soon as the incoming blip is done, Civil 3D comes back to life.
Pardon me, I did not read every post in this thread so this may be a repeat.
If you have not done this yet then.... get C3D up and running to the point where you are expecting to have the problem. Then Unplug the network cable (and make sure there are no other network connections such as Wifi).
Does the problem still exhibit itself?
I'm glad I was able to help you out.
I'm curious how things are going now and if the change you made to the DNS TTL was the answer?
I have also turned off auditing and windows search and told Antivirus not to scan any Autocad related type of file and that didn't seem to help out, so I'm really curious if it's the DNS.
Could you explain where this DNS TTL setting is, are you setting this just on the DNS server or just the servers where the Autocad related servers are or both?
Thanks
Brent Morris
It's been over a week since the changes and users are saying it's working good. They say the random freezing issues are gone and unless someone proves me wrong, I am convinced the DNS TTL was what fixed it.
The DNS TTL setting only needs to be changed on your primary DNS server. It should then replicate to your secondary DNS servers. You only need to change this TTL setting for servers AutoCAD connects to. This would include file servers where your drawigs reside, file servers where you store plot styles/plot paths/support files, and AutoCAD network licensing servers.
You can see the link on how to change the TTL of a DNS record from the following link. https://kb.edgewebhosting.net/KnowledgebaseArticle53052.aspx
What is your current TTL setting for your AutoCAD related servers?
Also, are you guys using DFS (Distributed File System)?
Thank you.
I just made those changes to those servers that host the files, support files, and licensing and we will see if the users notice a difference.
Are TTL was set to 20 minutes and I changed it to 1 day just like you did.
I don't think we are using DFS.
I have also been researching into Branche Cache.
http://technet.microsoft.com/en-us/network/dd425028.aspx
Brent
It'd be interesting to see if TTL adjustment helps. Please update when you can.
For us, all our users are on the LAN and the slowness was there before the adjustment. We use DFS for everything except for AutoCAD files since Autodesk does not support DFS.
We really haven't noticed any differences.
I'm curious what your TTL settings are for your whole zone to compare to ours, I have attached a word document that shows are settings.
I started looking more into the Branch Cache and found out that you need an Enterprise or Ultimate desktop OS in order to use this feature and we only have Windows 7 Pro, but I'm not 100% sure that even this would help us either.
At this time I'm still thinking that our problem with working with Civil 3D files especially on big projects that might be 10 miles long is Civil 3D just doesn't do a very good job handling files that have 4-8 xrefs, datashortcuts, and lot's of points, so in my opinion Autodesk needs to figure something out especially on why Acad.exe is wasting a lot of time looking for files it shouldn't be looking for like I stated in my first post but I also think the we also need to really look at on how we put together big projects and might have to find a better way to do this.
One example on working on one of these big projects is it took 65 seconds just to switch to another viewport, I then copied that project to the local computer right on the C:\ and it still took 60 seconds to switch to another viewport for the first time. This only happens with really big projects, if we are working on smaller files/projects things seem ok, it's once you get paste 2 xrefs, using datashortcuts, and/or have a lot of points.
Brent
Our zone settings have the exact settings as yours. Can you check your TTLs again and see if they are still at 24 hours or reset back to 20 mins?
All the servers that I changed the TTL setting still have it set to 1 day and did not revert back to 20 minutes.
Touching back on this topic. At first glance I thought it was the TTL settings, but I think it maybe my antivirus causing the issue. Right before the TTL change, one of the things I did was exclude the Plotter and Plot-Style folders on the network from being scanned. We're using SEP 12.1 and by default, the policy is set to scan remote files on access. That change coincided with the TTL change and when all was working well after the change, I assumed it was the TTL.
A few weeks later we had random users having issues when multiple people work on a set of drawings in the same folder. It was just slow to open up drawings and sometimes they would get messages that the drawing can only be opened in read-only mode because the file was accessed by another process. Tests showed that the issue was repeatable on other type of files such as doc, xls, pdf and txt files. If a user opens a file and another user opens the same file, it takes a good 30 seconds to a minute to open the file or to notify that that file can only be opened in a read only mode.
Researching on the issue lead me to this link. http://blogs.technet.com/b/markrussinovich/archive/2010/12/07/3373406.aspx . As suggested, we disabled the remote file scanning on all the computers and as of this morning, we are not able to repeat the issue with doc, xls, pdf and txt files. Looking at the disk usage, it seems a bit lower than the previous days although our I/O was never high to begin with.
I wouldn't say the problem is solved, but this looks hopeful. If you're using Symantec Endpoint Protection (SEP), I suggest you take a look at that setting.
Turns out that most of the problems I was having had to do with our WAN accelerator hardware settings. Since IT got that figured out, I've been happy with the performance of our WAN. The only time I have problems is when IT does a large data transfer. I don't know if it is server latency or just the load on the connection, but it really drops the performance to a dismal level. If I whine a bit, they delay the transfer. Don't know why the do it in the middle of a work day in the first place!