DAZ keeps using memory even after being closed
mlominy
Posts: 220
After rendering a scene and exiting from DAZ, I was surprised to find through Window's Task Manager that DAZ was still using a substantial amount of memory (around 4 Gb). There was a Daz Studio Application open in the Process Tab although Daz was already closed.
I had to make an End Task to free that memory . Any explanation?
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Not uncommon actually. Lightwave is even worse. If you look at the memory column & it's static, ya just kill it. But if you watch & it's trickling downward, it'll eventually realize it can free things up, generally just under 4Gb it seems.
I am advised that All advice to "just kill it" is bad advice. You can cause problems by following this advice.
@Chohole "I am advised"
Given this is a long standing issue with many, it would also be nice if the "adviors" also advised the dev team to work on having Studio clean up a bit faster.
I keep hearing and reading this, but I've been doing it for years, going back to DS 2.1, and have never had a "problem" that was attributable to killing DS, and I've never met or heard of anyone who has, either. I suspect the "advice" is a canard like the old, "Always completely shutt down your computer before turning off/disconnecting an external drive or you risk corrupting the drive" and "Turn on your computer before turning on the monitor or the power surge from the computer starting up will damage your monitor."
DS has a lot of clearing up to do after a busy scene - closing it without having loaded content etc. is pretty quick. I'm sure the develpers are highly aware of the issue, but that doesn't mean they can simply have DS "make it so" when shut down.
Force quitting risks corrupting some of the settings files and so on, which are written to reflect the state at close down.
DS takes too long to shutdown a scene, so sometimes I quit the application and start it again to quickly load a new scene.
The only problem with that is I now have two DS applications running in the background, one trying to shutdown, and the other trying to load a new scene. This may lead to a crash if there's a conflict.
Be aware that you're also risking database corruption. One of the shutdown background tasks is updating the content database. One of the startup tasks is checking and connecting to the content database. If you get the two in a tug-of-war, you're the loser as your content database goes through the blender and needs its feet nailed to the perch. Some computer things can be rushed. This can't.
Well of course folks. I'm talking after couple minutes, no drive activity & no memory usage change wheh it's painfully obvious the app is hung. It's very rare that's needed though. And I've NEVER had any corruption or file loss killing a hung app via TaskManager since back in the days of NT.
You're risking corruption every time you start DS, add or delete content, edit metadata, load an object, or the OS defrags the drive it's on.; hell, you're risking corruption any time the OS accesses the disk for any reason.
I've quit and immediately restarted DS with the shutdown thread still showing as running in TaskManager hundreds, if not thousands, of times over the years, and have yet to experience even a minor hiccup, much less a screwed-the-pooch db corruption.
Unless and until someone publishes console logs that clearly document a non- auto-recoverable corruption as a result of force qutting DS, I'm calling it an urban legend.
Having this issue too.
It is Daz, as it happens even on a fresh install.
It seems to hold onto 3gb to 5gb, sometimes 12gb of ram post shut down. Forcing it closed in task manager does it.
but due to this, it means it wont open sometimes if you do not realise its still actually running..
Cinema 4D does this too though. (r21 anyway)
How you run your system is up to you, but you shouldn't encourage others to adopt potentially risky (as in, more likely to cuase issues than the base-line risks) practices.
Well, I have yet to be able to simply Quit out of DS. I always have to Force Quit. Always.
How long are you waiting?
Why should this be a risk to any of the settings files? Assuming that any settings, unless modified, are loaded as read only. Even when they are modified the changes should persist upon completing the operation not while shutting down DS. Are you suggesting that random crashes of DS have the potential to corrupt any settings?
Personally, I would be more concerned about resource leaks (like file handles, RAM, GPU memory etc). TBH, rebooting the system after process kill is often faster than waiting for a normal exit and resource deallocation.
Edit: One scenario I can think of is the PostgreSQL db file corruption upon force exit. But that could be avoided if the DS shutsdown the db process before beginning the lengthy resource cleanup. I hope its implemented that way.
"Potentially risky" and "more likely." How about quantifying "potentially": 1:1? 1:10? 1:10000? 1 in a billion? And while you're at it, how much is "more likely"? Twice? 5x? 10x? 10,000x? 10,000,000x? 10,000,000,000,000x?
We keep hearing about "potential" risks and greater likelihoods, but in the 15-some years I've been using DS, I've yet to come across a thread, here or elsehwere, documenting an actual corruption of some sort caused by force-quitting. Meanwhile, there are plenty of threads about DIM or Daz Connect hosing user's installations.