Paraview 5.9.0 RC1 (Linux binaries from Kitware) spawns now a paraview-real process. I noticed that when exporting images with ospray (raycaster or pathtracer) paraview-real fills in RAM with each exported image until the system runs out of memory. The larger the scene the more memory is blocked with each image.
I am on CentOS 7.7
it seems that the memory leak happens when rendering and not exporting, so it’s enough to just run an animation with ospray on and observe how the memory increases with each time step.
Yes most likely. Related fixes are working into rc2. See: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7418 and https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7453
This has seemed to be an issue for a long time (at least for my system setup). If I run OSPRay with the standard build it will take up all the memory it can on the entire server cluster, even when it only needs like 1/50 of it.
The best fix I have found is to cap CPU threads using the environmental variables below. This limits the resources PV can grab and has been essential to getting it to run correctly on my system.
export KNOB_MAX_WORKER_THREADS=8
export OSPRAY_THREADS=8 #This is the command for 5.8
export OSPRAY_NUM_THREADS=8 #Changed in 5.9 w/ OSPRay 2.4
Change 8 to whatever works for your system and complexity of the scene you are rendering.
@Dave_DeMarle will these new fixes mean I won’t have to do this in the future?
Those settings constrain the number of threads that SWR and OSPRay use and are good for preventing oversubscription and thread contention so they will still be generally helpful even after I fix the memory leak.
The memory leak has been fixed and rebroken a couple of times now as the code has evolved since pv5.0/osp0.7. I’ll try and add a VTK level regression test this time around to make it less likely to come back in the future.