PDMLink cache wiped out.

CM10 · ‎Apr 21, 2010

Pro/E crashed last night. I restarted and found I'd lost everything I'd done yesterday, despite saving every 1/2hr or so. You'd think I'd lose only what I hadn't saved, not everything since I last checked in the work. I'm on WF3 and (unfortunately) PDMLink/Windchill 8 point whatever. I seem to remember at my last job that a guy sent an e-mail around saying the same thing happened to him without warning when he reached (I seem to remember) 2 gig in cache size. I just checked, and mine's 2.14 gig. Hmmmm.... Anyone else seen this?
This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

CM10 · ‎Apr 21, 2010

Ok, here's another weird thing. In the much superior Intralink, we had "frames" (a snapshot of all files at whatever iteration when you saved anything). Great feature! You could go back and look, or recover the state of your workspace at whatever frame you wanted. So, PDMLink won't have frames until Ver 9. So, why, in my cache, do I have almost 2 gig of "lid" (lid_110637.wfcont) and "sid" (sid_1209957.wfcont) files? These SEEM to be iterative versions of parts, assemblies, drawings, etc. as you can change the extension to ".prt, .asm, or .drw etc. and if you guess right you can actually open the file. So, are these what PTC uses behind the scenes to create frames? If so, and we don't have frames in PDMLink 8, why are they accumulating, and how do I delete them like we were able to clear the frames in Intralink? If I delete them all, will that corrupt my database or lose me more data? Better yet, if there are no frames now, how do I keep them from accumulating in the first place?

Darrell · ‎Apr 22, 2010

I just checked my cache folder. It's over 19GB, and I never lose my cache, anymore. Maybe the size of a single workspace makes a difference, but I don't think the total size of the cache folder matters as long as you have the disk space. We had problems when we first started using PDMLink 9.0, but since upgrading all our computers to 64bit XP with 8GB RAM and updated PDMLink to the latest maintenance release, the corrupt workspaces have gone away. We are now on 9.1 M040 and they have resolved a lot of the bugs with this latest release. It has gotten much better than 9.0 M020 which we started on. Frames weren't available until 9.1. I have heard that PTC has a tool that can attempt to restore a local cache from the lid and sid files. The "l" means locally modified and the "s" means it's not locally modified; i.e. it's either in commonspace or in your server workspace, which 'never' gets corrupted.

CM10 · ‎Apr 22, 2010

Thanks for the response. Too bad my company would rather spend the $$ losing and re-doing data than upgrading either our PC's or the server and PDMLink. Also too bad, the decision was made for our new project to spend TONS of oney on AutoCRAP products, including "Vault", which by most accounts is WORSE even than PDMLink 8. Oh, for the days when we were still on Intralink.....

sschroeder · ‎Apr 22, 2010

The amount of data in your cache (or cache size) does play a role in the amount of memory the Pro/E process (xtop) takes up. This is due to the fact that the Pro/E functions and the PDM Link functions are now in a single process. There is a new config option that can split these functions into two processes in newer versions of PDM Link and Wildfire so that it behaves like Intralink 3.4 did (one process for Pro, one for Intralink). Sounds like you're running close to the memory limit for a single process on a 32 bit machine. I'd recommend cleaning up your cache regularly using the cache tab in the server manager dialog box (Tools, Server Manager) to try to limit the amount of memory the xtop process is using.

ptc-321702 · ‎Jun 21, 2010

Engineers at the Raytheon Tewksbury Facility are currently experiencing issue with Pro/E crashing often when working on very large assemblies and the related drawings. They are currently running Wildfire 3 M240 64 bit with 12GB of RAM. The engineers admit to using lot of assembly cuts to speed up the design process, but thought that creating SREPs would allow them to aviod memory issues. They are now spending a lot of time monitoring the Task Manager memory while they work; saving their work before it runs out of memory. These memory concerns takes their mind away from designing (what they want/should spend most of their time doing). No matter what, the engineers still have to be able to continue working on their designs and finishing their tasks. Everyone was really hoping that they would be able to complete their task before running out of memory and having to clean up their designs to make them more efficient.

Questions:

Is there any value that can be put in for cache (in Tools > Server Registry) that can stop Pro/E from taking so much memory that it crashes?
Since we are also going to PDMLink, will this issue worsen? I understand that Pro/E and PDMLink share the same memory resources unless you split these functions into two processes.
Is there any guidelines to help us figure out which assemblies and drawings are becoming too large to work on with our current resources?

The engineers are willing to spend some time to fix up their drawings and assemblies, but they need a quick way to determine when their databases go beyond a recommended memory limit. It takes time to update computers to 64 bit and add memory or to order and setup new 64 bit computers. At this point, the engineers are not able to call up the Master Rep without running out on memory and crashing (they can only call up SREPs). Many of our users runn 32 bit machines with the 3GB switch. However, this adds an element of instability. It seems to make sense to have a maximum target limit for RAM to be under 2GB or maybe even 1.5GB. What is a realistic number (knowing that we are migrating all our data to PDMLink very shortly; many designs are already in PDMLink)? How can databases be split up into multiple files effectively and efficiently so that engineers do not need to be so concerned about others calling up and working on their data? Maybe the answer is to move everyone to Wildfire 5 on 64 bit machines. What do you think is the best plan of action that we can take to address this issue in the long term? My job is to support the engineers in getting their job done on Wildfire and improve the design reuse and collaboration. I also am involved with supporting them in the migration from Intralink to PDM. The engineers, having the issues, are experience users (about 15 years of using Pro/E, Wildfire and Intralink). Drastically changing how these engineers design on Wildfire will be a difficult sell without a good amount to support data to backup our recommendations.

If we can somehow generate some guidelines for our engineering community, then we can avert most issues before they happen. It will also give the Pro/E support team a way to show the urgency of improving their modeling practices and clean up their models consistently thoughout the design cycle. We do not really have the luxury to spend a lot of time analyzing designs to find out what is wrong; this is really supposed to be Model/CHECK's job (with a little bit of human intervention for special conditions).

ChrisHanna · ‎Jun 21, 2010

To prevent data loss when your local cache is corrupted or deleted, add the dm_upload_objects=automatic to your config.pro if you are linked to Windchill. This will cause a background upload to the to the server side workspace whenever you save your file. This also allows your to view your up to date workspace from a standalone browser.

ptc-321702 · ‎Jun 24, 2010

Chris, will this config.pro option allow engineers with less RAM to activate large assemblies that typically require more RAM than they have available on their computer? I assume that the activation time will be very long.

Thanks for the response...........Roy Thorkildsen

ChrisHanna · ‎Jun 25, 2010

Unfortunately not. The only way around that is to upgrade to a 64-bit OS to utilize all your available RAM and then to increase the amount of RAM installed. This solution prevents data loss if the local Windchill cache compromised or if there is a hardware failure (system or HD failure etc.).

How many components are in your large assemblies? On 8 GB of RAM we routinely open two 2000+ component top level assemblies at the same time.

Are you using large assembly management techniques?

Regards,

Chris

ptc-321702 · ‎Jul 22, 2010

One assembly has just under 2000 components/subassemblies. It also includes 475 patterns and 205 groups. I was able to create a SREP to activate the assembly on a 32 bit computer with 2GB RAM. To do this, I had to manually open each subassembly to EXCLUDE it. Pro/E crashed with the "Expand All" for the model tree.