카우치베이스의 쿼리 서비스 메모리 관리

카우치베이스에서 쿼리 서비스의 메모리 관리는 특히 서비스가 동시에 처리하는 쿼리 수가 증가함에 따라 서비스를 효율적이고 응답성 있게 유지하는 핵심 요소입니다. 적절한 메모리 관리 없이는 문제가 발생할 수 있습니다. 자원을 탐욕스럽게 소모하는 쿼리가 메모리를 독점할 수 있고, 여러 동시 쿼리의 결합된 메모리 사용량이 서비스에 과부하를 주어 성능 저하로 이어질 수 있습니다.

다행히도 쿼리 서비스에는 사용자가 쿼리의 메모리 사용량과 전체 서비스를 관리할 수 있게 해주는 여러 기능이 있습니다.

이 블로그에서는 이러한 기능들을 자세히 살펴보겠습니다.

• 요청당 메모리 할당량
• 소프트 메모리 제한
• 노드 전체 문서 메모리 할당량

요청별 메모리 할당량

Query 서비스 메모리 usage의 상당 부분은 문서나 계산된 값을 포함할 수 있는 임시 값에서 발생합니다. 이러한 임시 값이 사용하는 메모리는 다음과 같이 지칭됩니다. 문서 메모리 블로그에.

쿼리 서비스는 데이터 서비스로부터 인코딩된 바이트 스트림 형태로 문서를 수신합니다. 그러나 문서와 연결된 값이 사용하는 메모리는 원래 스트림보다 훨씬 클 수 있습니다. 이는 쿼리 서비스가 모든 필드, 값 및 중첩된 객체를 저장해야 하므로 규모가 커질 수 있는 구조로 스트림을 디코딩하기 때문입니다. 쿼리 서비스는 압축성보다는 성능에 최적화되어 있습니다.

자원 집약적인 쿼리가 들어와서 문서 메모리를 대량으로 사용하기 시작하면 어떻게 될까? 결국 메모리를 독점하여 다른 쿼리들이 멈추는 원인이 될 수 있다. 이를 어떻게 방지할 수 있을까? 탐욕스러운 다른 활성 쿼리의 실행에 영향을 미치는 쿼리로부터?

여기가 바로 그 요청당 메모리 할당량 기능이 추가됩니다!

Couchbase 7.0 이후부터 쿼리 서비스는 다음의 설정을 제공합니다. 메모리 할당량 쿼리 요청이 실행되는 동안 언제든지 사용할 수 있는 최대 문서 메모리 양을 제한하기 위해.

이 요청 별 메모리 할당량은 쿼리가 할당량을 초과할 경우 해당 쿼리를 종료하고 다른 모든 활성 쿼리는 계속 실행되도록 하는 방식으로 작동합니다. 이는 자원을 과도하게 소모하는 쿼리만 중단되도록 보장하여 다른 쿼리의 성능에 영향을 미치는 것을 방지합니다.

메모리 할당량이 OS 메모리 사용량과 일치하지 않습니다. 오직 문서 메모리 사용량만을 차지하며 힙, 스택, 실행 연산자 등에서 사용되는 메모리는 차지하지 않습니다.

메모리 할당량은 어떻게 작동하나요?

요청별 메모리 할당량은 쿼리 요청에 대한 문서 메모리 풀을 구성하는 것으로 생각할 수 있습니다. 풀의 크기는 쿼리의 메모리 할당량 값에 의해 결정됩니다.

쿼리가 문서/값을 요구할 때, 이 풀에서 문서/값의 크기를 할당합니다. 값/문서가 더 이상 필요하지 않으면, 할당된 크기는 요청에 의해 재사용되도록 풀로 반환됩니다.

어느 순간이든 쿼리 요청이 사용하는 문서 메모리의 총량은 해당 풀의 크기, 즉 메모리 할당량을 초과할 수 없습니다. 쿼리가 풀에서 사용할 수 있는 양보다 더 많은 문서 메모리를 사용하려고 하면, 해당 요청은 종료되고 오류가 반환됩니다.

쿼리 서비스는 고도로 병렬화되어 있으며 연산자들이 동시에 실행될 수 있다는 점에 유의하는 것이 중요합니다. 이는 실행마다 문서 메모리 사용량(따라서 요청 풀에서 할당되는 메모리 양)이 동일한 실행 단계에서도 달라질 수 있기 때문에, 쿼리가 메모리 할당량을 초과하는지 여부가 실행마다 다를 수 있음을 의미합니다.

메모리 할당량 구성 방법

요청당 메모리 할당량은 클러스터, 노드 및 요청 수준에서 설정할 수 있습니다.

• 유닛 맨인블랙
• 기본값 0, 즉 요청이 사용할 수 있는 문서 메모리 양에는 제한이 없습니다.

클러스터 수준

클러스터 내 모든 쿼리 노드의 메모리 할당량을 설정합니다 메모리할당량조회 클러스터 수준 설정. 클러스터 수준의 값은 지속되며, 설정되면 모든 쿼리 노드의 노드 수준 설정을 덮어씁니다.

• 클러스터 수준 설정을 구성하는 방법을 알아보세요. 여기

노드 수준

특정 쿼리 노드에 대한 메모리 할당량을 설정합니다 메모리 할당량 노드 수준 설정. 노드 수준에서 설정된 값은 해당 노드에서 실행되는 모든 쿼리 요청에 대한 기본 메모리 할당량입니다. 노드 수준 값은 지속되지 않으며 클러스터 수준 설정이 수정될 때 덮어쓰여집니다.

• 노드 수준 설정 방법을 알아보세요 여기

요청 수준

특정 쿼리 요청에 대한 메모리 할당량 설정 메모리 할당량 매개변수. 요청 수준 매개변수는 노드 수준 설정의 값을 무시합니다. 그러나 노드 수준 설정이 0보다 큰 경우, 요청 수준 값은 노드 수준 값에 의해 제한됩니다.

• 요청 수준 매개변수 설정 방법 배우기 여기

쿼리 서비스의 소프트 메모리 제한

이제 쿼리의 문서 메모리 usage를 제한하는 방법을 살펴보았으므로, 쿼리 서비스 자체의 메모리 usage를 제한할 수 있는 방법이 있는지 궁금하실 수 있습니다.

쿼리 서비스에는 서비스의 메모리 사용량에 엄격한 제한(하드 리밋)을 강제하는 설정이 없습니다. 이는 SQL++를 개발하는 데 사용된 프로그래밍 언어가 런타임 메모리 사용량에 대한 하드 리밋을 강제하는 메커니즘을 제공하지 않기 때문입니다. 하지만 소프트 메모리 리밋을 조정하는 메커니즘은 제공합니다…

따라서 Couchbase 7.6.0에서는 노드 할당량 Query 서비스의 소프트 메모리 제한을 조정하기 위해 설정이 도입되었습니다!

이것은 소프트 한계이므로, 쿼리 서비스의 메모리 사용량이 항상 엄격하게 이 한계 아래로 유지된다거나 메모리 부족(OOM) 상황이 발생하지 않는다고 보장할 수는 없습니다. 그러나 이 한계를 초과하거나 근접할 때 가비지 컬렉터(GC)를 더 자주 실행하여 쿼리 서비스의 메모리 사용량을 이 한계 아래로 유지하려는 노력이 이루어집니다.

중요 참고 사항:
메모리 사용량이 소프트 한트에 근접한 상태로 유지되면 GC가 적극적으로 실행되어 높은 CPU 사용량을 유발할 수 있습니다.

노드 할당량 구성 방법

노드 할당량은 클러스터, 노드 및 요청 수준에서 설정할 수 있습니다.

• 유닛 맨인블랙
• 기본값 0
• 최소 1

node-quota의 최솟값은 1 MiB이지만, 워크로드와 시스템 사양에 따라 실용적인 값으로 노드 쿼터를 설정해 주십시오.

클러스터 수준

클러스터 내 모든 쿼리 노드의 노드 할당량을 설정합니다. 쿼리노드할당량 클러스터 수준 설정. 클러스터 수준의 값은 지속되며, 설정되면 모든 쿼리 노드의 노드 수준 설정을 덮어씁니다.

• 클러스터 수준 설정을 구성하는 방법을 알아보세요. 여기

중요 공지:

이 설정을 클러스터 전체에 구성하는 한 가지 방법은 Couchbase 웹 콘솔을 사용하는 것입니다. 웹 콘솔에서 이 설정은 다음 위치에서 구성할 수 있습니다: 서버 노드당 메모리 할당량 설정 페이지에서.

이 섹션은 특히 쿼리 서비스의 클러스터 수준 노드 할당량을 구성하기 위한 것이며, 클러스터 수준 메모리 할당량 설정과 혼동해서는 안 됩니다.

노드 수준

특정 쿼리 노드에 대한 노드 할당량을 설정합니다. 노드 할당량 노드 수준 설정. 노드 수준에서 설정된 값은 해당 노드에서 실행되는 모든 쿼리 요청에 대한 기본 메모리 할당량입니다. 노드 수준 값은 지속되지 않으며 클러스터 수준 설정이 수정될 때 덮어쓰여집니다.

• 노드 수준 설정 방법을 알아보세요 여기

소프트 메모리 제한을 구성하는 방법

쿼리 서비스의 소프트 메모리 제한은 노드 할당량 값을 사용하여 설정됩니다. 설정되지 않은 경우 기본값이 계산됩니다.

노드 할당량

노드에 노드 할당량이 설정된 경우, 이는 소프트 메모리 제한입니다. 소프트 메모리 제한은 다음 단계에 따라 계산되는 최대 허용 값으로 상한이 설정됩니다.

a) 전체 시스템 RAM과 90%의 전체 시스템 RAM 간의 차이를 계산합니다.

전체 시스템 RAM - (0.9 * 전체 시스템 RAM)

b) 차이가 8 GiB보다 크면, 최대 소프트 메모리 제한은 다음과 같습니다:

전체 시스템 RAM - 8 GiB

c) 차이가 8 GiB 이하인 경우, 최대 소프트 메모리 제한은 전체 시스템 RAM의 90%로 설정됩니다.

노드 할당량이 계산된 최댓값을 초과하는 경우, 소프트 메모리 제한이 자동으로(묵시적으로) 최댓값으로 설정됩니다.

기본값

노드에 노드 할당량 설정이 지정되지 않은 경우, 다음 단계를 사용하여 소프트 제한에 대한 기본값이 계산됩니다.

a) 전체 시스템 RAM과 90%의 전체 시스템 RAM 간의 차이를 계산합니다.

전체 시스템 RAM - (0.9 * 전체 시스템 RAM)

b) 차이가 8 GiB보다 크면, 기본 소프트 메모리 제한은 다음과 같습니다:

전체 시스템 RAM - 8 GiB

c) 차이가 8 GiB 이하인 경우, 기본 소프트 메모리 제한은 전체 시스템 RAM의 90%로 설정됩니다.

노드 전체 문서 메모리 할당량

작업(workload)에 실행하는 데 많은 양의 메모리가 필요한 쿼리가 있는 경우, 요청당 메모리 할당량을 강제하는 것은 해당 쿼리가 할당량 초과로 인해 자주 종료될 수 있으므로 이상적이지 않을 수 있습니다. 쿼리 서비스가 과도한 메모리 사용으로부터 보호되도록 하면서 이 쿼리를 성공적으로 실행하려면 어떻게 해야 할까요?

각 요청별 메모리 할당량이 설정된 상태에서 여러 쿼리가 동시에 실행되는 또 다른 시나리오를 생각해 보십시오. 이 시나리오에서는 서비스의 메모리 사용량이 매우 높아졌습니다. 하지만 쿼리들의 문서 메모리 사용량은 각자의 할당량 아래에 머물러 있습니다. 따라서 어떤 쿼리도 종료되지 않습니다. 결과적으로 쿼리 서비스의 전체 메모리 사용량이 높은 상태로 유지되어 문제를 일으킵니다. 이를 어떻게 해결할 수 있습니까?

Couchbase 7.6.0부터 쿼리 서비스에는 활성 쿼리가 사용할 수 있는 문서 메모리의 누적 양을 제한하는 메커니즘이 있습니다! 노드 전체의 문서 메모리 할당량 도입은 이러한 과제들을 해결하기 위한 시도입니다.

노드 전체 할당량은 어떻게 작동하나요?

노드 전체 할당량은 노드 상의 전체 쿼리 서비스에 대한 문서 메모리 풀을 구성하는 것으로 생각할 수 있습니다.

노드 할당량이 설정되면, 메모리 세션 각 요청에 대해 생성됩니다. 기본적으로 이 세션은 1 MiB의 초기 크기로 시작합니다. 노드 전체 할당량이 구성된 경우, 각 서비서(servicer)마다 1 MiB가 할당되며 노드 전체 풀에서 차감됩니다. 이 기본 할당은 각 서비서가 최소한의 예약된 공간을 갖도록 보장하여 들어오는 요청이 항상 처리될 수 있도록 합니다.

요청에 값/문서가 필요할 때, 해당 값/문서의 크기는 다음으로부터 할당됩니다 세션. 세션에 이 할당을 위한 메모리가 충분하지 않은 경우, grow in minimum increments of 1 MiB to accommodate the allocation request. The additional memory required for this growth is allocated from the node-wide pool.

If an active request’s memory session attempts to grow beyond the available remaining memory in the node-wide pool, the request will be stopped and an error returned.

Once the request no longer needs the value/document, it returns the allocated size back to its 세션.

The session’s memory (excluding the 1 MiB of the initial servicer reservation) is only returned to the node-wide pool once the request’s execution completes.

At any time, the total size of all memory sessions cannot exceed the size of the node-wide quota.

It is important to understand that this memory session is not to be confused with the per-request pool that is configured when the memory quota is set for a request. The two are not the same.Both a node-wide quota and a per-request memory quota can be configured. Read Configuring both Node-Wide Document Quota and Per-Request Memory Quota section below to understand more.

In this way, the node-wide quota places a limit on the amount of document memory that is being used by all active requests.

The node-wide document quota can only be configured when the node quota setting is explicitly set for a node. The size of this quota is calculated using two Query settings, 노드 할당량 (explored in an earlier section) and node quota value percent.

How to configure node quota value percent?

The node quota value percent is the percentage of the node quota dedicated to tracked value content memory/ ”document memory” across all active requests.

The node quota value percent can be set at the cluster and the node level.

• 유닛 맨인블랙
• 기본값 67
• 최소 0
• Maximum: 100

클러스터 수준

Set the node quota value percentage for every Query node in the cluster with the queryNodeQuotaValPercent 클러스터 수준 설정. 클러스터 수준의 값은 지속되며, 설정되면 모든 쿼리 노드의 노드 수준 설정을 덮어씁니다.

• 클러스터 수준 설정을 구성하는 방법을 알아보세요. 여기

노드 수준

Set the node quota value percentage for a particular Query node with the node-quota-val-percent 노드 수준 설정. 노드 수준에서 설정된 값은 해당 노드에서 실행되는 모든 쿼리 요청에 대한 기본 메모리 할당량입니다. 노드 수준 값은 지속되지 않으며 클러스터 수준 설정이 수정될 때 덮어쓰여집니다.

• 노드 수준 설정 방법을 알아보세요 여기

How to configure the node-wide document memory quota

The size of the node-wide document memory quota is calculated relative to the node-quota. The node-quota 반드시 해야 한다 be set for the node-wide document memory quota to be configured.

The size of the node-wide pool is calculated using the following steps:

1. Calculate the percentage of the node quota dedicated to tracking document memory across all active queries using the following formula:

node-quota * node-quota-val-percent / 100

2. Calculate the minimum allowable value for the node-wide document memory quota.

The execution of SQL++ statements is handled by servicers. When a query is to be executed it is assigned to a servicer thread that is responsible for its execution. The Query service is configured with a number of servicers to handle incoming requests. There are two types of servicers, unbounded servicers 그리고 plus servicers.

The Query engine reserves 1 MiB of document memory for each servicer. Hence, the default initial value of each request’s memory session is 1 MiB. This means that the baseline document memory usage will be the total number of unbounded and plus servicers, measured in MiB.

Therefore, the size of the node-wide document memory quota must be at least equal to the number of servicers, measured in MiB.

• Learn more about unbounded servicers 여기 and plus servicers 여기

Formula 1

서비스 제공자를 위해 예약된 할당량 =
(제한 없는 서비스 제공자 수 + 플러스 서비스 제공자 수) MiB

3. The size of the node-wide document memory quota is calculated using the following formula:

Formula 2

노드 전체 문서 메모리 할당량 크기
=
MAX( node-quota * node-quota-val-percent / 100, 서비스 제공자를 위해 예약된 할당량)

• The quota reserved for the servicers is calculated using Formula 1

This is the maximum allowable size of all memory sessions across active requests and includes the initial reservation for each servicer.

Calculating available quota in the pool for document memory growth

The initial reservation for the servicers is deducted from the node-wide document memory quota for the node. Any remaining space in the node-wide memory pool can be used by each active request to grow its document memory usage beyond its initial 1 MiB reservation.

This remaining quota available for document memory growth is calculated using the following formula:

Formula 3

활성 요청의 메모리 세션이 증가할 수 있는 노드 전체 문서 메모리 할당량의 크기 =
노드 전체 문서 메모리 할당량 크기 - 서비스 제공자용으로 예약된 할당량

• The size of node-wide document memory quota is calculated in Formula 2 
• The quota reserved for the servicers is calculated using Formula 1 

It is important to set appropriate node-quota and node-quota-val-percent values that are practical and suitable for workloads. An example to illustrate the importance of this:

예시

Consider a Query node with 32 unbounded servicers and 128 plus servicers. The Administrator sets the node-quota to 10 MiB. The node-quota-val-percent is the default value of 67.

사용하여 Formula 2 to calculate the size of the node-wide document memory quota:

사용하여 Formula 3 to calculate the amount of document memory available in the node-wide pool available for requests’ memory growth:

This means that there is no room for document memory growth of requests beyond their 1 MiB initial reservation. In other words, each request is limited to using a maximum of 1 MiB of document memory.

Additionally the node-quota of 10 MiB is very small, garbage collection will likely be forced to run frequently causing high CPU utilization.

Reporting document memory figures

If the memory quota was set for a request or a node-wide document memory pool configured, information about the same will be reported in several SQL++ features which will be explored below. This information is helpful for debugging.

Response output

a) Metrics:

그 usedMemory field in the 지표 section of the query’s response reports the high water mark (HWM) document memory usage of the query in bytes.

The Query service is highly parallelized, and operators can run simultaneously.  As a result, the usedMemory figures can vary between runs for the same query. This is because, depending on the specifics of each run, the HWM document memory usage can be different.

b) Controls section:
If the controls Query setting is enabled and the 메모리 할당량 configured for the request, the memoryQuota field in the controls section of the query’s response reports the value of the memory quota set.

• Learn more about the controls setting 여기

System keyspaces

system:completed_requests, system:active_requests

In a request’s entry in these system keyspaces:

그 usedMemory field is the HWM document memory usage of the query in bytes. The Query service is highly parallelized, and operators can run simultaneously.  As a result, the usedMemory figures can vary between runs for the same query. This is because, depending on the specifics of each run, the HWM document memory usage can be different.

그 memoryQuota field is the value of the memory quota set for the request

• 자세히 알아보기 system:completed_requests 여기 그리고 system:active_requests 여기.

Configuring both per-request memory quota and node-wide document quota

As described in the 요청당 메모리 할당량 section, if a request has a memory quota configured, the maximum amount of document memory that it can use at any given time during its execution is limited by the memory quota.

Additionally, as explained in the Node-Wide Document Memory Quota section, when the node-quota and a node-wide document memory quota is configured, each request gets its own “memory session.” Any growth in the size of these sessions is allocated from the node-wide document memory quota.

If a node-wide document memory quota is configured and a request has a memory quota set, the document memory usage of the query request is limited by both quotas.

How would a document/value allocation be performed?

When the request requires a document/ value, the following steps are performed during the allocation process:

1. Memory Session Allocation:

• The request first tries to allocate memory for the document from its memory session.
• If there is enough space in the session, the allocation is successful.
• If there is insufficient space in the session, the session attempts to grow its size by allocating from the node-wide document memory quota. (i.e. from the “node-wide document memory pool” ).
• If there is not enough space for the session’s growth in the node-wide pool, the request will be stopped and an error returned.

1. Request Memory Quota Allocation:

• If the session allocation is successful, the request will attempt to allocate memory for the document from its memory quota. ( i.e. from its “request memory pool”).
• If there is sufficient space left in its memory quota, the allocation succeeds and the request proceeds.
• If there is not enough remaining space in the memory quota, the request will fail and an error will be returned.

Monitoring with system:vitals

The system keyspace system:vitals contains important information about each Query node in the cluster, including information related to memory and CPU usage, garbage collection and much more.  Users can use this system keyspace to monitor the health and vitals of the Query nodes.

There are two ways to access this information:

1. Query the system:vitals keyspace using SQL++.

SELECT * FROM system:vitals;

1. Accessing the vitals per node using the Query service’s /admin/vitals endpoint.

curl -u $USER:$PASSWORD $QUERY_NODE_URL/admin/vitals

Below is a sample of a record in system:vitals for a Query node.

• Learn more about the Vitals 여기 그리고 system:vitals 여기.

How does the query service trigger the garbage collector?

Starting in 7.6.0, the Query service routinely checks if the garbage collector (GC) has run in the last 30 seconds. If it has not, the GC is triggered to run. During this check, the amount of free system memory is also monitored. If the amount of free memory is less than 25%, an attempt is made to return as much memory to the OS as possible.

Run garbage collector on demand

Starting in 7.6.0, the Query service provides a REST endpoint /admin/gc that can be invoked to run the garbage collector. This endpoint can be invoked to trigger a GC run in an attempt to reduce memory utilization.

To force a GC run issue a GET request to the API:

curl -u $USER:$PASSWORD $QUERY_NODE_URL/admin/gc

To force a GC run and attempt to return as much memory to the OS as possible issue a POST request to the API

curl -X POST -u $USER:$PASSWORD $QUERY_NODE_URL/admin/gc

• Learn more about this endpoint 여기.

중요 공지:
Aggressively running the garbage collector can cause high CPU utilization.

Helpful references

• Couchbase blog on per-request memory quota
• Couchbase documentation for system keyspaces
• Configuring cluster, node, request level Query settings