License Server Seems to Have a Memory Leak

We are constantly getting “Windows is Out of Virtual Memory” messages on our machine running the VRay dongle. This requires us to restart the license server on a regular basis.

SysAdmin is reluctant to increase the page file because they suggest a licenses server shouldn’t really need to allocate so much resources. We also checked to see if the install for a slave provides a different cgauth.dll and maybe we had the wrong one on our slaves but it looks like we have it set up correctly.

Any one else have anything of this sort happening? I even limit the machines that hit the lic srvr at one time and it does no good. We don’t know when or what will crash the server on a daily basis.

Anyone have quick access to the minimum system requirements for the WibuKey drivers and VRLserver combined?

--Jon

Have you checked in the task manager - processes list to see if it is the licence server using up all the memory.
How much is it using?

vray final 1.5, max9 64, and xp64, afte more than 12 hours of usage, vrlserver.exe is still at 1.6 megs of ram used.

It seems a bit sporadic and I’m not really monitoring that server but just checking it right now it says:

Current ~10 MB
Peak ~200 MB

This machine only has 256 MB of RAM but it still seems a bit odd that the VRay license server should need that much. We don’t really seem to have a problem with any of our other licensing systems.

pre-1.5 days we had this same problem and we ended up using the software license for all our slaves so they never hit this server at all and the dongle only served the workstations.

Whatever it is you can imagine it’s extremely frustrating as I can never rely on some random job being rendered and sometimes I have to connect from home to reboot the license server.

Would probably be nice to have the option of rebooting from the HTTP interface as apposed to just a shutdown and monitor feature.

--Jon

This is very interesting… Thanks for the information. I wonder what else it could be. I can’t imagine bad RAM would do something like this. Where could that spike of memory consumption come from? That must be when it crashes the service.

--Jon

Ours has been running for months without errors, I’ll take a look tomorrow and see what it’s memory usage is, no help I know but at least another example of it working.

Do you have an estimate of how many machines may have attempted to access the license server at the same time (workstations + render slaves)?

Best regards,
Vlado

It seems like we regularly have 40-50 machines hitting the VRL server lately. Being that they are spread across multiple jobs that each have a limit of five machines, with my understanding, it would be improbable that the the VRL server should need to allocate that much memory. I guess it could potentially go up to about 150 machines on some occasions with our current farm configuration but I don’t think that has been the case for any VRay renders yet.

I have captured an HTML of the “Get status of the server” page when I first got in after reading your message this morning. It was just after I requeued four jobs with 5 machines each. Please let me know if you would like me to send it to you. Not sure if this is relevant but the display of our stats page sometimes looks a bit odd as if it is formatted wrong also. Should it reatain information about all of the slaves or jus tthe workstation licenses.

Something new that just came up with a coworker sitting next to me is that his workstation lic just seemed to fail out and fast exit Max while testing a Multi-Pass Camera Moblur render (locally) using VRay. When he turns off Multi-pass it renders fine (we even tried to do a test of rendering 4 or 8 times in a row to see if we could force it to crash - with no luck). Does VRay hit the lic server with every pass of a multi-pass render?

Thanks,
--Jon

Please ignore this last bit, it looks to be a bug in one of our fluid plugins :sweat_smile:

--Jon

lol, happens to the best of us and our inhouse fluid plugins. :lol:

From what I see, the server will allocate 2 MB per connection for data buffers; so if you have 50 connections at the same time, this may give quite high memory usage; although connections only happen for a fraction of a second, while a license is requested/released. Of course, for this particular purpose 2 MB is a bit too much so we’ll reduce this as much as possible.

Best regards,
Vlado

Yeah it really blows me away what these guys in our RnD dept give us for fluids solutions… kinda moistens my eyes like seeing the development of VRay over the years :wink:

I really hope, and constantly push so that, we start spending more time getting a more direct connection from Flood to VRay. I’m always looking for a reason to use it and on many occasions it has been a great solution.

Though it’s not always our singular rendering solution I can point out its use in almost every project we’ve worked on.

--Jon

This is great news Vlado! As always, thanks so much for the support:)

--Jon

my vrlserver was using 1.3Gb of memory today as reported in task manager.

had to restart it. max 2008 vray 1.5

happened a couple of days ago as well so i dunno whats causing this

Hi Jon,

I would be very interested what you guys plan on the flood - VRay connection.

Best regards,
Dieter

This should have been corrected for the service pack (vrlservice uses a lot less memory now).

Best regards,
Vlado

running into this now

this is what i walked into this morning :wink:

More details.. I am set up as the primary target for the render farm to snag a license from. my coworker has borrowed my dongle for the evening, and unthinkingly (I reminded him several times) sent a job to the farm.

I’ve had this happen many times previously, much more frequently in the past several weeks however. all previous times it has been with the Dongle in the computer.

Hi, and sorry it’s so late… for whatever reasons I missed a notification that there were replies to this thread.

Dieter, there aren’t any immediate plans to connect Flood with VRay with our current resources being focused on rewriting flood. Check your PM though.

Vlado/ Dave, I have had much more luck with VRL server since the SP1 upgrade. I believe it has only gone down once, perceived from my end, and this was probably due to IT reconfig or something like that.

I think the trick is to make sure everything gets the SP1 upgrade.

--Jon

yeah thats exactly what i’ve got. over 1.3 GB memory usage at times. normally it sits on about 4Mb but everything now and then something goes wrong.

I have the manager and rendering machines on this network with my workstation which has the dongle. The other machines refer back to the workstation for the licence. the workstation is also connected via VPN to the office so it may grab the occasional texture from there at times when a job is sent to render. Could this be the cause?

When the problem occurs, Max starts running very slowly and eventually crashes. I’,m not sure whats starting the problem but think it may be when i click to network render…it can sit there for a long time before the dialogue shows up.

This is a relatively clean installation and i havnt had any problems other than with quicktime (who doesnt have problems with this POS)

The only other thing i can think of is that when i uninstalled the previous version, there was an error and i noticed today that there was already a vrlservice running which may well be the old version, so that probably didnt uninstally properly. I guess i’ll try that first