Hi DRC, thanks for your answer.
Good to know installing libjpeg-turbo-official is not needed. I removed it now. I think it was needed some time ago, or not? Yes, this is reproducible with TurboVNC 2.2.1. We were seeing the high memory usage on TurboVNC 2.2.1 and that's why I updated to 2.2.2 hoping the issue would go away. But the issue seems to be the same on both versions, 2.2.1 and 2.2.2. And no, I am not sure it can only be reproduced with StarCCM+ (yes, right "guess" ;-) ) . I did not try to reproduce it with other software. I even couldn't reproduce it with StarCCM+, but not sure what users do over the days to end up with this high mem usage. Thanks for the explanations and for looking into it. Cheers, Richard On Mon, 8 Jul 2019 at 17:01, DRC <[email protected]> wrote: > Unsure what is going on. What I can tell you is that: > > - Yes, that memory usage is too high. > > - The problem is with TurboVNC, not VirtualGL. If it were a leak in > VirtualGL, then the memory usage would rise in the 3D application process, > not in the Xvnc process. The memory leaks that I fixed in VirtualGL 2.6.2 > truly were minor-- like so minor that they would have gone unnoticed unless > you ran VirtualGL through valgrind (which is how I detected them.) The > leaks mostly took the form of memory that was not properly freed at > shutdown, so for the most part, they didn't grow the memory usage of > VirtualGL while the 3D application was running. I fixed them primarily to > make it easier to detect more serious leaks, if they are introduced in the > future. > Note that, if you are using the official VirtualGL and TurboVNC packages, > those packages statically link with a specific version of libjpeg-turbo, so > installing libjpeg-turbo-official is unnecessary, and the installed version > of that package is not relevant for diagnostic purposes. > > I checked the diff between TurboVNC 2.2.1 and 2.2.2 and didn't see any > obvious areas of concern. Some follow-up questions: > > - Are you sure that this isn't reproducible with TurboVNC 2.2.1? > > - Are you sure that it can only be reproduced with one specific 3D > application? (StarCCM+, I'm guessing?) > > DRC > > On 7/5/19 9:36 AM, Richard Ems wrote: > > Hi all, hi DRC, > > DRC, thanks for your great work! TurboVNC + VirtualGL + libjpeg-turbo work > great! > > But now we are seeing what looks like a memory leak in Xvnc. > On a RHEL7.6 Workstation, we were using turbovnc-2.2.1, VirtualGL-2.6.1 > and libjpeg-turbo-official-2.0.2 up to one week ago. > We were seeing Xvnc consuming lots of memory, so I checked and found > "Fixed several minor memory leaks in the VirtualGL Faker." in the > "Significant changes relative to 2.6.1" list for VirtualGL-2.6.2 . > So I upgraded TurboVNC from 2.2.1 to 2.2.2 and VirtualGL from 2.6.1 to > 2.6.2 and restarted all VNC sessions. > > The memory usage for Xvnc was low for some days, but now after one week > running, one of the VNC sessions shows in "top" 601.4g virtual memory and > 127.9g resident memory in use. > That seems to be to much, or not? > > In /etc/turbovncserver.conf I've set "$useVGL = 1;" , may this be an > issue? This setting has been there for months and we were not seeing this > issue before. > > The Xvnc command line showed by "ps" is: > > # ps uw 364412 > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > <USER> 364412 1.1 25.4 632004096 134290304 ? Sl Jun27 133:52 > /opt/TurboVNC/bin/Xvnc :20 -desktop TurboVNC: serv1.bartech.local:20 > (<USER>) -httpd /opt/TurboVNC/bin//../j ava -auth /home/<USER>/.Xauthority > -geometry 1240x900 -depth 24 -rfbwait 120000 -rfbauth > /home/<USER>/.vnc/passwd -x509cert /home/<USER>/.vnc/x509_cert.pem -x509key > /home/<USER>/.vnc/x509_private.pem -rfbport 5920 -fp > catalogue:/etc/X11/fontpath.d -deferupdate 1 -dridir /usr/lib64/dri > -registrydir /usr/lib64/xorg > > This user is continuously running an application that gets started with > "-clientldpreload libvglfaker.so" . > > What is going on here? > > Kind regards, > Richard Ems > > -- > You received this message because you are subscribed to the Google Groups > "TurboVNC User Discussion/Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/turbovnc-users/4b34a770-8cd1-42a0-ac55-a9cf492066ca%40googlegroups.com > <https://groups.google.com/d/msgid/turbovnc-users/4b34a770-8cd1-42a0-ac55-a9cf492066ca%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "TurboVNC User Discussion/Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/turbovnc-users/3661f75c-8163-3a21-d43b-8cd69c6500d2%40virtualgl.org > <https://groups.google.com/d/msgid/turbovnc-users/3661f75c-8163-3a21-d43b-8cd69c6500d2%40virtualgl.org?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/CAEqczzz6Ki3JR3H9Kt3so7%2Bn9LGN1-nwZt7M%3D32a4tuXyhP3aw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
