We’ll call this “Windchill Garbage” (WG). Here are a few system-level scenarios that might cause WG to pile up.
– Long-running or Repeating Workflow Process Scenarios
Windchill can be a bit of a Tyrant, but it knows the business. Take workflows, for example. There is a tremendous argument for the efficiencies they create. But they can be tricky. The nature of workflow processes are to have specific start and end objectives, several distinct executions of tasks, and distinct start and end points. Sounds like an opportunity to set up continually repeating expressions after, or for a set amount of time, right? But what happens when running the expression itself takes longer than the time gap between run requests?
Windchill sees no real “completion” of the process so it’s constantly running, piling up garbage and never catching up, impacting Latency, Throughput, and Footprint.
If you stick to the cure, you still have the task of identifying what’s going on upstream of the dump, and downwind of… well… the dump!
Think of what’s required to clean up after a big, huge, Midwestern Thanksgiving Day meal, with 20 guests. Now think of having all of that prep and pomp and circumstance and problem every day; because that’s at least the level of resources required to clean up after the party, address the accumulated garbage, and settle the disruption. Eventually, it’s going to get ahead of you. You’ll see it in latency, throughput, and footprint problems.
Here’s another one:
– Replication: Non-Optimized Schedule, Quantity of Sites, Size of Files to Replicate, Resources Available
Windchill is powerful when you need to take advantage of the software’s abilities to replicate content across global locations for data integrity, security, and just common good sense. But it’s important to closely map out this strategy. While Windchill is configured to handle up to 3 simultaneous replication runs on default, poorly configured processes can generate a sizable load on the MS/BGMS processes, creating Windchill Garbage.
The quantity of replication files, the size of individual files, and the quality of the connection between sites can also put the MS/BGMS in a no-win scenario and max out your memory – which is a whole other problem by itself. To unravel all of this you’ll need to analyze how “busy” sites are, how “fast” the pipe is between the sites, and how to configure the optimal balance. You might limit replications to only “one at a time”, or have a MS/BGMS that is dedicated to ONLY the replication process, etc.
The best option is really going to be based on optimizing your process support needs.
Ideally this would include alignment of configuration rules with replication rules, and data storage practices to optimize performance. Or it might include working out a garbage management schedule for each site. Ironically, “faster” sites with better connections can also have a longer time frame between replication runs, which enables data build up due to the larger volume of items to replicate. “Slower” replica sites, on the other hand, can replicate more frequently to keep the quantity of files to replicate “per run” low.
The point is that garbage collection is a thing.
And you’ll spend a lot more time and resources treating the illness than you will with a cure. Going back to my Midwest Thanksgiving analogy you’ll enjoy the time more, the outcomes will be more fulfilling, and you’ll keep your friends. But most importantly, you’ll spend less time in your robe and slippers hauling out trash on a frosty Friday morning!
It’s a systems thing.