FAQ
Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform

English

Türkçe

English

Türkçe

Appearance

Advanced

What is QoS; how do I reserve dedicated CPU/memory resources for critical vServices? ​

Short answer

QOS is the vService setting that determines the memory limit to be allocated to the process in which the vService runs, the processor cores it will use, the processor priority and the processor usage limit. To allocate resources to a critical vService, vService → Details → QOS is checked; Memory Limit is selected, cores are checked with Manual in the Cores field, CPU Priority is set to High, and if needed, Cpu Usage Limit (%) is entered. While QOS is off, the vService runs with a 2 GB memory limit and automatic core assignment. QOS exists in HTTP and L7 TCP vServices; the change restarts the vService.

Problem: The Critical Service Shares Resources with Other Services ​

When many vServices run on the same device, a busy service can slow down critical services by consuming the processor and memory. Critical vServices are expected to be given dedicated cores, sufficient memory and priority, and unimportant services are expected to be limited.

Solution: Two Methods ​

Your situationSuitable method
Allocating resources to the critical vService from the interfaceMethod 1: QOS (web interface)
From the command lineMethod 2: WEB-CLI
  • How it works The vService runs on the allocated cores, with the defined memory limit and priority.
  • Where it is openedLoad Balancer → Load Balancer vService List → vService → Edit → Details → QOS
  • Requirement Full Load Balancer permission (otherwise the QOS box is disabled); a maintenance window, since saving restarts the vService
  • vService type HTTP · L7 TCP

Step-by-Step Configuration ​

1
Adım 1 Edit the vService

On the Load Balancer → Load Balancer vService List screen, the vService is selected and Edit is clicked.

2
Adım 2 Check QOS

The QOS box is checked in the Details panel.

3
Adım 3 Select the memory

A value is selected from the Memory Limit list (1–256 GB, default 2 GB).

4
Adım 4 Set Cores to Manual

The Cores switch is changed from Automatic to Manual.

5
Adım 5 Check the cores

The cores on which the vService will run are checked; if none is selected, the form gives the "At least one core must be selected" warning.

6
Adım 6 Select the priority

CPU Priority = High is selected (default Normal). This field is visible while Cores is Manual.

7
Adım 7 Enter the processor limit if needed

If an unimportant vService is to be limited, Cpu Usage Limit (%) is entered (1–100); if it is left empty, there is no limit. This field is also visible while Cores is Manual.

8
Adım 8 Save

Save is clicked. The vService restarts and open connections are closed (When does a change I make take effect; does it go live as soon as I save it?). In a cluster, it is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize.

Verification ​

1ResourcesTR7 side

The QOS, Cores, Memory limit and CPU priority rows in the Resources section of the vService's Load Balancer Management tab are checked.

ExpectedSelected values
2UsageTR7 side

The vService CPU and memory usage is monitored on the System tab of the vService dashboard; the memory percentage is calculated according to the selected Memory limit.

ExpectedUsage below the limit

Method 2: WEB-CLI ​

  • How it works The QOS fields are set from the command line.
  • Where it is opened TR7 WEB-CLI → lb service show · lb service update
  • Requirement WEB-CLI access; --memoryLimit is one of the values in the list, in bytes (e.g. 4 GB = 4294967296), --cpuPriority is low · normal · high, --cpuLimit is an integer from 1 to 100
  • vService type HTTP · L7 TCP

Step-by-Step Configuration ​

1
Adım 1 Check the current core list

On update, --poolCores.N replaces the Nth position in the list; the current list is viewed first:

text
lb service show <vService>
2
Adım 2 Write QOS

While the Cores list is empty (Automatic), the command reserves cores number 2 and 3 (resource management):

text
lb service update id <vService> --qos true --memoryLimit 4294967296 --poolCores.0 2 --poolCores.1 3 --cpuPriority high

If the list already has previously selected cores, the positions that are not written stay in the list; the excess ones are removed with --poolCores.N.delete. Saving restarts the vService. For more than one vService, bulk update is used.

Verification ​

1ResourcesTR7 side

The QOS fields are checked in the lb service show <vService> output and in the Load Balancer Management → Resources section.

ExpectedpoolCores 2, 3 · cpuPriority high

Common Mistakes ​

  • Assuming the save is uninterrupted. A QOS change restarts the vService; open connections are closed.
  • Assuming resources are unlimited while QOS is off. A vService with QOS off also runs with a 2 GB memory limit and automatic core assignment.
  • Setting a tight limit. A low Memory Limit or Cpu Usage Limit leads to slowness.
  • Forgetting the cache. The cache size is determined according to the memory limit of the vService; when Memory limit is reduced, the cache also shrinks (Can I do caching on TR7; what are the default settings?).
  • Assuming CPU priority always speeds things up. Priority makes a difference only when there is contention for the cores.

How it is done in the documentation

Related questions