KR20180018302A

KR20180018302A - 데이터 프로세싱 엔진 및 그것의 리소스 관리 방법

Info

Publication number: KR20180018302A
Application number: KR1020170076031A
Authority: KR
Inventors: 강양욱; 기양석
Original assignee: 삼성전자주식회사
Priority date: 2016-08-11
Filing date: 2017-06-15
Publication date: 2018-02-21
Also published as: US20180046512A1; US10146583B2; KR102226014B1

Abstract

본 발명의 실시 예에 따른 데이터 프로세싱 엔진의 리소스(resource) 관리 방법은, 복수의 쓰레드(thread) 그룹을 포함하는 쓰레드 풀(pool)을 제공하는 단계, 복수의 CPU(Central Processing Unit) 그룹을 포함하는 CPU 풀을 제공하는 단계, 입출력 테스크(task)들과 계산(compute) 테스크들을 포함하는 복수의 테스크를 수신하는 단계, 복수의 테스크 각각을 쓰레드 풀 내의 적어도 하나의 쓰레드 그룹으로 매핑(mapping)하는 단계, 그리고 쓰레드 풀 내의 복수의 쓰레드 그룹 각각을 CPU 풀 내의 적어도 하나의 CPU 그룹에 매핑하는 단계를 포함할 수 있다. 복수의 쓰레드 그룹 각각은 하나 이상의 쓰레드를 포함하고, 복수의 CPU 그룹 각각은 하나 이상의 CPU 코어를 포함하고, 복수의 테스크와 복수의 쓰레드 그룹 사이의 매핑 및 복수의 쓰레드 그룹과 복수의 CPU 그룹 사이의 매핑은 성능 변수들(variables)에 기반하여 동적으로 변경될 수 있다.

Description

데이터 프로세싱 엔진 및 그것의 리소스 관리 방법{A DATA PROCESSING ENGINE AND A METHOD FOR MANAGING RESOURCES THEREOF}

본 발명은 데이터 프로세싱 시스템에 관한 것으로, 좀 더 상세하게는 데이터 프로세싱 엔진 및 그것의 리소스 관리 방법에 관한 것이다.

시스템 리소스(resource) 관리 스킴(scheme)들은 데이터 프로세싱(data processing) 시스템의 성능 및 레이턴시(latency) 특성들을 결정하는데 중요한 역할을 한다. 대부분의 데이터 프로세싱 엔진들은, 그들의 백엔드(backend) 리소스 관리의 기반 구조(infrastructure)로서, 온디맨드(on-demand) 정책 및 정적(static) 매핑(mapping) 정책 중 하나를 사용한다. 온디맨드 리소스 관리 정책(종종 쓰레드-풀(thread-pool)로 지칭됨)은 다수의 데이터 중심(data-driven) 엔진들 및 계산 집중된(compute-intensive) 엔진들(예를 들어, Hadoop, Ceph 등) 내에서 사용된다. 정적 리소스 관리는, SCYLLA와 같은 데이터 스토리지 시스템들 또는 데이터 프로세싱 엔진들에 대한, 대부분의 상업적인 고성능 운영 체제(OS: Operating System)들의 기반(basis)이다.

온디맨드 정책은, 프로세스들 또는 쓰레드들을 실행할 때, 운영 체제의 공정하고(fair) 시분할(time-sharing)되는 스케쥴러(scheduler)에 기반한 계산 리소스들(예를 들어, CPU(Central Processing Unit))을 잘 활용한다. 하지만, 온디맨드 정책은 종종 입출력(I/O: Input/Output)과 계산 테스크들 간의 높은 CPU 경합(contention)을 발생시킬 수 있고, 이에 따라 보다 긴 레이턴시를 야기할 수 있다. 정적 매핑 정책은 입출력 및 계산 테스크들을 CPU의 다양한 물리 코어들에 할당함으로써 CPU 경합을 완화할 수 있다. 정적 매핑 정책은 보다 짧은 레이턴시를 발생시킬 수 있다. 하지만, 입출력 워크로드(workload)를 예측할 수 없는 경우 또는 기 할당된(pre-assigned) 쓰레드들과 계산 리소스들에 대한 충분한 요청들이 없는 경우, 정적 매핑 정책은 이상적이지 않을 수 있다. 기 할당된 테스크에의 불충분한 요청들은 계산 리소스들을 아이들(idle) 상태로 만들 수 있고, 이에 따라 차선의 성능을 야기한다.

본 발명은 상술된 기술적 과제를 해결하기 위한 것으로써, 본 발명은 동적으로 리소스들을 관리하는 데이터 프로세싱 엔진 및 그것의 리소스 관리 방법을 제공할 수 있다.

본 발명의 다른 실시 예에 따른 데이터 프로세싱 엔진은, 데이터 프로세싱 시스템의 성능 변수들을 모니터(monitor)하도록 구성된 시스템 상태 모니터, 그리고 입출력 테스크들과 계산 테스크들을 포함하는 복수의 테스크, 쓰레드 풀 내의 복수의 쓰레드 그룹, CPU 풀 내의 복수의 CPU 그룹을 매핑하도록 구성된 동적(dynamic) 매퍼를 포함할 수 있다. 복수의 쓰레드 그룹은 하나 이상의 입출력 핸들러(handler)와 하나 이상의 데이터 프로세서를 포함할 수 있다. 동적 매퍼는, 복수의 테스크 각각을 쓰레드 풀 내의 복수의 쓰레드 그룹의 쓰레드 그룹에 매핑하고, 쓰레드 풀 내의 복수의 쓰레그 그룹 각각을 CPU 풀 내의 복수의 CPU 그룹의 적어도 하나의 CPU 그룹에 매핑하도록 구성될 수 있다. 복수의 테스크와 복수의 쓰레드 그룹 사이의 매핑과 복수의 쓰레드 그룹과 복수의 CPU 그룹 사이의 매핑은 성능 변수들에 기초하여 동적으로 변경될 수 있다.

본 발명은 동적으로 리소스들을 관리하는 데이터 프로세싱 엔진을 포함할 수 있다. 본 발명의 실시 예에 따르면, 테스크(task)들 사이의 CPU 리소스들을 안정화할 수 있고, 결과적으로 프로세싱 처리량이 향상될 수 있다.

본 명세서에 일부로서 포함된 첨부된 도면들은 본 발명의 바람직한 실시 예를 도시하고 있고, 상술한 일반적인 설명들과 함께 이하에서 기술되는 바람직한 실시 예의 상세한 설명은 본 명세서에서 설명되는 원리들을 교시하고 설명할 것이다.
도 1은 온디맨드 스킴을 갖는 비동기식(asynchronous) 데이터 프로세싱 어플리케이션의 시스템 활용도를 예시적으로 보여준다.
도 2는 정적-할당(static-assignment) 스킴을 갖는 비동기식 데이터 프로세싱 어플리케이션의 시스템 활용도를 예시적으로 보여준다.
도 3은 종래의 온디맨드 스킴에서의 매핑을 예시적으로 보여준다.
도 4는 종래의 정적 할당 스킴에서의 매핑을 예시적으로 보여준다.
도 5는 본 발명의 일 실시 예에 따른 동적 매핑 스킴을 예시적으로 보여준다.
도 6은 본 발명의 일 실시 예에 따른 데이터 프로세싱 엔진의 예시적인 블록도를 보여준다.
도 7은 본 발명의 일 실시 예에 따른 동적 매퍼(mapper)의 예시적인 순서도를 보여준다.
도 8은 본 발명의 일 실시 예에 따른 입출력(I/O) 핸들러(handler)의 예시적인 순서도를 보여준다.
도 9는 본 발명의 일 실시 예에 따른 데이터 프로세서의 예시적인 순서도를 보여준다.
도면들은 반드시 일정한 비율로서 그려지지 않고, 일반적으로, 유사한 구조나 기능들의 요소들은 도면들에 걸쳐 예시적인 목적을 위해 유사한 참조 번호로 표시된다. 도면들은 본 명세서에서 기술되는 다양한 실시 예들의 설명을 용이하게 하기 위한 것이다. 도면들은 본 명세서에 개시된 교시들의 모든 양상들을 기술하지 않으며, 청구항의 보호 범위를 제한하지 않는다.

본 명세서에서 개시된 특징들 및 교시들 각각은 데이터 프로세싱 시스템들 내에서 계산 및 입출력 리소스를 동적으로 관리하기 위한 시스템 및 방법을 제공하기 위한 다른 특징들 및 교시들과 함께 또는 분리되어 사용될 수 있다. 이러한 추가적인 특징들 및 교시들이 분리되거나 결합되어 이용되는 대표적인 예들은 첨부된 도면들을 참조하여 상세히 설명된다. 이러한 상세한 설명은 단지 본 교시들의 측면들을 실시하기 위한 기술 분야에서 상세한 지식을 가진 자를 교시하기 위한 것이고, 청구항들의 범위를 제한하지 않는다. 그러므로, 상세한 설명에 상술된 특징들의 조합들은 넓은 의미에서 교시를 실시할 필요가 없을 수도 있고, 대신에 본 교시들의 특히 대표적인 실시 예들을 설명하기 위해 단지 교시된다.

아래의 설명에서, 설명의 목적으로만 특정 명칭이 본 발명의 완전한 이해를 제공하기 위해 설명된다. 그러나, 이러한 특정 세부 사항들은 본 발명의 사상을 실시하기 위해 필요하지 않는 것은 당업자에게 명백할 것이다.

상세한 설명의 몇몇 부분들은 알고리즘 및 컴퓨터 메모리 내 데이터 비트들에 대한 동작들의 심볼 표현의 측면에서 제공된다. 이들 알고리즘 설명들 및 표현들은 다른 분야의 당업자들에게 테스크의 실체를 효과적으로 전달하기 위해, 데이터 처리 분야의 당업자들에 의해 사용된다. 여기에서 알고리즘은 일반적으로 소망하는 결과에 이르는 단계들에 대한 일관성 있는 순서일 수 있다. 단계들은 물리적 양의 물리적 조작이 필요한 것들이다. 일반적으로, 필수적이진 않지만, 이러한 양들은 저장, 전달, 결합, 비교, 그리고 다르게 조작될 수 있는 전기 또는 자기 신호의 형태를 취한다. 이러한 신호들을 비트들, 값들, 요소들, 심볼들, 특징들, 용어들, 숫자들 등으로 지칭하는 것이 주로 공통적인 사용의 이유로 때때로 편리하게 입증되었다.

그러나, 이들 및 유사한 용어들 모두는 적절한 물리량과 연관되며 단지 이러한 양에 적용되는 편리한 라벨이라는 것을 명심해야 한다. 구체적으로는 아래의 설명으로부터 명백한 바와 같이 달리 명시되지 않는 한, 설명에서, 이러한 “처리”, “컴퓨팅”, “계산”, “결정”, “표시” 등과 같은 용어를 사용하는 논의는 컴퓨터 시스템 또는 컴퓨터 레지스터 및 메모리들 내에서 물리적(전기적) 양으로서 나타나는 데이터를 컴퓨터 시스템 메모리들 또는 레지스터들 또는 다른 정보 스토리지, 전송 또는 표시 장치들 내에서 물리적 양으로서 나타나는 유사한 다른 데이터로 조작 및 변형하는 유사한 전자 컴퓨팅 장치의 활동 및 과정을 나타내는 것으로 이해된다.

본 명세서에서 설명된 알고리즘은 본질적으로 임의의 특정 컴퓨터 또는 다른 장치들과 관련된 것이 아니다. 다양한 일반적인 목적의 시스템들, 컴퓨터 서버들, 또는 개인용 컴퓨터들은 본 명세서의 교시에 따른 프로그램과 함께 사용될 수 있거나 요구된 방법 단계들을 수행하기 위한 보다 특수화된 장치를 구성하는 것이 편리할 수 있다. 이러한 다양한 시스템을 위해 요구되는 구조는 이하의 설명에서 나타날 것이다. 다양한 프로그래밍 언어들이 본 명세서에서 기재된 바와 같이 발명의 교시를 구현하는데 사용될 수도 있는 것을 이해할 수 있을 것이다.

또한, 대표적인 예들에 대한 다양한 특징들 그리고 종속항들은 본 발명의 교시에 대한 유용한 추가적인 실시 예들을 제공하기 위해 명시적이지 않은 그리고 열거되지 않은 방식으로 결합될 수 있다. 또한 모든 값의 범위 또는 독립체들의 그룹들의 암시들은 모든 가능한 중간 값 또는 당해 발명을 제한하는 목적뿐만 아니라 본래의 개시 목적을 위한 중간 독립체들을 개시하는 것이 주목된다. 또한, 명시적 기준 및 도면에 도시된 구성 요소들의 형상은 본 명세서에서 실시되는 방식을 이해할 수 있도록 설계되지만, 치수 및 실시 예에 나타난 형상에 한정되지 않는 것을 유의한다.

데이터 프로세싱 시스템의 종래의 리소스 관리 스킴들은 테스크들, 쓰레드들, CPU들을 수동으로 관리하지 않고, 또는 테스크 각각에 대해 리소스들을 엄격하게 할당하지 않는다. 일 실시 예에서, 테스크(task)는 독립적으로 처리될 수 있는 코드 조각(fragment)을 의미한다. 본 명세서는 종래의 리소스 관리 스킴들에 의해 채택되는 온디맨드 정책 및 정적 매핑 정책과 관련된 상술한 이슈들을 완화하기 위한 새로운 타입의 리소스 관리 스킴을 제공한다. 본 발명의 리소스 관리 스킴은 지정된(given) 워크로드들과 테스크들 하에서 효율적인 리소스들의 할당을 제공할 수 있다.

본 발명의 리소스 관리 스킴은 안정된(balanced) 시스템 리소스 사용량을 달성하기 위해 동적으로 리소스 할당들을 다시 매핑할 수 있다. 본 발명의 리소스 관리 스킴은 시스템의 현재 상태와 테스크들의 특성들에 따라 리소스 아이들 시간을 최소화할 수 있다. 좀 더 구체적으로, 본 발명의 리소스 관리 스킴은 테스크들과 쓰레드 그룹들 사이의 매핑 및 쓰레드 그룹들과 CPU 그룹들 사이의 매핑을 조정할 수 있다. 추가적으로, 본 발명의 리스소 관리 스킴은 리소스 사용량을 좀 더 제어하기 위해 입출력 쓰레드들을 쓰로틀(throttle)할 수 있다.

본 발명의 리소스 관리 스킴은 데이터 프로세싱 엔진들 또는 데이터 스토리지 시스템들에 적용될 수 있다. 일 실시 예에 따르면, 본 발명의 리소스 관리 스킴은 두 개의 매핑들을 관리할 수 있다. 매핑들은 테스크들과 쓰레드들 사이의 제 1 매핑 및 쓰레드들과 CPU 리소스들 사이의 제 2 매핑을 포함할 수 있다. 테스크들 사이의 CPU 리소스들을 안정화함으로써, 동적 리소스 관리 스킴은 향상된 프로세싱 처리량을 제공할 수 있다.

일 실시 예에 따르면, 데이터 프로세싱 엔진이 제공된다. 데이터 프로세싱 엔진은 테스크들과 쓰레드들 사이의 매핑들 및 쓰레드들과 CPU 리소스들 사이의 매핑을 제공하기 위한 다수의 코어(core) 구성 요소들을 포함할 수 있다. 코어 구성 요소들의 예는 시스템 상태 모니터, 작업(job) 상태 모니터, 동적 매퍼(mapper), 입출력(I/O) 핸들러(handler), 그리고 데이터 프로세서를 포함한다. 다만, 본 발명은 이에 제한되지 않는다. 시스템 상태 모니터는 CPU 및 메모리 사용량과 같은 시스템 상태를 모니터하고, 동적 매퍼에 보고할 수 있다. 작업 상태 모니터는 작업들(예를 들어, 입출력 및 계산 테스크들)의 현재 상태를 모니터하고, 작업들의 상태를 동적 매퍼에 보고할 수 있다. 동적 매퍼는 다양한 시스템 파라미터(parameter)들에 기반하여 매핑들을 결정하고, 필요한 경우에 입출력 쓰로틀 값들을 계산할 수 있다. 입출력 핸들러는 동적 매퍼에 의해 정의된 입출력 쓰로틀 값들의 비율로 비동기적으로 입출력을 처리하고, 입출력 테스크들을 다시 스케쥴할 수 있다. 데이터 프로세서는, 예컨대 데이터를 계산하고 데이터 스토리지 매체로 데이터를 기입하고 데이터 스토리지 매체로부터 데이터를 독출하여, 데이터를 처리할 수 있다.

시스템 리소스 관리 스킴들은 온디맨드 할당과 동적 할당의 두 가지 타입들로 분류될 수 있다. 온디맨드 리소스 관리 스킴은 호스트 운영 체제 내의 공정하고 시분할되는 CPU 스케쥴러에 기반하여 계산 리소스들을 활용하는데 적합하다. 도 1은 온디맨드 스킴을 갖는 비동기식(asynchronous) 데이터 프로세싱 어플리케이션의 시스템 활용도를 예시적으로 보여준다. 하지만, 온디맨드 할당 스킴은 종종 입출력과 계산 테스크들 사이의 높은 CPU 경합을 생성하고, 이에 따라 수신되는 테스크들을 실행하기 위한 평균 레이턴시를 증가시킨다. 반면에, 수신되는 테스크들 사이의 리소스들을 분리(isolate)시킴으로써, 정적 할당 스킴은 온디맨드 할당의 CPU 경합 이슈들을 완화하도록 설계된다.

하지만, 정적 할당 스킴은 불충분한 리소스 활용도를 야기할 수 있다. 예를 들어, 입출력 쓰레드들과 계산 쓰레드들은 동일한 CPU 리소스들에 대해 경쟁(compete)할 수 있고, CPU 리소스들은 완전히 활용되지 못할 수 있다. 도 2는 정적-할당(static-assignment) 스킴을 갖는 비동기식 데이터 프로세싱 어플리케이션의 시스템 활용도를 예시적으로 보여준다. 도 2에 도시된 바와 같이, 입출력 쓰레드들 상의 CPU 리소스들을 분리함으로써, 정적 할당 스킴은 낮은 CPU 활용도를 보여줄 수 있다. 입출력 쓰레드들 각각이 분리된 CPU 코어 내에서 동작하기 때문에, 시스템 활용도는 할당된 입출력 쓰레드들을 실행할 때 높은 입출력 처리량을 보여준다. 하지만, CPU 코어들은 할당된 테스크들을 완료한 이후에 아이들 상태가 된다. 입출력 쓰레드들에 대해 아이들 상태가 된 리소스들은 다른 컴퓨팅 테스크들에 의해 활용되지 않는다.

종래의 리소스 할당 스킴들은 테스크들, 쓰레드들, 그리고 컴퓨팅 리소스들 사이의 관계에 의해 표시될 수 있다. 본 발명의 리소스 관리 스킴은 두 개의 분리된 매핑들을 관리함에 의해 향상된 프로세싱 처리량을 제공할 수 있다. 매핑들은 테스크들과 쓰레드 그룹들 사이의 제 1 매핑 및 쓰레드 그룹들과 물리적 CPU들 또는 CPU 코어들의 그룹들 사이의 제 2 매핑을 포함할 수 있다.

도 3은 종래의 온디맨드 스킴에서의 매핑을 예시적으로 보여준다. 온디맨드 모델(300)은 테스크 풀(310), 쓰레드 풀(320), 그리고 CPU 풀(330)을 포함한다. 테스크 풀(310)은 계산 테스크(311a, 311b), 그리고 입출력 테스크(311c)를 포함한다. 쓰레드 풀(320)은 쓰레드(321a~321e)를 포함한다. CPU 풀(330)은 CPU 코어(331a~331d)를 포함한다. 도 3의 예에서, 세 개의 테스크들, 다섯 개의 쓰레드들, 그리고 네 개의 CPU 코어들이 도시되었다. 하지만, 어떠한 수의 테스크들, 쓰레드들, 그리고 CPU 코어들도 테스크 풀(310), 쓰레드 풀(320), 그리고 CPU 풀(330) 내에 포함될 수 있다는 것은 쉽게 이해될 것이다.

온디맨드 모델(300)은 미리 정의된 수의 쓰레드(도 3의 예에서, 쓰레드(321a~321e))를 포함하는 쓰레드 풀(321)을 유지한다. 테스크(예를 들어, 계산 테스크(311a, 311b), 그리고 입출력 테스크(311c))가 수신되면, 데이터 프로세싱 엔진은 테스크를 테스크 풀(310)의 큐(queue)(예를 들어, FIFO(First-in First-Out 버퍼) 내에 위치시킨다. 그리고, 데이터 프로세싱 엔진은 테스크를 쓰레드 풀(320)로부터의 하나의 쓰레드(321)와 연관시킨다. 쓰레드와 코어 사이에 매핑이 없기 때문에, 쓰레드(321)는 쓰레드 풀(320)로부터 임의로 선택될 수 있다. 테스크(311)들과 쓰레드(321)들은 각각 테스크(311)들과 쓰레드(321)들이 위치한 순서대로 테스크 풀(310)과 쓰레드 풀(320)로부터 제거된다. 데이터 프로세싱 시스템은 특정 쓰레드를 실행하기 위해 CPU 풀(330)로부터의 CPU 코어(331)를 연관시킨다. CPU 코어(331)는 호스트 운영 체제의 CPU 스케쥴러에 기반하여 CPU 풀(330)로부터 임의로 선택될 수 있다. 테스크의 타입을 인지하지 않고서는, 도 1에 도시된 입출력 쓰레드 예시와 유사하게, 호스트 운영 체제는 쓰레드들 또는 테스크들을 우선순위화(prioritize)하지 못하고, 특정 쓰레드의 성능을 보존하도록 시도하지 못한다.

호스트 운영 체제 내의 CPU 스케쥴러는 다양한 파라미터들과 상태(condition)들에 기반하여 쓰레드들을 우선순위화할 수 있다. 예를 들어, 쓰레드 각각의 우선순위는 쓰레드 자체의 설계 목표들(예를 들어, 공정성(fairness) 또는 처리량의 최대화 등)에 의해 계산된다. CPU 경합이 발생하면, 성능 병목 현상(bottleneck)을 식별하고 해소하기가 어려워 진다. 이는, CPU 스케쥴러가 얼마나 많은 입출력 쓰레드들이 장치를 포화(saturate) 시키기 위해 필요한지를 알 수 없고, 따라서 입출력 쓰레드들의 생성이나 해체(destruction)를 제어하지 못하기 때문이다. 이하에서 설명되는 바와 같이, 계산 및 입출력 테스크들의 성능 특성들에 기반하여 쓰레드들과 CPU 코어들 사이의 매핑과 쓰레드들의 수를 동적으로 조정함에 의해, 본 발명의 리소스 관리 스킴은 CPU 경합을 완화할 수 있다.

테스크들, 쓰레드들, 그리고 CPU 코어들 사이의 대표적인 관계들은 테스크들의 수(s), 쓰레드들의 수(t), 그리고 CPU 코어들의 수(p) 로 기술될 수 있다. 온디맨드 모델(300)은 어떠한 s도 어떠한 t와 매핑되도록 하고, 어떠한 t도 어떠한 p와 매핑될 수 있도록 한다. 온디맨드 모델(300)의 매핑들은 다음과 같이 표현될 수 있다.

테스크들(Tasks) : 쓰레드들(Threads) = s : t, 그리고

쓰레드들 : CPU 코어들 = t : p.

매핑들 상의 제한은 없고, 따라서, CPU 경합은 온디맨드 모델(300)에 따라 발생할 수 있다.

도 4는 종래의 정적 할당 스킴에서의 매핑을 예시적으로 보여준다. 정적 할당 모델(400)은 테스크 풀(410), 쓰레드 풀(420), 그리고 CPU 풀(430)을 포함한다. 테스크 풀(410)은 계산 테스크(411a, 411b), 그리고 입출력 테스크(411c)를 포함한다. 쓰레드 풀(420)은 쓰레드(421a~421d)를 포함한다. CPU 풀(430)은 CPU 코어(431a, 431b)를 포함합니다. 쓰레드(421a, 421b)는 쓰레드 그룹(422a) 내에서 함께 그룹화되고, 쓰레드(421c, 421d)는 쓰레드 그룹(422b) 내에서 함께 그룹화된다. 테스크 풀(410), 쓰레드 풀(420), 그리고 CPU 풀(430) 내에 포함된 테스크(411)의 수, 쓰레드(421)의 수, 그리고 CPU 코어(431)의 수는 예시적인 목적으로 도시되었다. 즉, 어떠한 수의 테스크들, 쓰레드들, CPU 코어들도 테스크 풀(410), 쓰레드 풀(420), 그리고 CPU 풀(430) 내에 존재하거나 할당될 수 있음은 쉽게 이해할 수 있을 것이다.

정적 할당 스킴(400)은 테스크(411) 각각에 대해 CPU 리소스들을 분리한다. 테스크(411)는 쓰레드 풀(420)로부터 선택된 하나의 쓰레드 그룹(422)과 연관된다. 하나의 쓰레드 그룹(422)은 특정 CPU 코어(431)에 의해 수행되도록 스케쥴된다. 쓰레드 그룹(422)의 크기는 하나일 수 있다. 이 경우, 오직 하나의 쓰레드(421)가 각각의 코어(431) 내에서 실행될 수 있다. 단일 CPU 코어(431)와 단일 크기의 쓰레드 그룹(422)의 연관성 및 단일 크기의 쓰레드 그룹(422)은 CPU 경합을 최소화할 수 있다. 하지만, 도 2의 예시에서 도시된 바와 같이, 특정 할당된 테스크(411)가 할당된 CPU 코어(431)를 완전히 활용하지 못하는 경우, 정적 할당 모델(400)은 오버헤드(overhead)를 야기할 수 있다. 정적 할당 스킴(400)의 매핑들은 다음과 같이 표현될 수 있다.

테스크들 : 쓰레드 그룹 = s : 1, 그리고

쓰레드 그룹 : CPU 그룹 = 1 : 1.

각각의 CPU 코어(431)는 쓰레드 그룹(422) 내에 고정된 수의 미리 할당된 쓰레드(421)를 가질 수 있고, 테스크(411)는 쓰레드 그룹(422)에 매핑된다.

일 실시 예에 따르면, 동적 매핑 스킴은 도 3의 온디맨드 모델(300)과 도 4의 정적 할당 모델(400)이 갖는 이슈들을 완화시키기 위해 사용된다. 도 5는 본 발명의 일 실시 예에 따른 동적 매핑 스킴을 예시적으로 보여준다. 동적 매핑 모델(500)은 테스크 풀(510), 쓰레드 풀(520), 그리고 CPU 풀(530)을 포함한다. 테스크 풀(510)은 복수의 테스크(511)를 포함한다. 쓰레드 풀(520)은 복수의 쓰레드 그룹(522)으로 그룹화된 복수의 쓰레드(521)를 포함한다. CPU 풀(530)은 복수의 CPU 그룹(532)으로 그룹화된 복수의 CPU 코어(531)를 포함한다.

동적 매퍼(550)는 복수의 테스크(511)를 쓰레드 풀(520) 내의 쓰레드 그룹(522)에 매핑할 수 있다. 일 실시 예에 따르면, 입출력 테스크들과 CPU 테스크들의 혼합(mixture)은 동일한 쓰레드 그룹(522)으로 매핑될 수 있다. 또한, 동적 매퍼(550)는 쓰레드 풀(520) 내의 쓰레드 그룹(522)을 CPU 풀(530) 내의 CPU 그룹(532)으로 매핑할 수 있다. 복수의 쓰레드 그룹(522)과 복수의 CPU 그룹(532)의 비율은 1:1이 아닐 수 있다.

다양한 파라미터들에 기반하여, 동적 매퍼(550)는 복수의 테스크(511)와 복수의 쓰레드 그룹(522) 사이의 매핑들 및 복수의 쓰레드 그룹(522)과 복수의 CPU 그룹(532) 사이의 매핑들을 변경할 수 있다. 이러한 파라미터의 예시들은 복수의 테스크(511)의 특성들, 시스템 상태(예를 들어, CPU 및 디스크 활용도), 그리고 시스템의 작업 상태(예를 들어, 남은 테스크들의 수)를 포함한다. 다만, 본 발명은 이에 제한되지 않는다. 본 발명의 동적 매핑 모델(500)의 매핑들은 다음과 같이 표현될 수 있다.

테스크들 : 쓰레드 그룹들 = s : 1, 그리고

쓰레드 그룹들 : CPU 그룹들 = T : P.

쓰레드 그룹들의 수(T)와 CPU 그룹들의 수(P)는 서로 동일하거나 다를 수 있다. 예를 들어, 쓰레드 그룹들의 수(T)는 CPU 그룹들의 수(P) 보다 클 수 있다. 또는, CPU 그룹들의 수(P)는 쓰레드 그룹들의 수(T)보다 클 수 있다.

운영 체제가 특정 리소스가 충분히 활용되지 않기 시작한다는 것을 판단한 경우, 동적 매핑 모델(500)은 복수의 테스크(511)와 복수의 쓰레드 그룹(522) 사이의 매핑 및 복수의 쓰레드 그룹(522)과 복수의 CPU 그룹(532) 사이의 매핑들을 재지정할 수 있다. 예를 들어, 도 2의 경우에서, 데이터 프로세싱 엔진의 시스템 상태 모니터 및/또는 작업 상태 모니터가 입출력 쓰레드들에 대한 CPU 그룹들의 불충분한 활용을 감지한 경우, 6초 뒤에, 입출력 쓰레드들에 대한 CPU 그룹들은 쓰레드들을 계산하기 위해 다시 매핑될 수 있다. 입출력 쓰레드들이 완료되기를 기다리는 계산 쓰레드가 있는 경우, 입출력 쓰레드들의 우선순위를 증가시킴으로써, 데이터 프로세싱 엔진의 동적 매퍼는 추가적인 CPU 그룹들을 할당하거나, 입출력 쓰레드들에 대한 입출력 쓰로틀 값들을 감소시킬 수 있다.

입출력 테스크는 높은 우선순위의 입출력 테스크이거나, 낮은 우선순위의 입출력 테스크일 수 있다. 높은 우선순위의 입출력 테스크는 이전에 디스패치된(dispatched) 낮은 우선순위의 입출력 테스크보다 빠르게 서비스될 수 있다. 데이터 프로세싱 시스템은 입출력 테스크들의 우선순위 레벨을 유지할 수 있다. 일 실시 예에서, 낮은 우선순위의 입출력 테스크들은 미리 결정된 입출력 비율(예를 들어, 입출력 프로세싱 비율)로 쓰로틀될 수 있고, 이에 따라 낮은 우선순위의 입출력 테스크들은 CPU 리소스들의 부족을 겪지 않는다. 다만, 낮은 우선순위의 테스크들은 데이터 프로세싱 시스템의 입출력 처리량에 영향을 줄 수 있다. 하지만, 적어도 낮은 우선순위의 입출력 테스크들의 입출력 비율은 결정론적으로 데이터 프로세싱 시스템의 입출력 처리량을 조절할 수 있다.

도 6은 본 발명의 일 실시 예에 따른 데이터 프로세싱 엔진의 예시적인 블록도를 보여준다. 호스트 컴퓨터(601)는 하나 이상의 CPU 코어를 포함하는 CPU(615)와 메모리(620)를 포함한다. 비록 하나의 CPU(615)가 도 6에 도시되었지만, 본 명세서의 개시를 벗어나지 않고, 호스트 컴퓨터(601)가 복수의 CPU를 포함할 수 있고 CPU 각각이 하나 이상의 CPU 코어를 포함할 수 있다는 것은 쉽게 이해될 수 있다. 메모리(620)는 운영 체제(625)와 데이터 프로세싱 엔진(630)을 포함한다. 데이터 프로세싱 엔진(630)은 작업 상태 모니터(631), 시스템 상태 모니터(632), 작업 수신기(633), 그리고 동적 매퍼(650)를 포함하는 다양한 모듈들을 포함한다. 다만, 본 발명은 이에 제한되지 않는다. 데이터 프로세싱 엔진(630)은 복수의 입출력 핸들러(671)와 복수의 데이터 프로세서(672)를 포함하는 쓰레드 그룹들(670)을 추가적으로 포함한다. 복수의 입출력 핸들러(671)와 복수의 데이터 프로세서(672)는 각각 쓰레드들, 프로세싱 입출력 요청들 및 데이터를 나타낼 수 있다.

호스트 컴퓨터(601)는 작업 요청들(605)을 수신할 수 있고 데이터 스토리지 장치들(610)(예를 들어, SSD(Solid-State Drive)들과 HDD(Hard Disk Drive)들)과 통신할 수 있다. 작업 요청들(605)은 로컬에서 실행되는 프로세스에 의해 생성되거나 외부에서 생성될 수 있다. 작업 요청들(605)은 네트워크 통신 채널(TCP/IP(Transmission Control Protocol/Internet Protocol)와 RDMA(Remote Direct Memory Access))을 통해 클라이언트(client)로부터 수신될 수 있다. 종래의 데이터 프로세싱 엔진과 비교하여, 데이터 프로세싱 엔진(630)은 시스템 상태 모니터(632), 동적 핸들러(650), 그리고 복수의 입출력 핸들러(671)를 제공하고, 새로 소개되거나 변형된 복수의 데이터 프로세서(672)를 제공한다.

동적 매퍼(650)는 어플리케이션 테스크들과 쓰레드 그룹들 사이의 매핑과 쓰레드 그룹들과 CPU 그룹들 사이의 매핑을 결정할 수 있다. 또한, 동적 매퍼(650)는 CPU 리소스들의 공유된 사용에 대한 쓰로틀 입출력들을 계산할 수 있다. 시스템 상태 모니터(632)는 다양한 시스템 성능 변수들(예를 들어, CPU(615) 및 메모리(620)의 상태, 네트워크 활용도, 디스크 활용도, CPU 사용량이 많은 프로세스들의 수 등)을 수집할 수 있다. 시스템 성능 변수들을 수집하기 위해, 시스템 상태 모니터(632)는 기존의 시스템 유틸리티(utility)들(예를 들어, sar, hdparm, top 그리고 다른 유틸리티 등)을 이용하여 구현될 수 있다. 작업 상태 모니터(631)는 작업들의 상태(예를 들어, 처리된 테스크들의 수, 대기중인 작업들의 수 등)를 모니터하고, 수집하고, 보고할 수 있다.

도 7은 본 발명의 일 실시 예에 따른 동적 매퍼(mapper)의 예시적인 순서도를 보여준다. S701에서, 구성의 유효성을 검사하고, 모니터가 필요한 서브 구성 요소들(예를 들어, 시스템 상태 모니터)에의 액세스를 검증하고, 정보(예를 들어, 성능 파라미터들)를 수집하기 위해 데이터 구조를 준비하고, 정보의 수집을 시작하기 위해 쓰레드의 모니터링을 시작함에 의해, 동적 매퍼는 초기화된다. 초기화된 이후, S702에서, 동적 매퍼는 시스템 상태 모니터로부터 다양한 성능 파라미터들을 수집하기 시작한다. 성능 파라미터들의 예시들은 데이터 프로세싱 시스템의 CPU 코어들의 DPR(Data Processing Rate)과 IOR(I/O Processing Rate)를 포함한다. 다만, 본 발명은 이에 제한되지 않는다. 동적 매퍼는 IOR를 DPR에 가능한 가깝게 유지함으로써 CPU 코어들을 포화시키도록 시도한다. S703에서 IOR이 DPR과 동일하거나 큰 경우에, 동적 매퍼는 입출력 테스크들과 계산 테스크들에 할당된 CPU 코어들의 수를 계산한다(S705). S703에서 DPR이 IOR보다 큰 경우, 동적 매퍼는 장치들(예를 들어, 도 6의 스토리지 장치들(610))이 포화되었는지 여부를 확인한다(S704). 장치는 장치의 입출력 대역폭 또는 IOPS(Input/Output Operations Per Second)들이 완전히 활용되는 경우에 포화된다. 따라서, 포화된 장치에 추가적인 입출력 커맨드들을 전송하는 것은 어떠한 성능 이득도 가져올 수 없을 것이다. S704에서 장치들이 포화되지 않으면, 동적 매퍼는 또한 입출력 테스크들과 계산 테스크들에 대해 할당된 CPU 코어들의 수를 계산한다(S705). S706에서, 입출력 테스크들 및 계산 테스크들에 할당된 CPU 코어들의 수에 기반하여, 동적 매퍼는 입출력 및 계산 쓰레드들의 수 및/또는 CPU 그룹들에의 입출력과 계산 쓰레드들의 연관도(affinity)를 조정한다. 예를 들어, 하나 이상의 쓰레드들을 하나의 쓰레드 그룹으로부터 다른 쓰레드 그룹으로 이동시킴으로써, 동적 매퍼는 쓰레드 그룹 내의 쓰레드들의 수를 증가시키거나 감소시킬 수 있다. 동적 매퍼는 쓰레드 그룹과 다른 CPU 그룹 사이의 매핑을 변경함으로써 CPU 그룹으로의 쓰레드 그룹의 연관도를 변경할 수 있다. 이러한 성능 변수들의 예시들은 CPU 활용도, 장치 활용도, 블로킹(blocking) 동작들의 존재, 그리고 테스크들의 레이턴시-민감도(sensitivity) 등을 포함한다. 다만, 본 발명은 이에 제한되지 않는다. S707에서, 특히 DPR이 IOR보다 낮은 경우, 입출력 쓰로틀 값들을 조정함으로써, 동적 매퍼는 추가적으로 IOR을 낮출 수 있다. 그리고 입출력 쓰레드는 다른 계산 쓰레드들과 CPU 코어들을 공유한다. 프로세스들은, 데이터 사용량의 성능 변수들에 기반하여, 입출력 테스크들과 계산 테스크들 사이의 CPU 리소스들을 지속적으로 안정화하는 작업을 반복한다. 동적 매퍼는 호스트 운영 체제의 프로세스 또는 쓰레드로서 구현될 수 있다.

도 8은 본 발명의 일 실시 예에 따른 입출력(I/O) 핸들러(handler)의 예시적인 순서도를 보여준다. 입출력 핸들러는 데이터 프로세싱 시스템에 대한 더 높은 입출력 성능을 위해 입출력 요청들을 비동기적으로 처리할 수 있다. 일 실시 예에서, 데이터 프로세싱 시스템은 입출력 테스크들을 처리하기 위한 입출력 큐와 계산 테스크들을 처리하기 위한 데이터 큐를 포함한다. S801에서, 입출력 핸들러는 입출력 테스크를 파스(parse)한다. S802에서, 입출력 핸들러는 파스된(parsed) 입출력 테스크를 입출력 큐에 대기(queue)시킨다. S803에서, 입출력 핸들러는 데이터 큐가 가득 찼는지 여부를 확인한다. S803에서 데이터 큐가 가득 차지 않은 경우(아니오 방향), 입출력 핸들러는 입출력 테스크를 이슈한다(S805). S804에서, 입출력 핸들러는 데이터 큐가 완료된 입출력 테스크를 갖는지 여부를 확인한다. S803에서 데이터 큐가 가득 찬 경우(예 방향), 입출력 핸들러는 데이터 큐가 완료된 입출력 테스크들을 갖는지 여부를 확인한다(S804). S804에서 데이터 큐가 완료된 입출력 테스크들을 갖는 경우(예 방향), 입출력 핸들러는 입출력 테스크를 데이터 큐에 대기(queue)시킨다(S806). S804에서 데이터 큐가 완료된 I/O 테스크들을 갖지 않거나(아니오 방향) 완료된 입출력 테스크들을 데이터 큐에 대기시킨 이후, 입출력 핸들러는 쓰로틀 값들을 적용한다(S807). 그리고, S808에서, 입출력 테스크의 매핑이 변경된 경우, 입출력 핸들러는 입출력 테스크를 다시 스케쥴링한다. 입출력 핸들러는 너무 많은 리소스가 입출력 테스크에 할당된 경우 쓰로틀 값들을 적용한다. 입출력 테스크들의 수는 하나로 줄어들 수 있지만, 입출력 테스크들의 IOR는 여전히 DPR보다 높을 수 있다. 이러한 경우, 특정 주기(frequency)로 미리 정해진 기간 동안 슬립(sleep) 모드로 진입함으로써, 입출력 핸들러는 입출력 테스크들의 CPU 소비를 추가적으로 줄인다. 일 실시 예에서, 주파수와 슬립 시간의 길이는 쓰로틀 값으로서 지칭된다. 쓰로틀 값들은 IOR과 DRP를 안정화하기 위해 현재의 IOR과 DRP를 기반으로 계산될 수 있다. 계산된 이후, 쓰로틀 값들이 0보다 큰 경우, 입출력 핸들러는 새로운 쓰로틀 값들을 입출력 테스크에 적용할 수 있다.

S807에서 쓰로틀 값들의 어플리케이션은 공유된 모드 내에 적용될 수 있다. 예를 들어, 입출력 모니터에 의해 설정된 쓰로틀 값들에 기반하여, 입출력 핸들러는 슬립 시간과 큐 깊이(depth)를 조정할 수 있다. S808에서 입출력 테스크들을 다시 스케쥴링하는 것은 전용 모드에서 사용될 수 있다. 입출력 모니터가 입출력 핸들러들에 대한 CPU 연관도를 변경할 때, 입출력 테스크들을 다시 스케쥴링할 수 있다.

도 9는 본 발명의 일 실시 예에 따른 데이터 프로세서의 예시적인 순서도를 보여준다. S901에서, 데이터 프로세서는 계산 테스크에 대한 데이터를 데이터 큐로부터 해제(dequeue)한다. S902에서, 데이터 프로세서는 DPR에서 데이터를 처리한다. 예컨대 계산 테스크의 매핑이 다른 쓰레드 그룹으로 변경되거나 계산 테스크가 매핑된 쓰레드 그룹이 다른 CPU 그룹으로 매핑된 경우, S903에서, 데이터 프로세서는 계산 테스크를 다시 스케쥴할 수 있다. 데이터 프로세서는 데이터가 처리되는 동안 블로킹 동작들에 의해 슬립 모드로 진입할 수 있다. 입출력 모니터가 데이터 프로세서에 대한 CPU 연관도를 변경할 때, 데이터 프로세서는 계산 테스크를 다시 스케쥴할 수 있다.

본 명세서는, 현재의 시스템 리소스 사용량에 기반하여, 데이터 프로세싱 시스템 내에서 입출력 테스크들과 계산 테스크들 사이의 CPU 리소스들을 동적으로 안정화할 수 있는 동적 매핑 스킴을 기술한다. 본 발명의 동적 매핑은 물리적인 CPU 코어들과 쓰레드들 사이의 매핑을 조정할 수 있고, 어플리케이션 테스크들과 쓰레드들 사이의 매핑들을 조정할 수 있다. 본 발명의 동적 매핑 스킴은, 향상된 데이터 프로세싱 처리량을 위해, 백그라운드(background) 입출력 쓰레드들의 우선순위를 조정할 수 있고, 다양한 타입의 테스크들 각각에 대한 쓰레드들의 수를 조정할 수 있다. 테스크들을 쓰레드 그룹들로 매핑하고 쓰레드 그룹들을 CPU 그룹들로 매핑하기 위한, 본 발명의 동적 매핑 스킴은 다양한 우선순위들 또는 종속성을 갖는 동시에 발생하는 복수의 테스크들(예를 들어, 입출력과 계산들)을 갖는 어떠한 서버 어플리케이션들에도 적용될 수 있다.

일 실시 예에 따르면, 방법은:

복수의 쓰레드(thread) 그룹을 포함하는 쓰레드 풀(pool)을 제공하는 단계;

복수의 CPU(Central Processing Unit) 그룹을 포함하는 CPU 풀을 제공하는 단계;

입출력 테스크(task)들과 계산(compute) 테스크들을 포함하는 복수의 테스크를 수신하는 단계;

복수의 테스크 각각을 상기 쓰레드 풀 내의 적어도 하나의 쓰레드 그룹으로 매핑(mapping)하는 단계; 그리고

상기 쓰레드 풀 내의 상기 복수의 쓰레드 그룹 각각을 상기 CPU 풀 내의 적어도 하나의 CPU 그룹에 매핑하는 단계를 포함한다.

상기 복수의 쓰레드 그룹 각각은 하나 이상의 쓰레드를 포함한다. 상기 복수의 CPU 그룹 각각은 하나 이상의 CPU 코어를 포함한다. 상기 복수의 테스크와 상기 복수의 쓰레드 그룹 사이의 매핑과 상기 복수의 쓰레드 그룹과 상기 복수의 CPU 그룹 사이의 매핑은 성능 변수들에 기반하여 동적으로 변경된다.

상기 성능 변수들은 CPU 활용도(utilization), 장치 활용도, 블로킹(blocking) 동작들의 존재, 그리고 테스크들의 레이턴시-민감도(latency-sensitivity) 중 적어도 하나를 포함할 수 있다.

적어도 하나의 상기 입출력 테스크와 적어도 하나의 상기 계산 테스크는 동일한 쓰레드 그룹으로 매핑될 수 있다.

상기 방법은:

데이터 프로세싱(processing) 시스템(system)의 CPU 코어들의 DPR(Data Processing Rate)과 IOR(I/O Processing Rate)을 포함하는 성능 파라미터들을 수신하는 단계; 그리고

상기 IOR이 상기 DPR보다 클 때, 상기 복수의 테스크와 상기 복수의 쓰레드 그룹 사이의 매핑과 상기 복수의 쓰레드 그룹과 상기 복수의 CPU 그룹 사이의 매핑을 조정하는 단계를 더 포함한다.

상기 방법은:

상기 입출력 테스크들과 상기 계산 테스크들에 대해 할당된 CPU 코어들의 수를 계산하는 단계; 그리고

상기 입출력 테스크들과 상기 계산 테스크들에 대해 할당된 상기 CPU 코어들의 수를 기초로, 상기 복수의 CPU 그룹에 대한 상기 복수의 쓰레드 그룹의 연관도(affinity) 및 상기 복수의 쓰레드 그룹의 수를 조정하는 단계를 더 포함할 수 있다.

상기 방법은, 쓰레드들을 제 1 쓰레드 그룹으로부터 제 2 쓰레드 그룹으로 이동시킴으로써, 쓰레드 그룹 내의 쓰레드들의 수를 감소시키거나 증가시키는 단계를 더 포함할 수 있다.

상기 방법은, 쓰레드 그룹과 제 2 CPU 그룹 사이의 매핑을 변경함으로써, 제 1 CPU 상기 쓰레드 그룹에 대한 상기 쓰레드 그룹의 상기 연관도를 변경하는 단계를 더 포함할 수 있다.

상기 방법은 상기 IOR과 상기 DPR을 안정화(balancing)하기 위해 입출력 쓰로틀(throttle) 값들을 조정하는 단계를 더 포함할 수 있다.

상기 방법은:

상기 입출력 테스크들을 프로세싱하기 위한 입출력 큐(queue) 및 상기 계산 테스크들을 프로세싱하기 위한 데이터 큐를 제공하는 단계;

입출력 테스크를 파싱(parsing)하고 상기 파싱된(parsed) 입출력 테스크를 상기 입출력 큐에 대기시키는(queueing) 단계;

상기 데이터 큐가 가득 차지 않은 경우, 상기 입출력 테스크를 이슈(issue)하는 단계; 그리고

상기 데이터 큐가 완료된 입출력 테스크를 포함하는 경우, 상기 입출력 테스크를 데이터 큐에 대기시키는 단계를 더 포함할 수 있다.

상기 방법은 쓰로틀 값들을 적용하는 단계; 그리고

상기 입출력 테스크를 다시 스케쥴링(scheduling)하는 단계를 더 포함할 수 있다.

상기 방법은: 계산 테스크에 대한 데이터를 상기 데이터 큐로부터 해제(dequeue)하는 단계; 상기 데이터를 상기 DPR에서 프로세싱하는 단계; 그리고 상기 계산 테스크의 매핑이 변경되는 경우, 상기 계산 테스크를 다시 스케쥴링하는 단계를 더 포함할 수 있다.

다른 실시 예에 따르면, 데이터 프로세싱 엔진은:

데이터 프로세싱 시스템의 성능 변수들을 모니터(monitor)하도록 구성된 시스템 상태 모니터; 그리고

입출력 테스크들과 계산 테스크들을 포함하는 복수의 테스크, 쓰레드 풀 내의 복수의 쓰레드 그룹, CPU 풀 내의 복수의 CPU 그룹을 매핑하도록 구성된 동적(dynamic) 매퍼를 포함하되,

상기 복수의 쓰레드 그룹은 하나 이상의 입출력 핸들러(handler)와 하나 이상의 데이터 프로세서를 포함한다. 상기 동적 매퍼는 상기 복수의 테스크 각각을 상기 쓰레드 풀 내의 상기 복수의 쓰레드 그룹의 쓰레드 그룹에 매핑하도록 구성된다. 상기 동적 매퍼는 상기 쓰레드 풀 내의 상기 복수의 쓰레드 그룹 각각을 상기 CPU 풀 내의 상기 복수의 CPU 그룹의 적어도 하나의 CPU 그룹에 매핑하도록 구성된다. 상기 복수의 테스크와 상기 복수의 쓰레드 그룹 사이의 매핑과 상기 복수의 쓰레드 그룹과 상기 복수의 CPU 그룹 사이의 매핑은 상기 성능 변수들에 기초하여 동적으로 변경된다.

상기 성능 변수들은 CPU 활용도, 장치 활용도, 블로킹 동작들의 존재, 그리고 테스크들의 레이턴시-민감도 중 적어도 하나를 포함할 수 있다.

상기 동적 매퍼는 하나 이상의 입출력 테스크와 하나 이상의 계산 테스크를 동일한 쓰레드 그룹으로 매핑할 수 있다.

상기 동적 매퍼는:

데이터 프로세싱 시스템의 CPU 코어들의 DPR과 IOR을 포함하는 성능 파라미터들을 수신하고;

상기 IOR이 상기 DPR보다 클 때, 상기 복수의 테스크와 상기 복수의 쓰레드 그룹 사이의 매핑과 상기 복수의 쓰레드 그룹과 상기 복수의 CPU 그룹 사이의 매핑을 조정하도록 구성될 수 있다.

상기 동적 매퍼는:

상기 입출력 테스크들과 상기 계산 테스크들에 할당된 CPU 코어들의 수를 계산하고; 그리고

상기 입출력 테스크들과 상기 계산 테스크들에 대해 할당된 상기 CPU 코어들의 수를 기초로, 상기 복수의 CPU 그룹에 대한 상기 복수의 쓰레드 그룹의 연관도 및 상기 복수의 쓰레드 그룹의 수를 조정하도록 구성될 수 있다.

상기 동적 매퍼는 상기 IOR과 상기 DPR을 안정화하기 위해 입출력 쓰로틀 값들을 조정하도록 구성될 수 있다.

상기 입출력 핸들러 각각은:

상기 입출력 테스크를 프로세싱하기 위한 입출력 큐와 상기 계산 테스크들을 프로세싱하기 위한 데이터 큐를 제공하고;

입출력 테스크를 파싱하고 상기 파싱된 입출력 테스크를 상기 입출력 큐 내에 대기시키고;

상기 데이터 큐가 가득 차지 않은 경우 상기 입출력 테스크를 이슈하고; 그리고

상기 데이터 큐가 완료된 입출력 테스크를 포함하는 경우, 상기 입출력 테스크를 상기 데이터 큐로 대기키시도록 구성될 수 있다.

상기 입출력 핸들러 각각은: 쓰로틀 값들을 적용하고; 상기 입출력 테스크를 다시 스케쥴링하도록 구성될 수 있다.

상기 데이터 프로세서 각각은:

계산 테스크에 대한 데이터를 상기 데이터 큐로부터 대기 해제하고; 상기 데이터를 상기 DPR에서 프로세싱하고; 그리고 상기 계산 테스크의 매핑이 변경되는 경우, 상기 계산 테스크를 다시 스케쥴링하도록 구성될 수 있다.

이상에서, 상술한 예시적인 실시 예들은 데이터 프로세싱 시스템들 내에서 계산 및 입출력 리소스를 동적으로 관리하기 위한 시스템 및 방법을 구현하기 위한 다양한 실시 예들을 설명하기 위해 기술되었다. 개시된 예시적인 실시 예들로부터의 다양한 변형들 및 이탈(departure)들은 본 기술 분야의 통상의 지식을 가진 자들에 의해 수행될 수 있다. 본 발명의 범위 내에 존재하도록 의도된 기술 구성은 다음의 청구범위에서 기술될 것이다.

Claims

데이터 프로세싱 엔진의 리소스(resource) 관리 방법에 있어,
복수의 쓰레드(thread) 그룹을 포함하는 쓰레드 풀(pool)을 제공하는 단계;
복수의 CPU(Central Processing Unit) 그룹을 포함하는 CPU 풀을 제공하는 단계;
입출력 테스크(task)들과 계산(compute) 테스크들을 포함하는 복수의 테스크를 수신하는 단계;
상기 복수의 테스크 각각을 상기 쓰레드 풀 내의 적어도 하나의 쓰레드 그룹으로 매핑(mapping)하는 단계; 그리고
상기 쓰레드 풀 내의 상기 복수의 쓰레드 그룹 각각을 상기 CPU 풀 내의 적어도 하나의 CPU 그룹에 매핑하는 단계를 포함하되,
상기 복수의 쓰레드 그룹 각각은 하나 이상의 쓰레드를 포함하고, 상기 복수의 CPU 그룹 각각은 하나 이상의 CPU 코어를 포함하고, 상기 복수의 테스크와 상기 복수의 쓰레드 그룹 사이의 매핑 및 상기 복수의 쓰레드 그룹과 상기 복수의 CPU 그룹 사이의 매핑은 성능 변수들(variables)에 기반하여 동적으로 변경되는 방법.
제 1 항에 있어,
상기 성능 변수들은 CPU 활용도(utilization), 장치 활용도, 블로킹(blocking) 동작들의 존재, 그리고 테스크들의 레이턴시-민감도(latency-sensitivity) 중 적어도 하나를 포함하는 방법.
제 1 항에 있어,
적어도 하나의 입출력 테스크와 적어도 하나의 계산 테스크는 동일한 쓰레드 그룹으로 매핑되는 방법.
제 1 항에 있어,
데이터 프로세싱(processing) 시스템의 CPU 코어들의 DPR(Data Processing Rate)과 IOR(I/O Processing Rate)을 포함하는 성능 파라미터들을 수신하는 단계; 그리고
상기 IOR이 상기 DPR보다 클 때, 상기 복수의 테스크와 상기 복수의 쓰레드 그룹 사이의 매핑 및 상기 복수의 쓰레드 그룹과 상기 복수의 CPU 그룹 사이의 매핑을 조정하는 단계를 더 포함하는 방법.
제 4 항에 있어,
상기 입출력 테스크들과 상기 계산 테스크들에 대해 할당된 CPU 코어들의 수를 계산하는 단계; 그리고
상기 입출력 테스크들과 상기 계산 테스크들에 대해 할당된 상기 CPU 코어들의 수를 기초로, 상기 복수의 CPU 그룹에 대한 상기 복수의 쓰레드 그룹의 연관도(affinity) 및 상기 복수의 쓰레드 그룹의 수를 조정하는 단계를 더 포함하는 방법.
제 5 항에 있어,
쓰레드들을 제 1 쓰레드 그룹으로부터 제 2 쓰레드 그룹으로 이동시킴으로써, 쓰레드 그룹 내의 쓰레드들의 수를 감소시키거나 증가시키는 단계를 더 포함하는 방법.
제 5 항에 있어,
쓰레드 그룹과 제 1 CPU 그룹 사이의 매핑을 변경함으로써, 제 2 CPU 그룹에 대한 상기 쓰레드 그룹의 상기 연관도를 변경하는 단계를 더 포함하는 방법.
제 4 항에 있어,
상기 IOR과 상기 DPR을 안정화(balancing)하기 위해 입출력 쓰로틀(throttle) 값들을 조정하는 단계를 더 포함하는 방법.
제 1 항에 있어,
상기 입출력 테스크들을 프로세싱하기 위한 입출력 큐(queue) 및 상기 계산 테스크들을 프로세싱하기 위한 데이터 큐를 제공하는 단계;
입출력 테스크를 파싱(parsing)하고 상기 파싱된(parsed) 입출력 테스크를 상기 입출력 큐에 대기시키는(queueing) 단계;
상기 데이터 큐가 가득 차지 않은 경우, 상기 입출력 테스크를 이슈(issue)하는 단계; 그리고
상기 데이터 큐가 완료된 입출력 테스크를 포함하는 경우, 상기 입출력 테스크를 상기 데이터 큐에 대기시키는 단계를 더 포함하는 방법.
제 9 항에 있어,
쓰로틀 값들을 적용하는 단계; 그리고
상기 입출력 테스크를 다시 스케쥴링(scheduling)하는 단계를 더 포함하는 방법.