Render time inconsistent

   1950   8   2
User Avatar
Member
5 posts
Joined: Oct. 2012
Offline
Hi all,

While trying to render a scene, the average render time of a frame is around 3/4 minutes, the problem however is that every +- 12 frames (or sometimes completely random) the render takes more than 3 hours to complete. The next frame will be 3/4 minutes again.
When I'm interrupting the render and render the frame again it will be 3/4 minutes again for the same frame that took 3 hours. I tried to render over the weekend and looking back 1 frame took 20 hours where as the next frame took 3/4 minutes and re-rendering the frame also took 3/4 minutes.

I have a scene with several Alembic animations and hair. Also have a bunch of packed primitives in my scene.

Anyone knows what's going on or experiences the same issues?

Using Houdini 16

Cheers,

Jelmer
User Avatar
Member
1743 posts
Joined: March 2012
Offline
Do the long renders actually finish correctly, or are they hitting a time limit, running out of memory, or being killed manually?

If they're finishing correctly, it might be that the renders are running close to the physical memory of the system, and if the swap partition or pagefile is on a slow harddrive, the long renders might be swapping and taking a very long time because of the swapping. If that's the case, the short renders are fast because they're avoiding swapping. This could also be what's happening if the long renders are being killed by hitting the swap memory limit.

If they're being killed early because of a time limit, it might be a deadlock, in which case it would be a bug, so if it's that case, please submit a report to support.

If it's none of the above, it's difficult to guess what the issue it might be without an example that demonstrates it.
Writing code for fun and profit since... 2005? Wow, I'm getting old.
https://www.youtube.com/channel/UC_HFmdvpe9U2G3OMNViKMEQ [www.youtube.com]
User Avatar
Member
5 posts
Joined: Oct. 2012
Offline
Thanks for the reply!

The renders seem to finish correctly, I have no problem comping them in Nuke.
Is there a solution to this problem or is it the Hardware?

Thanks!
User Avatar
Member
1743 posts
Joined: March 2012
Offline
How much memory are they using? Can you post an example that demonstrates the issue?
Writing code for fun and profit since... 2005? Wow, I'm getting old.
https://www.youtube.com/channel/UC_HFmdvpe9U2G3OMNViKMEQ [www.youtube.com]
User Avatar
Staff
5161 posts
Joined: July 2005
Offline
I'd suspect memory. If you had 32GB installed and the renders were hovering around the 30GB mark, it wouldn't take much extra memory use to suddenly go over into swap/pagefile territory, and then you're looking at nearly 0% CPU usage while the I/O churns away, swapping memory pages in and out.
User Avatar
Member
5 posts
Joined: Oct. 2012
Offline
It seems that the memory peaks at about 15 gb. I changed the cache memory ratio to 0.5 trying to fix the issue, didn't work tough.

In addition, today I work on the computer and After Effects takes sometimes upto 40 gb of Ram and the Render seems fine, only slows down a little bit.

I have 64 GB of RAM forgot to mention.
Edited by JelmerHoekstra - May 2, 2017 15:22:45

Attachments:
MemoryHoudini.jpg (148.3 KB)

User Avatar
Staff
5161 posts
Joined: July 2005
Offline
Any texture or geometry files being fetched over the network?
User Avatar
Member
5 posts
Joined: Oct. 2012
Offline
No everything is on my local drive, however, I do have the setup for the HQUEUE so my folder is shared but still on my local drive.

I just did another test and it hang on frame 47, number 10 in this sequence and the ram is at 13 gb and cpu at 97. This Render is busy now for almost 2 hours.
User Avatar
Member
5 posts
Joined: Oct. 2012
Offline
UPDATE: Seems the problem is fixed, I changed the material on the packed primitives. I'm not sure what's wrong with the previous material but I remember I had the same problem with packed primitives in a previous scene when they took a long time to render. Going 45 frames now with a average of 4 minutes, no spikes.

Thanks for the help.
  • Quick Links