locked
High Memory Usage With App-V 5.1 Client RRS feed

  • Question

  • We recently upgraded to App-V 5.1 and we're seeing high memory usage with the AppVClient.exe process. After reboot, usage starts at about 10MB and then quickly grows to nearly 800MB+ while its updating packages. This isn't the worst of it though. As they day goes on, this number climbs even higher. I've logged into a few machines and seen the number as high as 2.8GB. 

    Any thoughts on this? Our students have not complained about it (yet) but with our machines having only 8GB of ram, this is going to have a big impact on resource intensive applications. 

    The computers are running 64-bit Windows 7 Enterprise and we have about 39 packages. Some are assigned to the computers and some to user groups. 

    Tuesday, January 19, 2016 5:59 PM

Answers

  • Open up a case with MS Support and have them take a WPR trace.


    Steve Thomas, Senior Consultant, Microsoft

    App-V/MED-V/SCVMM/Server App-V/MDOP/AppCompat

    http://blogs.technet.com/gladiatormsft/
    The App-V Team blog: http://blogs.technet.com/appv/
    The MED-V Team Blog: http://blogs.technet.com/medv
    The SCVMM Team blog: http://blogs.technet.com/scvmm/

    “This posting is provided "AS IS" with no warranties, and confers no rights. User assumes all risks.”

    Saturday, February 20, 2016 4:59 AM

All replies

  • Anything relevant in the App-V Eventlog?

    Have you applied the Hotfix 1 (KB3115834)? The release notes of the HF1 don't talk about your Problem, but it's worth a try.


    Simon Dettling | msitproblog.com | @SimonDettling

    Wednesday, January 20, 2016 6:35 AM
    Moderator
  • Hi,

    Besides information within the event log is there a point where the memory in use will go down?

    Regards,

    Ryan

    Wednesday, January 20, 2016 10:49 AM
  • I'll give the Hotfix a try but according to some of my staff this was an issue with App-V 5.0 as well (why didn't you tell me!)

    There's nothing in the event log related to an app-v memory problem. The memory usage really never goes down. It just keeps going up and it seems to get higher, the more people that use a computer. Maybe its setting aside a chunk for every user and not releasing it when they log off?

    Wednesday, January 20, 2016 4:48 PM
  • What I would do to troubleshoot this issue:

    Get a machine that has no packages assigned.  Slowly add in the packages, rebooting between each.  My guess is that you have one or two packages that are causing this issue.  Isolate the problem package and troubleshoot.  You might want to re-package the problem package using the 5.1 sequencer.

    Wednesday, January 20, 2016 6:36 PM
    Moderator
  • I've noticed this 'problem' seems to be related to AppV 'caching' and RegistryStaging.  A stop and start of the appv service (net stop AppVClient && net start AppVClient') frees up all the memory but any heavy programs then start or operate super slow until they get cached again.

    I have this documented in my blog here:

    http://trentent.blogspot.ca/2014/11/appv-5-first-launch-application.html

    You can see this in action here in this GIF:

    Memory start at 11MB and as it's 'loading' the package gets as high as 600MB before settling around 350-380MB for this single application.

    I think this is expected behavior.


    • Edited by TrententMVP Wednesday, January 20, 2016 10:13 PM
    Wednesday, January 20, 2016 10:13 PM
  • Well, the Hotfix fixed some issues we had with a couple of applications, but not the memory usage. 

    I logged into a computer this morning and the memory usage was already over 1GB. It had rebooted earlier this morning and I was the first to login so no applications had been run yet. 

    When I get some time, I'll do what CodyLamber suggests. Though, I'm expecting it to be due to how complex and/or large engineering applications are. Some of them make Epic look simple in comparison.

    Thursday, January 21, 2016 5:52 PM
  • If possible, I would pre-stage those apps that have large registries etc using a script to see if that helps.
    Thursday, January 21, 2016 5:55 PM
    Moderator
  • We are experiencing the same issue (or 'feature' if it's by design..). We want to add a large amount of packages on server boot. After adding the packages the AppVClient.exe process easily takes >500MB of memory but never releases it.

    As I read up on this topic I still don't understand what is causing this. Caching and registry staging are possible named causes. However, we are using shared content store mode, so from the moment all sparse files are created it should release back it's memory again? Same as with registry staging.. I have background registry staging still enabled (default), so this happens on logon. Now from the moment all the registry items are set the appvclient process should release it's memory back again? What am I missing here?

    Is stopping and starting the appvclient after we added the packages a good workaround -or- does it affect the startup of big applications heavily as Trentent mentioned. How long should I wait to restart the appvclient after the packages are added.

    BTW: App-V 5.0 SP3 Client, so not new to 5.1

    • Edited by .dBase Monday, February 1, 2016 5:12 PM added version
    Monday, February 1, 2016 5:10 PM
  • I can also confirm that this seems to be normal behaviour.

    I've seen this very quickly happen on shared platforms (RDS) since adopting App-V 5.0 - though the earliest version I've seen deployed in a production environment was  SP2, so not sure if the behaviour was around before then.

    Regular cycling of the services / instances isn't unheard of.

    Also running in SCS mode, so full caching of packages to disk isn't needed, but I guess it still goes through the package to confirm all the stub files are expanded and vReg available...

    A process monitor shortly after restarting the service would reveal what it's doing, if scouring through (Debug) Event Logs isn't appealing / doesn't reveal much.

    I would be interested to see if there's a correlation between the held memory and packages that use local system interaction (named/COM); though I'm sure there will be someone who knows that side of it in much more detail to either confirm/deny that as a plausable avenue of investigation.

    • Edited by Sizzl Tuesday, February 2, 2016 1:46 PM
    Tuesday, February 2, 2016 1:18 PM
  • None of my packages have COM or named objects enabled and I have the same issue. So I think it's not related.
    Tuesday, February 2, 2016 4:52 PM
  • I wouldn't stop/restart the service ever.  The caching of memory does provide a performance benefit and when the application is relaunched it will consume RAM just as before.  I just did an extreme test and the AppVClient.exe will relinquish memory when under memory pressure.  So I'm not sure that this is really an issue as unused memory serves no benefit whatsoever.

    Video of memory being relinquished.

    Tuesday, February 2, 2016 5:45 PM
  • Just so I am clear, is SCS mode on or off? If it is on - this is indeed normal behavior.

    Steve Thomas, Senior Consultant, Microsoft

    App-V/MED-V/SCVMM/Server App-V/MDOP/AppCompat

    http://blogs.technet.com/gladiatormsft/
    The App-V Team blog: http://blogs.technet.com/appv/
    The MED-V Team Blog: http://blogs.technet.com/medv
    The SCVMM Team blog: http://blogs.technet.com/scvmm/

    “This posting is provided "AS IS" with no warranties, and confers no rights. User assumes all risks.”

    Monday, February 15, 2016 3:55 PM
  • It's off. 
    Monday, February 15, 2016 7:09 PM
  • This memory usage is getting ridiculous. I installed HF2 on a machine this morning and after a reboot and a sync the AppVClient.exe is already using more than 4GB of memory 
    Friday, February 19, 2016 4:39 PM
  • Open up a case with MS Support and have them take a WPR trace.


    Steve Thomas, Senior Consultant, Microsoft

    App-V/MED-V/SCVMM/Server App-V/MDOP/AppCompat

    http://blogs.technet.com/gladiatormsft/
    The App-V Team blog: http://blogs.technet.com/appv/
    The MED-V Team Blog: http://blogs.technet.com/medv
    The SCVMM Team blog: http://blogs.technet.com/scvmm/

    “This posting is provided "AS IS" with no warranties, and confers no rights. User assumes all risks.”

    Saturday, February 20, 2016 4:59 AM
  • Did you get to the bottom of your issues with high memory usage?

    We're seeing similar behaviour, and would be very interested to share experiences.

    Friday, September 23, 2016 12:41 PM
  • I posted this earlier but it seems to be missed:

    I wouldn't stop/restart the service ever.  The caching of memory does provide a performance benefit and when the application is relaunched it will consume RAM just as before.  I just did an extreme test and the AppVClient.exe will relinquish memory when under memory pressure.  So I'm not sure that this is really an issue as unused memory serves no benefit whatsoever.

    Video of memory being relinquished.

    However, if you own Citrix Platinum licenses, they released a product called Workspace Environment Manager (WEM) that you can put AppVClient.exe in their 'memory reduce' feature which will essentially do the same thing as applying memory pressure forcing the .exe to relinquish the memory.

    I would be careful though.  There maybe a performance impact forcing the appvclient.exe to relinquish memory it has cached.

    • Edited by TrententMVP Wednesday, December 7, 2016 4:00 PM offered solution
    Wednesday, December 7, 2016 3:56 PM
  • Hi,

    Try installing the latest Hotfix/Patches on the machine.

    Below is the link from where you can download the Hotfix 5 and Hotfix 6.

    But, make sure both HF05 and HF06 are installed as HF06 is not cumulative and doesn't contain HF05.

    Hotfix 5

    Hotfix 6

    Thursday, December 8, 2016 2:52 PM