This message was deleted.
# citrix-vad
s
This message was deleted.
👍🏼 1
👍 2
🤔 1
s
I didnt face any such issue yet with WS2019 VDA 2203 LTSR
j
Thank you for posting this. We just upgraded our app layered image for 2019 hosted shared desktops with 2203 LTSR VDA. Let's see if we find something similar. I think we will know more sometime early next week since we don't have a ton of usage in Dev, but I guess if it's a memory leak we should see it sooner...will check either way
d
It continues in our environment. Granted only deployed to two production servers that are identical. Not sure that I can deploy to more until we figure out what's going on here. Citrix hasn't responded to the ticket yet.
Installed on a fresh build and seeing the same symptom, but smaller amount of memory used per new session compared to the previous systems. Still waiting on Citrix to provide any useful followup.
j
How much memory per session on average were and are you seeing?
d
Testing on quiet servers with no other users logged in: Original server build around .5 to .8 MB per login session New fresh build server around .1 to .2 MB per login session
j
RAM usage?
Oh on that process...nvm lol
I thought per user hahaha
d
🙂 Leaking that much per session on svchost for TermServ.
j
Well on that note how much memory does your typical user session use? And what's your user density and vm sizing?
d
In that one process, which is all I am focused on at the moment, it uses a bit more while the user is logged in, but not a great deal more probably 1 to 1.5 MB per session. Not sure what user density and vm sizing have to do with this particular issue. The servers are sized appropriately when memory isn't being leaked away.
The svchost.exe process for TermService should not use 10.23 GB of memory. This is after just 2 days since a restart. What is special about my environment? This started when 2203 was installed on the servers.
j
I was just curious. For learning purposes. I know it's not related.
d
As an MSP, for us, the answer is almost always, it depends. We do sizing per client, but generally limit user load to 20 per machine and CPU and Memory are somewhat application dependent. There is a formula that is used, but I don't do that portion of things. We adjust as needed based on real world performance as needed.
Found the culprit. <<username>> tried to open custom virtual channel CUEPUX This is the ControlUp custom virtual channel. I knew that virtual channels were going to be blocked by default in 2203, but hadn't put in the policy to allow them as I was hoping to test an only allow as I found them and may get back to that, but for now they are all open again.
❤️ 2
s
I have also observed this same msg in System Event Logs for other virtual channel.. CTXMM and CTXCAM