Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X
Version: Windchill 13.0
Use Case: The problem is that the converted drawing takes up too much space on the server.
Description:
Hello,
I'm currently experiencing a server overflow issue.
After checking the database and server, I believe the issue is due to the large number of drawings being checked in or created by new rendering tasks.
I haven't been deleting these unnecessary drawings, so I think there are too many.
There are 34 million data items in the Vault, making backup and recovery difficult.
Does anyone know of a way to resolve or somewhat alleviate this situation?
Thank you
Solved! Go to Solution.
Have you calculated any rates on drawing/CAD model iterations creation? You should also be monitoring vault file growth over time. I do not know the size of your installation but perhaps there is some scaling issue. You pointed to the WVS as a cause and yes, it does produce a lot of files but of little size. Drawings specifically should not but assemblies are typically the major contributor.
"considering a method to find old iteration drawing information that isn't in the database" - This is already handled via the removing "unreferenced files" feature of the vaults. This should be run periodically, especially if there is a large deletion of data. If you are running purging or as @TDT mentioned. clearing published data on older iterations, then you need to remove unreferenced files. When Windchill deletes data, the files remain in the vault.
You need to be running this task periodically.
Note that when you setup purge jobs (from Site admin), this can clear old iterations of data. Any published content associated with that is also deleted. So doing purging of un-needed iterations can help keep vaults in check.
You can certainly take steps to reduce file creation if that is your issue. One step is to have it publish to a .pvz which wraps everything up as a single zip file creating only 1 file entry. This is more for assemblies but might help. It has a tradeoff when you open Creo View, it has to download a big zip file instead of streaming components in as they are asked for by Creo View. Publishing creates a lot of little files and I am not certain that all of them will be captured in the pvz.
Second thing you can do is only publish on release and not on check in. Trade offs here but this means that you will not see thumbnails and content created on each check in. You can also run jobs that purge out published jobs on out of date representations. This can be setup periodically. Purging in general older iterations will do this as well.
Remember that files are never removed from the vaults. You have to run remove unreferenced files jobs to do that.
Thank you for reply, avillanueva.
We've talked a lot about your reply, but we've decided that it can't actually proceed.
People want to see the thumbnail before it's released, and they want to be able to see it all at once in Creo View.
We're currently considering a method to find old iteration drawing information that isn't in the database and then delete those drawings from the server. However, we're still reviewing it, as it seems like it could be problematic.
So, I think your answer 'You can also run an action to clear posted actions for expressions that are dated past. You can set it periodically. Usually, this is also done when you remove old iterations.' can make it easy.
Could you tell me about that function or method or related eSupport Report?
Are you referring to the function to delete 'expired thumbnails' through WVS scheduler?
Have you calculated any rates on drawing/CAD model iterations creation? You should also be monitoring vault file growth over time. I do not know the size of your installation but perhaps there is some scaling issue. You pointed to the WVS as a cause and yes, it does produce a lot of files but of little size. Drawings specifically should not but assemblies are typically the major contributor.
"considering a method to find old iteration drawing information that isn't in the database" - This is already handled via the removing "unreferenced files" feature of the vaults. This should be run periodically, especially if there is a large deletion of data. If you are running purging or as @TDT mentioned. clearing published data on older iterations, then you need to remove unreferenced files. When Windchill deletes data, the files remain in the vault.
You need to be running this task periodically.
Note that when you setup purge jobs (from Site admin), this can clear old iterations of data. Any published content associated with that is also deleted. So doing purging of un-needed iterations can help keep vaults in check.
Thank you for detailed answer.
I'm currently developing a deletion plan based on the information you shared.
The information you shared will likely solve the problem.
Consistently deleting unnecessary files should be sufficient.
I'm also looking into ways to minimize the additional capacity required for the many iterations that will occur.
Hello @HK_10285495,
It looks like you have some responses from some community members. If any of these replies helped you solve your question please mark the appropriate reply as the Accepted Solution.
Of course, if you have more to share on your issue, please let the Community know so other community members can continue to help you.
Thanks,
Vivek N.
Community Moderation Team.
Hi @HK_10285495,
We faced a similar issue where our vaults contained a large amount of data.
As @avillanueva mentioned, we implemented a similar solution — a weekly scheduler that deletes representations for CAD objects, keeping only the top three iterations.
Hi @TDT ,
I'm interested in doing something like that - scheduling deletion of CAD representations. Can you share how you're doing that?
Hello TDT
Thank you for reply.
That's a very interesting answer.
I imagine there are a lot of variables involved, but have you had any issues using that configuration internally?
If possible, could you share the logic?
