This is probably old hat for some folks here, but I discovered something interesting. This is likely to be more important to folks with older hardware (like myself), since it most likely affects them.

I found when trying to render something with fancy settings all the way through, after my memory usage gets too high (and it starts hitting the HDD and going into virtual-mem) I start having instability and things get really sluggish if not freezing completely. One clue of this seems to be that the CPU usage goes from a near constant %100 to thrashing all over the place. (If you monitor process activity, you'll also see Carrara being juggled with System Idle or System processes.) Apparently Carrara doesn't properly clear memory used after finishing tiles in a continuous render. (Dunno about v.7+, but this seems to be true with older versions.)

So the fix is to use batch mode rendering. Once you get everything setup to render the normal way, save the file and then load it into the batch renderer. And then render it as a batch item. The thing that is important, is that you watch the task manager to see when memory usage starts getting high. (PF memory use starts approaching installed memory amount.) Then you go to the renderer and pause it. Then let CPU and memory settle down. Then resume the render. Interestingly enough, it starts out again with a lower memory use before creeping up again. It may be a form of "babysitting" a render in order to manage memory use, but it keeps the program from freezing completely so a render can actually be saved out of Carrara.

Anyone else do this?

I've never done that, but thanks for the heads up on that.

It sounds like Carrara may be handling memory cleanup with a garbage collector running on a separate thread... if they're not forcing a collection and waiting for it to finish every so often, then a long, heavy render could conceivably chew up memory before the GC (usually a low priority thread in most designs) gets to it.

GC's are great for programmers, because you rarely have memory leaks with them, but they're not necessarily the most efficient way to handle memory from a performance point of view.

I've just noticed 6.2 seems to be a little better on this than 5.1. (Since I just upgraded.) But if you hit indirect lighting, have multiple light sources, a transparent and/or reflective material, and do anything with caustics, the memory usage can climb fairly quickly into the unstable range. For more "regular" scenes, not so much. This is also easier to have happen if you multitask (doing light things like browsing/email) while rendering in the background.

That garbage collection thing is probably true though, since if you can wait long enough (like another day at least) the memory use may go back down when done. (When not using the batch method mentioned.) But it's best to not let it hit virtualmem territory in the first place. (Having an extra GB or using newer hardware probably helps alot.)

Waiting on the memory to free up reminds me of an interesting (but totally unrelated) event that happened in my younger days. I was doing phone support on a Monday morning, when I got a call to terminate a runaway print job from the office next door. Fairly routine stuff. I went next door (this was pre-network), got on the computer there, killed the print job, and cycled power on the printer to flush the data. No big deal.

The woman I was working with thanked me, and mentioned that she had tried to take care of it herself. She actually sent the job the previous Friday, and, not knowing what else to do, she turned the printer off. She had been hoping that the report would (this is a direct quote) "drain away" over the weekend.

I accepted her thanks with a straight face (she didn't know anything about print spoolers and why the report was still in the computer for almost the entire print run [the printer having a memory buffer of about 256 bytes]) and walked away.

Me and the rest of the gang couldn't help laughing about it later, though, and talking about the "drain plug" that we might be able to install on newer printers.

Another thing I have seen is reducing the size of the scratch disk to help resolve that as well.