ControlUp captures metadata of community members. This leads to innovation like allowing customers to compare their logon times vs the wider community. I reached out to the ControlUp Research team and asked a question that I had been thinking about. What percentage of users are idle or in a disconnected state over the course of a day? What I found was shocking.
Out of 6 million terminal services sessions, an average of 41% were in an idle or disconnected state. If we focus purely on the busiest time (9AM-3PM) we see an average of 34% of all sessions are in an inactive state .
34%! Think for a moment on the server resources being consumed by a third of users who are not doing any active work. That’s a whole lot of nothing!
Let’s look at the data:
Definitions:
Active – Users whom sessions have an idle time of less than 10 minutes
Disconnected – Users whom have a session state of disconnected
Idle – Users whom sessions have an idle time of more than 10 minutes
This is shocking stuff.
These idle/disconnected sessions are consuming resources at the same level as your employees who are actively working. Their processes get their turn in the CPU scheduler the same as any other, even though they are just sitting there. Memory is being consumed by their idle processes, causing less free RAM on your servers — or even worse — memory contention.
Of course, admins may have set their users up with long idle or disconnect times and this information is over a full 24 hour period. Focusing on the highest usage window, I looked at the period where idle and disconnected sessions would be the lowest. This would show us the amount of wasted resources when they are needed the most.
The highest percentage of active sessions — that is the most amount of sessions where someone is actively working — is 70%. A minimum of 30% of resources across 6 million sessions is wasted by users who are not doing any active work.
Users who are idle or in a disconnected state may not consume much CPU time as their processes are (typically) in a state of waiting for an event. However, some applications may poll for activity, consuming resources. In most cases, the CPU load is quite low. But, reducing the opportunity for these apps to consume CPU resources would be a big win in any environment and we can do exactly that with ControlUp Automation. But CPU isn’t the only big consumer of resources. There is a bigger consumer and it generates much more waste-memory.
Memory maybe cheaper than ever but this comes with tradeoffs in software. Applications and operating systems are consuming copious amounts of memory; more now than ever before. New frameworks promote lazy memory management, with said management now being handled by the frameworks. Generally, this is not an issue when running your application on a full fledged desktop computer where the resources are dedicated and plentiful. Using 1, 2 or 4GB of RAM for an application in this scenario is common. But, as soon as you start moving these applications to servers that have to share resources amongst multiple users your ability to optimize these resources effectively becomes critical. An idle application consuming 4GB of memory is a large amount of wasted resources. Freeing up that memory, especially in times of contention, can reduce demand paging for the active users.
Wouldn’t it be grand if we could put more priority on users who are actually active and working? With ControlUp Automation, this is easily done.
ControlUp’s trigger system activates on changes. This is an incredibly powerful system.
We can tell ControlUp to lower the CPU priority and trim the memory of processes when the user is idle or in a disconnected state. By reducing these properties with triggers we can free up resources for the real, productive users.
When a user moves from Idle to Active or Disconnected to Active the resource optimization can work in the reverse. CPU priorities will be restored to previous values or set to the default “Normal”. Any memory trimmed will be recalled as the program requests it and brought back into the working set.
The design of the script action and trigger is detailed here but this resource optimization is fully enabled by checking 4 boxes within the Triggers window.
We HIGHLY recommended that you edit the triggers after enabling them and set the scope to only encompass your multi-session servers.