이제 N1QL 쿼리 언어에 요청당 메모리 할당량이 있습니다.

다른 서비스와 달리 SQL++ 쿼리 언어는 에는 지금까지 메모리 공간을 조정할 수 있는 옵션이 없었습니다. 지금까지는요.

함께 카우치베이스 서버 7.0 출시이제 쿼리 서비스에는 요청당 메모리 할당량이 포함됩니다.

배경

SQL++(이전의 N1QL)와 다른 Couchbase 서비스 간에 이러한 격차가 발생하는 주된 이유는 한 가지 간단한 사실로 귀결됩니다. 색인 는 캐시이며, 새 문서가 들어올 때마다 공간이 부족할 경우 항상 제거할 수 있는 항목이 있습니다. 대부분의 쿼리 서비스 작업은 개별 요청의 한 단계에서 수명을 시작하고 요청이 끝나기 전에 만료되는 일시적인 값(가져온 문서 또는 계산된 값)에 의존합니다.

SQL++에서는 쫓아내고 대체할 것이 없습니다. 시계가 계속 돌아가기 위한 균형 잡힌 행위가 없습니다. 리소스를 사용할 수 없는 경우 유일한 옵션은 실패뿐입니다.

또한 이벤트, 색인 및 전체 텍스트 검색 코드가 쿼리 서비스 내부에서 실행됩니다. 이들은 SQL++ 메모리 리소스를 사용하지만 SQL++는 이를 제어할 수 없습니다.

SQL++ 메모리 소비는 문제가 되지 않지만 일반적으로 - 요청이 문서를 빠르게 로드하고 삭제하면 세상은 행복한 곳이지만, 때때로 이상한 욕심 많은 요청이 나타나서 모든 사람의 게임을 망치는 경우가 있습니다. 이 문제는 다음과 같은 이유로 수정이 필요했습니다. 카우치베이스 사용자.

하지만 SQL++가 제어할 수 없는 구성 요소는 일단 무시하고, 노드 전체에 일시적인 값 풀이 바람직한지 생각해 봅시다.

이러한 값 풀의 작동은 다음과 같이 작동할 수 있습니다: 요청에 값이 필요할 때마다 글로벌 풀에서 해당 크기를 할당하고, 요청이 완료되면 즉시 풀로 반환합니다. 메모리가 부족하면 충분한 메모리가 확보될 때까지 모든 할당이 실패합니다.

하지만 욕심 많은 요청이 나타나면 어떻게 될까요? 가능한 한 많이 잡고 놓지 않습니다. 다른 모든 검소한 요청은 어떻게 되나요? 퇴거가 불가능한 상황에서 유일한 선택지는 실패뿐입니다. 다른 요청은 오류와 오류로 하나씩 끝나고 결국 범인은 실패하게 됩니다.

이러한 행동은 교사가 분필로 맞은 학생을 교장실로 보낸 후 범인만 조사하여 보내지 않고 반 전체 학생을 교장실로 보내는 것과 비슷합니다.

이제 쿼리 서비스는 머리 뒤쪽에 눈을 키워 누가 분필을 던졌는지 확인할 수 있게 되었습니다.

요청당 메모리 할당량 입력

요청별 메모리 할당량이 켜져 있으면 각 쿼리 요청은 자체 풀을 갖게 됩니다. 메모리 추적은 평소와 같이 작동하지만 이제 풀이 모두 소진되면 실패한 범인만.

"하지만 노드 전체 설정은 다음과 같습니다. 많이 더 실용적이죠!" 무슨 말인지 알겠습니다. 맞습니다.

쿼리 서비스에서 한 번에 고정된 수의 요청을 실행할 수 있도록 하는 기능을 은밀하게 구현했습니다. 이 옵션은 서버 설정을 사용하면 기본적으로 쿼리 노드 코어 수의 4배로 설정됩니다. 전체 노드 메모리 할당량은 서버 수에 요청당 할당량을 곱한 값입니다.

요청당 할당량은 노드 전체가 아닌 개별 요청을 추적한다는 점을 명확히 하기 위해 명시적으로 설정했습니다.

어떻게 사용하나요?

SQL++의 요청당 메모리 할당량에는 두 가지 설정이 있습니다:

• • 그리고 /admin/settings 노드 REST 매개변수 메모리 할당량
  • 그리고 /query/service 요청 REST 매개변수 memory_quota

이 설정은 요청이 한 번에 사용할 수 있는 최대 메모리 양을 메가바이트 단위로 나타냅니다.

기본값 메모리 할당량 가 0인 경우, 즉 메모리 할당량이 꺼진 상태입니다. 메모리 할당량이 memory_quota 설정은 요청된 값이 이를 초과하지 않는 한 항상 노드 전체 설정을 재정의합니다.

몇 가지 예를 살펴보겠습니다. 아래 명령은 전체 노드의 메모리 할당량을 10MB로 설정하고 이 설정을 다른 모든 노드에 복제합니다:

그리고 이 명령은 아래에서 볼 수 있듯이 단일 요청에 대한 메모리 할당량을 10MB로 설정합니다:

마지막으로, 아래는 메모리 할당량을 10MB로 설정합니다. cbq 세션:

응답 및 시스템 키 공간

메모리 할당량이 설정되어 있는 경우(어떤 방식으로든) 여러 SQL++ 기능에 다음과 같은 추가 정보가 포함될 수 있습니다:

• • 메트릭
  • 컨트롤
  • 시스템 키 공간

이러한 각 응답을 자세히 살펴보겠습니다.

응답: 메트릭

응답의 메트릭 섹션에는 사용된 메모리 필드에 요청을 실행하는 데 사용된 문서 메모리 양을 표시합니다.

문서 메모리가 사용되지 않으면 이 메트릭은 생략됩니다. 다음에서도 동일한 생략이 발생합니다. 돌연변이 또는 errorCount 도 마찬가지입니다.

응답: 컨트롤

응답의 컨트롤 섹션에서는 설정에 따라 메모리 할당량도 보고합니다. 그 모습은 다음과 같습니다:

시스템 키 공간

시스템 키 공간 - 둘 다 시스템:활성_요청 그리고 시스템:완료_요청 - 에는 메모리 할당량 정보도 포함되어 있습니다. 메모리 할당량 정보는 사용된 메모리 그리고 메모리 쿼터 정보도 여기에 표시됩니다. 아래 예시를 살펴보세요:

메모리는 어떻게 사용되나요?

메모리 할당량 작업의 몇 가지 메커니즘을 살펴보기 전에 요청이 메모리를 사용하는 방식에 대해 조금 알아볼 필요가 있습니다.

이미 짐작하셨겠지만 사용된 메모리 메트릭 필드는 실행이 허용되기 전에 개별 문장의 메모리 요구 사항을 측정하기 위해 도입되었습니다. 이 실험을 시작으로 몇 가지 실험을 해보고 어떻게 작동하는지 살펴보겠습니다:

위에서 볼 수 있듯이 사용된 메모리는 결과 집합의 크기가 아닙니다.

이번에는 서식을 지정하지 않고 다시 시도해 보겠습니다. 이렇게 하면 결과 집합의 크기가 스토리지의 데이터 크기에 최대한 가깝게 됩니다:

가져온 데이터의 크기도 문제가 되지 않습니다.

결과를 화면에 표시하는 데 드는 비용을 제거해 보겠습니다:

같은 쿼리, 같은 형식이지만 저장 공간이 다르면 메모리 사용량도 달라집니다.

요점입니다: 일부 유형의 문에서 메모리 소비는 문 자체보다는 특정 실행 상황의 영향이 더 큽니다.

요청 실행 단계 작업

요청의 실행 단계에서는 병렬로 실행되는 연산자 파이프라인을 사용합니다. 각 연산자는 이전 단계에서 값을 수신하고 해당 값을 처리한 다음 다음 단계로 전송합니다.

연산자 값 교환 인프라에는 값 대기열이 포함되어 있어 각 연산자가 이전 연산자나 다음 연산자에 의해 차단되지 않습니다. (사실 실행 엔진은 더 복잡합니다. 일부 연산자는 다른 연산자에 인라인되어 있고 일부는 오케스트레이션 작업을 수행하기 위해서만 존재하므로 값 대기열이 항상 관여하는 것은 아니지만 여전히 존재합니다.)

예를 들어 다음과 같은 간단한 쿼리가 있습니다:

는 인덱스 스캔 를 사용하여 키를 생성하고 가져오기 를 사용하여 키-값 캐시에서 문서를 검색하여 필터 를 사용하여 해당되지 않는 문서를 제외시키고, 해당되는 문서는 프로젝션 를 사용하여 필드를 추출하고 (필요한 경우) JSON으로 마샬링한 후 최종적으로 스트림 를 호출하면 클라이언트에 다시 기록합니다.

코스를 완료한 값은 결국 쓰레기 수거 과정에서 폐기됩니다.

위의 예에서 이러한 연산자를 모두 병렬로 실행할 수 있는 코어가 있고 모든 연산자가 정확히 동일한 속도로 실행된다면, 요청이 아무리 많은 문서를 처리하더라도 한 번에 파이프라인을 통과하는 문서가 5개 이상은 되지 않을 것입니다.

물론 스캔 보다 훨씬 빠르게 키를 생성할 수 있습니다. 가져오기 는 문서를 수집할 수 있고 마샬링 비용이 많이 들 수 있습니다. 유선을 통해 클라이언트로 결과를 다시 전송하는 것은 느릴 수 있으므로 사용 가능한 코어가 있더라도 위에서 설명한 대기열은 회선을 따라 처리 대기 중인 값의 버퍼로 사용됩니다. 결과적으로 요청이 들어오는 값의 시퀀스를 처리하는 데 필요한 메모리 양이 일시적으로 증가합니다.

이 패턴은 프로젝션 더 효율적(예쁜=거짓), 또는 스트림 (터미널이 아닌 파일로 전송)는 메모리 소비에 유익한 효과가 있습니다. 연산자가 빠르면 값 교환 대기열에 갇혀 있는 값이 줄어듭니다.

요청 부하가 증가하면 SQL++ 커널에서 예약해야 할 연산자가 더 많아지므로, 이전 연산자가 실행되지 않는 동안 이전 연산자의 값 대기열 크기가 증가하여 개별 요청을 처리하는 데 더 많은 메모리가 필요합니다. 결국, 로드된 노드는 활동이 거의 없는 노드보다 더 많은 메모리를 사용합니다.

메모리 할당량 작업

앞선 논의의 목적상 값을 교환하지 않고 메모리가 증가하는 경우는 모두 무시했습니다. 해시 JOIN, ORDER BY, GROUP BY가 가장 먼저 떠오르는 몇 가지 예입니다.

정렬, 집계 또는 해시 버퍼가 특정 임계값 이상으로 증가하거나 메모리 할당량이 초과되어 오류가 발생하고 요청이 실패하는 경우 등 메모리 할당량의 첫 번째 작동 모드가 이러한 특정 경우를 처리합니다.

그러나 앞서 살펴본 것처럼 요청 부분의 결함 없이 메모리 사용량이 증가하는 상황은 여러 가지가 있습니다.

이러한 경우 메모리 할당량 기능은 메모리 사용량을 제어하고 과도한 리소스 없이 요청을 완료할 수 있도록 지원하는 기술을 사용합니다.

소비자 하트비트 기능

파이프라인은 생산자와 소비자가 모두 같은 속도로 진행할 때 잘 작동합니다.

생산자가 실행하지 않으면 요청은 그냥 지연됩니다. 그러나 소비자가 실행하지 않으면 요청이 중단될 뿐만 아니라 생산자의 값 대기열의 크기도 증가합니다.

이러한 가능성에 대응하기 위해 소비자 운영자에게는 생산자가 모니터링하는 하트비트가 장착되어 있습니다. 소비자가 대기 중이지만 생산자 측에서 설정된 횟수의 전송 작업이 성공한 후에도 값을 수신하려고 시도하지 않으면 생산자는 소비자가 실행할 때까지 양보합니다.

안타깝게도 SQL++ 개발에 사용된 언어가 특정 연산자에게 양보하는 것을 허용하지 않기 때문에 이 접근 방식은 정확한 과학은 아닙니다. 하지만 충분한 생산자가 양보하면 모든 소비자가 커널 시간을 공평하게 확보할 수 있으므로 메모리 사용량이 자연스럽게 감소할 것입니다.

운영자당 할당량

수율은 정확한 과학이 아니기 때문에, 개별 소비자가 생산자보다 커널 시간이 적기 때문에 개별 운영자가 가끔씩 실행하더라도 상당한 메모리 사용량을 기록할 수 있습니다.

이러한 불균형을 해결하기 위해 SQL++에는 생산자별 메모리 풀도 있습니다. 이 풀이 모두 소진되면 생산자가 양보하고(실패하지 않고) 소비자가 값을 받으면 작업을 재개합니다.

이러한 양보로 인해 이전 생산자가 자신의 풀을 소진하고 양보함으로써 전체 요청 풀을 소비하지 않고 전체 요청이 진행될 수 있지만, 처리량을 희생할 수도 있습니다(반드시 그렇지는 않음).

기타 트릭

지금까지 쿼리는 가비지 수집기에 의존하여 힙에 값 메모리를 반환하고 메모리 관리자가 값 구조를 할당했습니다.

메모리 추적 노력의 일환으로 가비지 컬렉터 자체에서 CPU 시간을 확보하고 보류 중인 모든 미사용 값을 처리하기 전에 메모리를 미사용으로 표시하는 기술을 도입했습니다.

또한 이미 할당되어 재사용이 가능한 일부 미사용 값 구조를 저장하는 소규모 임시 풀이 있어 가비지 수집기가 특정 유형의 동적 메모리 할당을 위해 반복적으로 실행할 필요가 없고 대신 중요한 메모리를 처리하는 데 집중할 수 있습니다.

결론

Couchbase Server 7.0 릴리스 이전에는 쿼리 서비스가 조금은 자유 요청당 메모리 사용량을 제한합니다. 이제 메모리 사용량을 제어할 수 있는 당근과 채찍이 명확해졌습니다. 도움이 되셨기를 바랍니다.