Hi,

in order to speed up my POV-Ray rendering, I keep my Windows Task
Manager (WTM) on and changed the Priority of POV-Ray to "High", but only
during the nights.

But having the WTM always open, allows me also to see the memory usage
of POV-Ray. I am observing, that I started the render with a usage of
450 MB or so. Now, after 8 days, the memory usage lays at 3.7 GB.

1
Does this point towards memory leak(s), or is this normal?

2
I have 8 GB of memory. What will happen if POV-Ray reaches a memory
consumption 0f 7 or even 8 GB?

Post a reply to this message

On 1/31/2016 6:37 PM, Sven Littkowski wrote:
> Hi,
>
> in order to speed up my POV-Ray rendering, I keep my Windows Task
> Manager (WTM) on and changed the Priority of POV-Ray to "High", but only
> during the nights.
>
> But having the WTM always open, allows me also to see the memory usage
> of POV-Ray. I am observing, that I started the render with a usage of
> 450 MB or so. Now, after 8 days, the memory usage lays at 3.7 GB.
>
> 1
> Does this point towards memory leak(s), or is this normal?
>
> 2
> I have 8 GB of memory. What will happen if POV-Ray reaches a memory
> consumption 0f 7 or even 8 GB?
>

This is normal. If you run out of memory your whole computer will lock up.


Mike

Post a reply to this message

On 1/31/2016 11:37 PM, Sven Littkowski wrote:
> Hi,
>
> in order to speed up my POV-Ray rendering, I keep my Windows Task
> Manager (WTM) on and changed the Priority of POV-Ray to "High", but only
> during the nights.
>
> But having the WTM always open, allows me also to see the memory usage
> of POV-Ray. I am observing, that I started the render with a usage of
> 450 MB or so. Now, after 8 days, the memory usage lays at 3.7 GB.
>
> 1
> Does this point towards memory leak(s), or is this normal?
>

What version are you using?

-- 

Regards
     Stephen

Post a reply to this message

Le 16-01-31 18:37, Sven Littkowski a écrit :
> Hi,
>
> in order to speed up my POV-Ray rendering, I keep my Windows Task
> Manager (WTM) on and changed the Priority of POV-Ray to "High", but only
> during the nights.
>
> But having the WTM always open, allows me also to see the memory usage
> of POV-Ray. I am observing, that I started the render with a usage of
> 450 MB or so. Now, after 8 days, the memory usage lays at 3.7 GB.
>
> 1
> Does this point towards memory leak(s), or is this normal?

Normal

>
> 2
> I have 8 GB of memory. What will happen if POV-Ray reaches a memory
> consumption 0f 7 or even 8 GB?
>

You'll start on the road of paging hell as more and more of the data for 
the scene get swapped back and forth between the RAM and the disk.
If you have no more space in virtual memory, welcome computer crash.

Post a reply to this message

Am 01.02.2016 um 02:20 schrieb Alain:

>> 2
>> I have 8 GB of memory. What will happen if POV-Ray reaches a memory
>> consumption 0f 7 or even 8 GB?
> 
> You'll start on the road of paging hell as more and more of the data for
> the scene get swapped back and forth between the RAM and the disk.
> If you have no more space in virtual memory, welcome computer crash.

Running out of /virtual/ memory is a feat that on a Windows system
rarely ever happens. Before that, Swap Hell will become so bad that the
render (and everything else on the computer) grinds to a
near-standstill, including anything that would allocate additional memory.

Post a reply to this message

The end of the universe. Suns dim to red giants, and die. Red dwars.
Break-down of atoms, neutrons. The end of matter as we know it. The big
freeze.

I hope, after POV-Ray finished the area with the red hangars, all
remaining stuff will be faster and be finished before the memory
consumption gets too bad.

Post a reply to this message

On 1/31/2016 8:51 PM, clipka wrote:

>
> Running out of /virtual/ memory is a feat that on a Windows system
> rarely ever happens.

I actually had povwin suck down all my memory the other day.  Windows 
(8.1) was kind enough to say "you really want to kill this guy".

I currently have a povwin idling at 2GB real memory and 8GB virtual 
memory.  In this instance, I have rendered maybe 800-1000 frames (test 
frames, low object count).

This isn't anything I even looked at until the other day when it freaked 
out.  I'm not saying it's leaking, but it would be nice if it gave back 
the memory when it was doing nothing.

Post a reply to this message

Am 01.02.2016 um 19:10 schrieb dick balaska:
> On 1/31/2016 8:51 PM, clipka wrote:
> 
>>
>> Running out of /virtual/ memory is a feat that on a Windows system
>> rarely ever happens.
> 
> I actually had povwin suck down all my memory the other day.  Windows
> (8.1) was kind enough to say "you really want to kill this guy".

Okay -- that is new then.


> I currently have a povwin idling at 2GB real memory and 8GB virtual
> memory.  In this instance, I have rendered maybe 800-1000 frames (test
> frames, low object count).
> 
> This isn't anything I even looked at until the other day when it freaked
> out.  I'm not saying it's leaking, but it would be nice if it gave back
> the memory when it was doing nothing.

That, too, is something new (at least to me). Needs more details to
investigate though.

Post a reply to this message

On 2/1/2016 2:48 PM, clipka wrote:
> Am 01.02.2016 um 19:10 schrieb dick balaska:
>> On 1/31/2016 8:51 PM, clipka wrote:
>>
>>>
>>> Running out of /virtual/ memory is a feat that on a Windows system
>>> rarely ever happens.
>>
>> I actually had povwin suck down all my memory the other day.  Windows
>> (8.1) was kind enough to say "you really want to kill this guy".
>
> Okay -- that is new then.
>
>
>> I currently have a povwin idling at 2GB real memory and 8GB virtual
>> memory.  In this instance, I have rendered maybe 800-1000 frames (test
>> frames, low object count).
>>
>> This isn't anything I even looked at until the other day when it freaked
>> out.  I'm not saying it's leaking, but it would be nice if it gave back
>> the memory when it was doing nothing.
>
> That, too, is something new (at least to me). Needs more details to
> investigate though.

:(  I'm gonna have to go with this is a thing now.
povwin 3.7.1-alpha.8358383+av65.msvc14.win
I think you built it.


I was starting up to run 100 frames. I looked at System Explorer 
7.0.0.5356 and noticed a handful of petabytes consumed by povwin (I 
don't remember how much, it was a lot).  I restarted povwin and started 
my render.  I notice it is leaking about 50MB per frame.
So I've done 48 frames and I'm sitting at
Mem Usage (KB) 1,972,724
VM Size (KB)   2,020,552

That works out to 42MB leaking per frame.  Seems low. What does the next 
frame give us?

Mem Usage (KB) 2,006,148
VM Size (KB)   2,055,804

It does give a little back between frames. It dropped to
Mem Usage (KB) 1,996,000

and then climbed to
Mem Usage (KB) 2,042,780
VM Size (KB)   2,094,184

I can't wait to see what it says when I get up in the morning...
...
99 frames rendered.

Mem Usage (KB) 4,217,172
VM Size (KB)   8,005,052

And then after it finished 100 frames and povwin went idle, it actually 
gave a little memory back and currently sits at.

Mem Usage (KB) 3,761,412
VM Size (KB)   8,055,384

This is the baseline memory usage for my next render job.  It will never 
go below this.  It will only go up.

Post a reply to this message

Am 10.02.2016 um 19:00 schrieb dick balaska:

> povwin 3.7.1-alpha.8358383+av65.msvc14.win
> I think you built it.

To be precise, I didn't -- it was AppVeyor that did. All builds
identifying as "+av<number>" are automated builds generated by that service.
But yes, I did authorize the build and its distribution.

Can you do me a favour and try out whether the most recent build does
the same?

I just recently discovered a bug in the cleanup of user-defined
functions; as I couldn't pinpoint when exactly it was introduced, it
might have been around longer than I suspected. If that's the root cause
of the memory leaks you're seeing, this build should fix it:

https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8463913%2Bav107

Post a reply to this message

On 2/10/2016 2:19 PM, clipka wrote:
> Am 10.02.2016 um 19:00 schrieb dick balaska:
>
>> povwin 3.7.1-alpha.8358383+av65.msvc14.win
>> I think you built it.
>
> To be precise, I didn't -- it was AppVeyor that did. All builds
> identifying as "+av<number>" are automated builds generated by that service.
> But yes, I did authorize the build and its distribution.

tomayto, tomahto.

> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8463913%2Bav107
>
Running the same render set.
boot idle:
Mem Usage (KB) 16,028
VM Size (KB)    7,704

During first frame:
Mem Usage (KB) 190,400
VM Size (KB)   243,388

2nd:
Mem Usage (KB) 221,928
VM Size (KB)   273,868

3rd:
Mem Usage (KB) 253,004
VM Size (KB)   304,468

4th:
Mem Usage (KB) 286,372
VM Size (KB)   340,000

aborted render.  Hey, it gave back lots of memory then. Idling at:
Mem Usage (KB) 185,532
VM Size (KB)   197,652

Post a reply to this message

Am 10.02.2016 um 22:32 schrieb dick balaska:

>> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8463913%2Bav107
>>
>>
> Running the same render set.
> boot idle:
> Mem Usage (KB) 16,028
> VM Size (KB)    7,704
> 
> During first frame:
> Mem Usage (KB) 190,400
> VM Size (KB)   243,388
> 
> 2nd:
> Mem Usage (KB) 221,928
> VM Size (KB)   273,868
> 
> 3rd:
> Mem Usage (KB) 253,004
> VM Size (KB)   304,468
> 
> 4th:
> Mem Usage (KB) 286,372
> VM Size (KB)   340,000
> 
> aborted render.  Hey, it gave back lots of memory then. Idling at:
> Mem Usage (KB) 185,532
> VM Size (KB)   197,652

I presume you're currently giving it a more challenging test?

Post a reply to this message

On 2/10/2016 5:46 PM, clipka wrote:

> I presume you're currently giving it a more challenging test?

Nah. I discovered an object position problem (I think related to my 
constantly switching between 23.976 and 30 fps).  My renderfarm is 
cranking a 2 week run and I didn't want to waste 12 hours of cpu time on 
my fastest box. ;)
complete:1028 todo:2315     FPH:10.70  lastday:6.2   lasthour:7 
ETC:9 days   (15 days, 13 days)

I had looked at some leak detectors a while back.  I should look 
again... (In 1989 I paid $2K for Purify.  If we can get povwin running 
on Windows 3.1, *that* will find all leaks)

dik

Post a reply to this message

Le 16-02-10 19:12, dick balaska a écrit :
> On 2/10/2016 5:46 PM, clipka wrote:
>
>> I presume you're currently giving it a more challenging test?
>
> Nah. I discovered an object position problem (I think related to my
> constantly switching between 23.976 and 30 fps).  My renderfarm is
> cranking a 2 week run and I didn't want to waste 12 hours of cpu time on
> my fastest box. ;)
> complete:1028 todo:2315     FPH:10.70  lastday:6.2   lasthour:7 ETC:9
> days   (15 days, 13 days)
>
> I had looked at some leak detectors a while back.  I should look
> again... (In 1989 I paid $2K for Purify.  If we can get povwin running
> on Windows 3.1, *that* will find all leaks)
>
> dik
>

It's a tool to detect memory leak in 16 bits applications running under 
a 16 bits OS with 32 bits extention. Not sure if it can work for 32 bits 
applications, and would be surprised if it can work at all for 64 bits ones.

Post a reply to this message

I have seen this happen, but only occasionally. And I have a workaround.

Some while ago one of my images (I render at 2048x1536) crashed POV-Ray (XP,
intel quad core - yes, I know, I need to leave the stone age!) by eating up the
memory (gradual climb from 1.3 gb to 1.7 gb over 24 hours). It was a tree scene
so there were lots of objects. I subsequently discovered that by pausing the
render and going off to do something else on the very same machine the reported
memory usage dropped and then picked up again after restarting the render, but
at a much lower value, allowing the render to complete.

Is this the same problem, or something else again?

Post a reply to this message

Am 25.03.2016 um 13:43 schrieb Simon J. Cambridge:
> 
> I have seen this happen, but only occasionally. And I have a workaround.
> 
> Some while ago one of my images (I render at 2048x1536) crashed POV-Ray (XP,
> intel quad core - yes, I know, I need to leave the stone age!) by eating up the
> memory (gradual climb from 1.3 gb to 1.7 gb over 24 hours). It was a tree scene
> so there were lots of objects. I subsequently discovered that by pausing the
> render and going off to do something else on the very same machine the reported
> memory usage dropped and then picked up again after restarting the render, but
> at a much lower value, allowing the render to complete.
> 
> Is this the same problem, or something else again?

That exactly matches the scenario I described.

Post a reply to this message