Understanding Workspace Environment Management (WEM) System Optimization

The WEM System Optimization feature is a group of settings designed to dramatically lower resource usage on a VDA on which the WEM Agent is installed.

These are machine-based settings that will apply to all user sessions.




Managing Servers with different Hardware Configurations

Sets of VMs may have been configured with different hardware configurations. For instance some machine may have 4 CPU cores and 8GB RAM, while others have 2 CPU Cores and 4GB RAM. The determination could be made such that each server set requires a different set of WEM System Optimization settings. Because machines can only be part of one WEM ConfigSet, administrators must consider whether they need to create multiple ConfigSets to accommodate different optimization profiles.


WEM System Optimization Settings

User-added image


Fast Logoff

A purely visual option that will end the HDX connection to a remote session, giving the impression that the session has immediately closed. However, the session itself continues to progress through the session logoff phases on the VDA.


CPU Management

CPU Priority:

You can statically define the priority for a process. Every instance of, for example, Notepad that is launched on the VDA will be launched with a priority of the desired CPU priority. The choices are:

  • Idle
  • Below Normal
  • Normal
  • Above Normal
  • High
  • Realtime *

* https://stackoverflow.com/questions/1663993/what-is-the-realtime-process-priority-setting-for

CPU Affinity:

You can statically define how many CPU cores a process will use. Every instance of Notepad that is launched on the VDA will use the number of cores defined.

Process Clamping:

Process clamping allows you to prevent a process from using more CPU percentage than the specified value. A process in the Process Clamping list can use CPU up to the configured percentage, but will not go higher. The setting limits the CPU percentage no matter which CPU cores the process uses.

Note: The clamping percentage is global, not per core (that is, 10% on a quad-core CPU is 10%, not 10% of one core).


Generally, Process Clamping is not a recommended solution for keeping the CPU usage of a troublesome process artificially low. It’s a brute force approach and computationally expensive. The better solution is to use a combination of CPU spikes protection and to assign static Limit CPU / Core Usage, CPU priorities, CPU affinities values to such processes.

CPU Management Settings:

CPU Spikes Protection:

CPU Spikes Protection is not the same as Process Clamping. Process Clamping will prevent a process from exceeding a set CPU percentage usage value. Spikes Protection manages the process when it exceeds the CPU Usage Limit (%) value.

CPU Spikes Protection is not designed to reduce overall CPU usage. CPU Spikes Protection is designed to reduce the impact on user experience by processes that consume an excessive percentage of CPU Usage.

If a process exceeds the CPU Usage Limit (%) value, for over a set period of time (defined by the Limit Sample Time (s) value), the process will be relegated to Low Priority for a set period of time, defined by the Idle Priority Time (s) value. The CPU usage Limit (%) value is global across all logical processors.

The total number of logical processors is determined by the number of CPUs, the number of cores in the CPU, and whether HyperThreading is enabled. The easiest method of determining the total number of logical cores in a machine is by using Windows Task Manager (2 logical processors shown in the image):

User-added image

To better understand CPU Spikes Protection, let’s follow a practical scenario:

Users commonly work with a web app that uses Internet Explorer. An administrator has noticed that iexplore.exe processes on the VDAs consume a lot of CPU time and overall responsiveness in user sessions is suffering. There are many other user processes running and percentage CPU usage is running in the 90 percent range.

To improve responsiveness, the administrator sets the CPU Usage Limit value to 50% and a Idle Priority Time of 180 seconds. For any given user session, when a single iexplore.exe process instance reaches 50% CPU usage, it’s CPU priority is immediately lowered to Low for 180 seconds. During this time iexplore.exe will consequently get less CPU time due to its low position in the CPU queue and thereby reduce its impact on overall session responsiveness. Other user processes that haven’t also reached 50% have a higher CPU priority and so continue to consume CPU time and although the overall percentage CPU usage continues to show above 90%, the session responsiveness for that user is greatly improved.

In this scenario, the machine has 4 logical processors. If the processes’ CPU usage is spread equally across all logical processors, each will show 12.5% usage for that process instance.

If there are two iexplore.exe process instances in a session, their respective percentage CPU usage values are not added to trigger Spikes Protection. Spikes Protection settings apply on each individual process instance.​

User-centric CPU Optimization (process tracking on the WEM Agent):

As stated previously, all WEM System Optimization settings are machine-based and settings configured for a particular ConfigSet will apply to all users launching sessions from the VDA.

The WEM Agent records the history of every process on the machine that has triggered Spikes Protection. It records the number of times that the process has triggered Spikes Protection, and it records the user for which the trigger occurred.

So if a process triggers the CPU Spikes Protection in User A’s session, the event is recorded for User A only. If User B starts the same process, then WEM Process Optimization behavior is determined only by process triggers in User B’s session. On each VDA the Spike Protection triggers for each user (by user SID) are stored in the local database on the VDA and refreshing the cache does not interfere with this stored history.

Limit CPU / Core Usage:

When a process has exceeded the CPU Usage Limit value (i.e. Spikes Protection for the process has been triggered), in addition to setting the CPU priority to Low, WEM can also limit the amount of CPU cores that the process uses if a CPU / Core Usage Limit value is set. The limit is in effect for the duration of the Idle Priority Time.

Enable Intelligent CPU Optimization:

When Enable Intelligent CPU Optimization is enabled, all processes that the user launches in their session will start at a CPU Priority of High. This makes sense as the user has purposefully launched the process, so we want the process to be reactive.

If a process triggers Spikes Protection, it will be relegated to Low priority for 180 seconds (if default setting is used). But, if it triggers Spikes Protection a certain number of times, the process will run at the next lowest CPU Priority the next time it’s launched.

So it was launching at High priority initially; once the process exceed a certain number of triggers, it will launch at Above Normal priority the next time. If the process continues to trigger Spikes Protection, it will launch at the next lowest priority until eventually it will launch at the lowest CPU priority.

The behavior of Enable Intelligent CPU Optimization is overridden if a static CPU Priority value has been set for a process. If Enable Intelligent CPU Optimization is enabled and a process’s CPU Priority value has been set to Below Normal, then the process will launch at Below Normal CPU priority instead of the default High priority.

If Enable Intelligent CPU Optimization is enabled and a process’s CPU Priority value has been statically set to High, then the process will launch at High. If the process triggers Spikes Protection, it will be relegated to Low priority for 180 seconds (if default setting is used), but then return to High priority afterwards.

Note: The Enable CPU Spikes Protection box must be ticked for Enable Intelligent CPU Optimization to work.


Memory Management

Working Set Optimization:

WEM determines how much RAM a running process is currently using and also determines the least amount of RAM the process requires, without losing stability. The difference between the two values is considered by WEM to be excess RAM. The process’s RAM usage is calculated over time, the duration of which is configured using the Idle Sample Time (min) WEM setting. The default value is 120 minutes.

Let’s look at a typical scenario when WEM Memory Management has been enabled:

A user opens Internet Explorer, navigates to YouTube, and plays some videos. Internet Explorer will use as much RAM as it needs. In the background, and over the sampling period, WEM determines the amount of RAM Internet Explorer has used and also determines the least amount of RAM required, without losing stability.

Then the user is finished with Internet Explorer and minimizes it to the Task Bar. When the process percentage CPU usage drops to the value set by the Idle State Limit (percentage) value (default is 1%), WEM then forces the process to release the excess RAM (as previously calculated). The RAM is released by writing it to the pagefile.

When the user restores Internet Explorer from the Task Bar, it will initially run in its optimized state but can still go on to consume additional RAM as needed.

When considering how this affects multiple processes over multiple user sessions, the result is that all of that RAM freed up is available for other processes and will increase user density by supporting a greater amount of users on the same server.

Idle State Limit (percent):

The value set here is the percentage of CPU usage under which a process is considered to be idle. The default is 1% CPU usage. Remember that when a process is considered to be idle, WEM forces it to shed its excess RAM. So be careful not to set this value too high; otherwise a process being actively used may be mistaken as an idle process, resulting in its memory being released. It is not advised to set this value higher than 5%.


I/O Management

These settings allow you to optimize the I/O priority of specific processes, so that processes which are contending for disk and network I/O access do not cause performance bottlenecks. For example, you can use I/O Management settings to throttle back a disk-bandwidth-hungry application.

The process priority you set here establishes the “base priority” for all of the threads in the process. The actual, or “current,” priority of a thread may be higher (but is never lower than the base). In general, Windows give access to threads of higher priority before threads of lower priority.

I/O Priority Settings:

Enable Process I/O Priority

When selected, this option enables manual setting of process I/O priority. Process I/O priorities you set take effect when the agent receives the new settings and the process is next restarted.

Add Process I/O Priority

Process Name: The process executable name without the extension. For example, for Windows Explorer (explorer.exe) type “explorer”.

I/O Priority: The “base” priority of all threads in the process. The higher the I/O priority of a process, the sooner its threads get I/O access. Choose from High, Normal, Low, Very Low.

Enable Intelligent I/O Optimization:

This adopts exactly the same principles as Enable Intelligent CPU Optimization, but for I/O instead of CPU.

Note: The Enable CPU Spikes Protection box must be ticked for Enable Intelligent I/O Optimization to work.


Exclude specified processes:

By default, WEM CPU Management excludes all of the most common Citrix and Windows core service processes. This is because they make the environment run and they need to make their own decisions about how much CPU time & priority they need. WEM administrators can however, add processes they want to exclude from Spikes Protection to the list. Typically, antivirus processes would be excluded. In this case, in order to stop antivirus scanning taking over disk I/O in the session, administrators would also set a static I/O Priority of Low for antivirus processes.


Notes:

  1. When configuring, the entered process name is a match to the process name’s entry in Windows Task Manager.
  2. Process names are not case-sensitive.
  3. You don’t enter “.exe” after the process name. So for instance, enter “notepad” rather than “notepad.exe”.

Related:

Balanced Memory is Best: 2nd Generation AMD EPYC Processors for PowerEdge Servers

Understanding the relationship between a server processor (CPU) and its memory subsystem is critical when optimizing overall server performance. Every CPU generation has unique memory population guidelines that must be satisfied to attain the best memory performance. 2nd Generation AMD EPYCTM server processors can support up to sixteen memory modules across eight channels with two memory slots. This presents numerous possible ways of configuring the memory subsystem, yet there are only a couple of configurations that will achieve the peak memory performance for Dell EMC PowerEdge servers. Memory that has been incorrectly populated is referred to … READ MORE

Related:

Hardware requiremnet for Bluecoat Proxy SG500-10

I do not need a solution (just sharing information)

Hardware requiremnet for Bluecoat Proxy VA100

Hello,

I would like to know about hardware requirement for Bluecoat Proxy SG500-10 detail below this.

CPU
Memmory

Diskspace

Actually, I already searched in Datasheet but, I didn’t find CPU specification on Data sheet.

Cloud you please support in this portion ?

If possible maybe have some doucument for refference.

0

Related:

  • No Related Posts

Citrix ADC System Counters

This article contains information about the newnslog system counters and their brief description.

Using newnslog Counter

To use the newnslog counter, log on to the ADC using an SSH client, switch to SHELL, navigate to the /var/nslog directory, and then use the ‘nsconmsg’ command to see comprehensive statistics. For more information refer to Citrix Blog – NetScaler ‘Counters’ Grab-Bag!

Citrix ADC System Counters

The following table lists the newnslog System counters with a simple description of the counter.

newnslog Counter

Description

allnic_tot_rx_mbits This counter tracks the number of megabytes received by the NetScaler appliance.
allnic_tot_tx_mbits This counter tracks the number of megabytes transmitted by the NetScaler appliance.
avg_cpu_usage This counter tracks the average CPU utilization percentage.
avg_cpu_usage_pcnt This counter tracks the average CPU utilization percentage.
cc_cpu_use This counter tracks the CPU utilization percentage.
cpu_speed_expected This counter tracks the CPU speed in MHz.
cpu_usage This counter tracks the CPU utilization percentage.
cpu_usage_pcnt This counter tracks the CPU utilization percentage.
cpu_usage_snmp This counter tracks the CPU utilization percentage.
cpu_use This counter tracks the CPU utilization: percentage * 10.
cur_moninfo This counter tracks the number of monitor bindings defined on this NetScaler appliance.
cur_monitor This counter tracks the number of monitors defined on this NetScaler appliance.
cur_server This counter tracks the number of servers defined on this NetScaler appliance.
cur_service This counter tracks the number of services defined on this NetScaler appliance.
cur_servinfo This counter tracks the number of virtual server bindings on this NetScaler appliance.
cur_svcgroup This counter tracks the number of service groups defined on this NetScaler appliance.
cur_svcgroup_svcitem This counter tracks the number of service group members defined on this NetScaler appliance.
cur_svcgroup_vsrvitem This counter tracks the number of virtual server, service group bindings on this NetScaler appliance.
cur_syshealth_disk0_avail This counter tracks the available space in /flash partition of the hard disk.
cur_syshealth_disk0_errors This counter tracks the disk (/flash) Error counter.
cur_syshealth_disk0_pusage This counter tracks the cur_syshealth_disk0_errors.
cur_syshealth_disk0_size This counter tracks the size of /flash partition of the hard disk.
cur_syshealth_disk0_used This counter tracks the used space in /flash partition of the hard disk.
cur_syshealth_disk1_avail This counter tracks the available space in /var partition of the hard disk.
cur_syshealth_disk1_errors This counter tracks the number of errors on the /var partition of the hard disk.
cur_syshealth_disk1_pusage This counter tracks the used space in /var partition of the disk, as a percentage. This is a critical counter.

You can configure /var Used percentage by using the Set snmp alarm DISK-USAGE-HIGH command.
cur_syshealth_disk1_size This counter tracks the size of /var partition of the hard disk.
cur_syshealth_disk1_used This counter tracks the used space in /var partition of the hard disk.
cur_syshealth_fan0 This counter tracks the system fan speed. Acceptable range is 3000 to 6000 RPM. This is a critical counter.

You can configure System Fan Speed by using the Set snmp alarm FAN-SPEED-LOW command to set the lower limit.
cur_syshealth_fan1 This counter tracks the system fan 1 speed. For new platforms, associated pin is connected to CPU supporting fans. For platforms in which it is not connected, it points to System Fan.
cur_syshealth_fan2 This counter tracks the system fan 2 speed. For new platforms, associated pin is connected to CPU supporting fans. For platforms in which it is not connected, it points to System Fan
cur_syshealth_fan3 This counter tracks the speed of Fan 0 if associated pin is connected to health monitoring chip.
cur_syshealth_fan4 This counter tracks the speed of Fan 1 if associated pin is connected to health monitoring chip.
cur_syshealth_fan5 This counter tracks the speed of Fan 2 if associated pin is connected to health monitoring chip.
cur_syshealth_fan6 This counter tracks the speed of Fan 3 if associated pin is connected to health monitoring chip.
cur_syshealth_fancpu0 This counter tracks the CPU Fan 0 speed. Acceptable range is 3000 to 6000 RPM. This is a critical counter.

You can configure CPU Fan 0 Speed by using the Set snmp alarm FAN-SPEED-LOW command to set the lower limit.
cur_syshealth_fancpu1 This counter tracks the CPU Fan 1 speed. Acceptable range is 3000 to 6000 RPM. 7000 platform displays speed of CPU fan 0. This is a critical counter.

You can configure CPU Fan 1 Speed by using the Set snmp alarm FAN-SPEED-LOW command to set the lower limit.
cur_syshealth_misc0 Miscellaneous Counter 0.
cur_syshealth_misc1 Miscellaneous Counter 1.
cur_syshealth_ps1fail This counter tracks the power supply 1 failure status. Values: 0=Not Supported; 1=Not Present; 2=Power Supply Failed; 3=Power Supply OK
cur_syshealth_ps2fail This counter tracks the power supply 2 failure status. Values: 0=Not Supported; 1=Not Present; 2=Power Supply Failed; 3=Power Supply OK
cur_syshealth_ps3fail This counter tracks the power supply 3 failure status. Values: 0=Not Supported; 1=Not Present; 2=Power Supply Failed; 3=Power Supply OK
cur_syshealth_ps4fail This counter tracks the power supply 4 failure status. Values: 0=Not Supported; 1=Not Present; 2=Power Supply Failed; 3=Power Supply OK
cur_syshealth_tcpu0 This counter tracks the CPU 0 temperature. NetScaler 9800 and 9960 platforms display internal chip temperature. This is a critical counter.

You can configure CPU 0 Temperature by using the Set snmp alarm TEMPERATURE-HIGH command to set the upper limit.
cur_syshealth_tcpu1 This counter tracks the CPU 1 temperature. NetScaler 9800 and 9960 platforms display internal chip temperature. NetScaler 7000, 9010 and 10010 platforms display CPU 0 temperature. This is a critical counter.

You can configure CPU 1 Temperature by using the Set snmp alarm TEMPERATURE-HIGH command to set the upper limit.
cur_syshealth_temp0 This counter tracks the temperature of a device connected to health monitoring chip through pin 0.
cur_syshealth_temp1 This counter tracks the temperature of a device connected to health monitoring chip through pin 1.
cur_syshealth_temp2 This counter tracks the temperature of a device connected to health monitoring chip through pin 2.
cur_syshealth_temp3 This counter tracks the temperature of a device connected to health monitoring chip through pin 3.
cur_syshealth_tint This counter tracks the internal temperature of health monitoring chip. This is a critical counter.

You can configure Internal Temperature by using the Set snmp alarm TEMPERATURE-HIGH command to set the upper limit.
cur_syshealth_v12n This counter tracks the power supply -12V output. Acceptable range is -13.20 to -10.80 volts. NetScaler 9800 and 9960 platforms display standard value of -12.0V.
cur_syshealth_v12p This counter tracks the power supply +12V output. Acceptable range is 10.80 to 13.20 volts.
cur_syshealth_v33main You can configure Standby 3.3V Supply Voltage by using the Set snmp alarm VOLTAGE-LOW command to set the lower limit and the Set snmp alarm VOLTAGE-HIGH command to set the upper limit.
cur_syshealth_v33stby This counter tracks the standby power supply +3.3V output. Acceptable range is 2.970 to 3.630 volts. NetScaler 9800 and 9960 platforms display standard value of 3.3V.
cur_syshealth_v50n This counter tracks the power supply -5V output. Acceptable range is -5.50 to -4.50 volts. NetScaler 9800 and 9960 platforms display standard value of -5.0V.
cur_syshealth_v50p This counter tracks the power supply +5V output. Acceptable range is 4.50 through 5.50 volts.
cur_syshealth_v5sb This counter tracks the power Supply 5V Standby Voltage. Currently, only 13k Platforms have a valid value for this counter and for older platforms the value is 0.
cur_syshealth_vbat This counter tracks the onboard battery power supply output. NetScaler 9800 and 9950 platforms display standard value of 5.0V.
cur_syshealth_vcc0 This counter tracks the CPU core 0 voltage. Acceptable range is 1.080 to 1.650 volts.
cur_syshealth_vcc1 This counter tracks the CPU core 1 voltage. Acceptable range is 1.080 to 1.650 volts. If CPU 1 is not connected to the health monitoring chip, then display shows voltage of CPU 0.
cur_syshealth_volt0 This counter tracks the voltage of a device connected to health monitoring chip through pin 0.
cur_syshealth_volt1 This counter tracks the voltage of a device connected to health monitoring chip through pin 1.
cur_syshealth_volt2 This counter tracks the voltage of a device connected to health monitoring chip through pin 2.
cur_syshealth_volt3 This counter tracks the voltage of a device connected to health monitoring chip through pin 3.
cur_syshealth_volt4 This counter tracks the voltage of a device connected to health monitoring chip through pin 4.
cur_syshealth_volt5 This counter tracks the voltage of a device connected to health monitoring chip through pin 5.
cur_syshealth_volt6 This counter tracks the voltage of a device connected to health monitoring chip through pin 6.
cur_syshealth_volt7 This counter tracks the voltage of a device connected to health monitoring chip through pin 7.
cur_syshealth_vsen2 This counter tracks the voltage Sensor 2 Input. Currently, only 13k Platforms have a valid value for this counter and for older platforms the value is 0.
cur_syshealth_vtt This counter tracks the Intel CPU Vtt power. Currently, only 13k Platforms have a valid value for this counter and for older platforms the value is 0.
master_cpu_usage This counter tracks the CPU 0 (currently the master CPU) utilization, as percentage of capacity.
master_cpu_use This counter tracks the CPU0 utilization: percentage * 10.
mem_cur_feature_allocpercent This counter tracks the percentage of NetScaler appliance memory used by the feature.
mem_cur_feature_allocsize This counter tracks the total current NetScaler appliance memory available for use by the feature, in kilobytes.
mem_err_feature_alloc_failed This counter tracks the memory allocation failure for a particular feature.
mem_tot_allocated This counter tracks the currently allocated memory, in megabytes.
mem_tot_allocated_pcnt This counter tracks the currently allocated memory in percent.
mem_tot_MB This counter tracks the total Main memory available for use by packet engine (PE), in megabytes.
mem_tot_use_MB This counter tracks the total NetScaler Memory in use, in megabytes.
mem_usage_pcnt This counter tracks the percentage of memory utilization on NetScaler.
mem_usage_percent This counter tracks the percentage of memory utilization on a NetScaler appliance.
mem_use_MB This counter tracks the main memory currently in use, in megabytes.
mgmt_cpu_usage_pcnt This counter tracks the management CPU utilization percentage.
mgmt_cpu_use This counter tracks the management CPU utilization: percentage * 10.
ns_interval This counter tracks the interval in seconds between performance monitoring records taken on the NetScaler appliance.
ns_time This counter tracks the current time set on the NetScaler appliance.
packet_cpu_usage_pcnt This counter tracks the packet CPU utilization percentage.
per_cpu_usage This counter tracks the CPU utilization percentage.
shmem_cur_alloc_pcnt This counter tracks the shared memory in use percent.
shmem_cur_allocsize This counter tracks the shared memory in use, in megabytes.
shmem_max_allowed This counter tracks the total shared memory allowed to allocate, in megabytes.
slave_cpu_usage This counter tracks the CPU 1 (currently the slave CPU) utilization, as percentage of capacity. Not applicable for a single-CPU system.
slave_cpu_use This counter tracks the CPU1 utilization, percentage * 10.
sys_cpus This counter tracks the number of CPUs on the NetScaler appliance.
sys_cpus_1 This counter tracks the number of CPUs on the NetScaler appliance.
sys_cur_duration_sincestart This counter tracks the seconds after the NetScaler appliance started.
sys_memorysize_MB This counter tracks the total amount of system memory, in megabytes.
sys_starttime This counter tracks the time when the NetScaler appliance was last started.
sys_tot_config_changes This counter tracks the number of times a configuration change was made on the NetScaler appliance.
sys_tot_save_configs This counter tracks the number of times the system configuration was saved on the NetScaler appliance.

Related:

Apache HTTP Server (32 bit) service reports high cpu usage

I need a solution

Hello,

We are experiencing Apache HTTP Server (32 bit) service high cpu usage [75% approx] which raises the overall CPU utilization to 100% constantly after upgrading SEPM 14.2RU1  Version: 14.2.3332.1000 on Windows 2016 Servers Virtual Machines. However, the physical machines are working fine.

The Virtual Machines configuration is – Windows Server 2016 @2.00GHz  – 6 processors, 32GB RAM. The previous SEPM version 14.2MP1 didn’t have this issue.

Appreciate your thoughts.

Thank you.

0

Related:

SEP 14.x use over 30% CPU usage

I need a solution

We noticed Symantec Service Framework use more than 30% CPU usage. Is this normal?

Any reason it use a lot resources eventhough no scanning in progress ?

Hope the community can advise.

0

Related: