 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
