Citrix Blogs

Citrix Director: CPU, Memory Usage and Process Information

How often do you find a user who has a session freeze because a process is consuming too much CPU power, and there is no way to troubleshoot the problem easily? If only you could review CPU usage trends from the last month, you could plan better for the new delivery groups that you’re provisioning.

With XenApp and XenDesktop 7.11, you can get insight into the CPU and memory usage on your apps and desktops, enabling you to better prepare for CPU and memory consumption.

Machine-based CPU and Memory Usage

We’ve added a View Historical Utilization button in the Machine Utilization Panel.

This will open a new page, Historical Machine Utilization for the machine. Here, you will find the historical usage of CPU, Memory and Peak concurrent session count on the specific machine.

Time ranges can be selected to view the historical resource Utilization. We support 2 hours, 24 hours, 7 days, 1 month and 1 year periods.

 

Three graphs show the historical trend of each parameter – CPU, Memory and Session Count.

  1. CPU graph: CPU graph shows the average CPU trend over the selected time and the baseline.
  2. Memory graph: Memory graph shows the average memory trend over the selected time and the baseline.
  3. Session graph: Session graph shows peak concurrent session count trend over the selected time and the baseline.

In the below screen capture, “Last 2 hours” was selected. Hence the baseline period will be the 2 hours prior to the selected time range. The CPU, Memory and Session trend over the last 2 hours and the baseline time can be seen in 3 graphs. On hovering, the tooltip provides additional information.

Process Information

In the historical resource utilization page, process information is added in addition to the resource data. The table lists top 10 processes based on CPU or Memory. It also provides information about the process such as Application Name, User Name, Session ID, CPU average, and Peak and Memory Average and Peak over the selected time range.

Note: Session ID is shown as 0000’s for the system processes.

The below table shows the top 10 processes based on memory peak. And clicking on a process gives the historical trend on the resource consumption of that particular process. The chart below shows the resource utilization trend for BrokerAgent.exe

Historical CPU and Memory Utilization Trend

There is a new tab introduced under Trends page called Resource Utilization. Here you can get the trends based on the usage of CPU, Memory and Peak concurrent sessions for a selected time period.

Similar to other Trends tabs, filters are supported. You can set a filter for Delivery Group and Time Period.

Delivery Group Filter: You can select either a specific Delivery Group or all Delivery Groups.

Time Period Filter: We support 2 hour, 24 hour, 7 day, 1 month and 1 year ranges.

The Resource Utilization trend chart contain 3 graphs. All 3 graphs provide a baseline analysis.

  1. CPU graph: CPU graph shows the average CPU consumption for regular intervals over selected time and baseline for all the delivery groups or specific delivery group.
  2. Memory graph: Memory graph shows the average memory for regular intervals over selected time and baseline for all the delivery groups or specific delivery group.
  3. Session graph: Session graph shows peak concurrent session count for regular intervals over selected time and baseline for all the delivery groups or specific delivery group.

The tooltip provides the summary of all the above graphs for a specific time.

The table below the chart provides the resource utilization details per machine. The table provides the information such as Peak concurrent Session Count, CPU average, CPU Peak, Memory Average, Memory Peak. The table can be sorted according to any of these parameters.

In addition to the above said parameters you can even see the existing notification count per machine. Note, this is available only for RDS machines.

As per other trends, the zooming feature is provided for all charts and the reports can be exported as well.

Group Policy

Group Policies are a collection of settings that define how sessions, bandwidth, and security are managed for a group of users, devices, or connection types. Group Policies can be easily configured in Citrix Studio.

A new section of Monitoring is introduced, which has 2 policies:

  1. Enable Process Monitoring (default = disabled) :  The process data is disabled by default. Please enable this policy to get the process information in Historical Machine Details page.
  1. Enable Resource Monitoring (default =enabled) : The CPU and memory utilization data is enabled by default.

Both the policies can be changed based on the requirement.

The scope for these policies can be defined based on the Site, Delivery Group, Type of Delivery Group, Organizational Unit, Tags, etc.

Each data point regarding the CPU, Memory and Processes are collected from the VDA and stored on the Monitoring Database. If you are not interested in monitoring either resource data or process data or both for a specific scope (specific delivery group, Organizational unit, etc.), it is recommended to disable the appropriate policy.For example, if Resource Monitoring policy is disabled on the Delivery Group, the resource data points will not be collected from any of the VDAs in the Delivery Group.

Scalability

We have improved on the storage consumption for Resource Utilization data in this release. Now, the CPU, memory data is pushed to the DB at 5-minute interval and process data (if enabled) is pushed to the database at 10-minute intervals.

The following table gives the default configuration for the data retention.

CPU and Memory data

Data granularity Number of Days
5 Minute Data 1 Day
10 Minute Data 7 Days
Hourly Data 30 Days
Daily Data 90 Days

With the above data retention settings, approximately 260 KB space is needed to store the CPU and memory data for one VDA over a period of one year.

Number of machines The approximate storage required
1 260 KB
1K 253 MB
40K 10 GB

Process Data

Process data is not enabled by default. It is recommended to enable process data on subset of machines on need basis. The default data retention settings for the process data is as follows:

Data granularity Number of Days
10 minute Data 1 Day
Hourly Data 7 Days

If process data is enabled, with the default retention settings, process data would consume ~1.5MB per VDA and 3MB per TSVDA over a period of one year.

Number of machines Approximate storage required
VDA TSVDA
1 1.5 MB 3 MB
1K 1.5 GB 3 GB

Optional Configurations:

The default retention settings can be altered according to the need. But this would consume extra storage. By enabling the below settings there would be more accuracy in the Process Utilization data. The configurations which can be enabled are:

EnableMinuteLevelGranularityProcessUtilizationks

EnableDayLevelGranularityProcessUtilization

These Configurations can be enabled from the Monitoring Powershell cmdlet: Set-MonitorConfiguration

*Please note the above numbers do not include the Index space. And all the above calculations are approximations and may vary depending on the deployment.

The following pointers might help you in planning the storage better:

  1. Group policy: If you are not interested in monitoring the Resource Data or Process Data, either or both can be turned off using the group policy. Refer to the Group Policy Section of this document for more details.
  2. Data grooming: The default data retention settings can be modified to groom the data early and free the storage. Learn more about the grooming settings.

Notifications

With 7.11 XenApp and XenDesktop , you can now configure alerts and get notified when the CPU or Memory values reaches beyond the designated threshold. For more details please refer to the blog post on the Proactive Notifications and Alerting improvements.

With this feature, you will be able to get an insight into the CPU, memory consumption and processes running on your XenApp and XenDesktop deployment. You can even get an overview on the historical resource consumption which helps in planning future deployments.

Exit mobile version