[engine] 로그 개수에 맞는 쓰레드 생성

Related issue

Result

이전에 Worker를 사용하여 병렬적으로 로그를 받아오는 기능을 구현했습니다. 이 과정에서 항상 컴퓨터 코어 수 - 1개의 쓰레드를 생성하여 로그를 받아왔는데 멘토님께서 이는 메모리를 과하게 사용하는 매우 비효율적인 작업이라고 지적해주셨습니다.

따라서 로그 수에 따른 적절한 쓰레드 개수를 찾기 위해 사용하는 소요되는 메모리 양과 걸리는 시간을 평가하였습니다.

setInterval(() => {
    const memoryUsage = process.memoryUsage();
    const rssUsage = memoryUsage.rss / 1024 / 1024; // RSS 메모리(MB)로 변환
    maxMemoryUsage = Math.max(maxMemoryUsage, rssUsage);
}, 10);

소요되는 메모리의 양을 정확히 구할 수는 없기 때문에 위와 같이 setInterval 함수를 사용하여 코드가 실행되는 동안 메모리 사용량을 10ms마다 기록하여 최댓값을 구하였습니다.

const startMemoryUsage = process.memoryUsage().rss / 1024 / 1024; // 단위 MB
// setInterval 실행
// 로그 받아오는 코드 실행
const memoryIncrease = maxMemoryUsedDuringTask - startMemoryUsage; // maxMemoryUsedDuringTask에는 setInterval에서 구한 메모리 최댓값 저장

시작하기 전에 현재 프로세스가 사용하는 메모리의 양을 구하고 로그를 받아오는 동안 사용한 메모리 사용량의 최댓값을 구하였습니다. 그 후에 이 둘의 차를 이용하여 로그를 받아오는 코드가 얼마나 많은 메모리를 사용하는지 유추해 볼 수 있었습니다.

256, 1690, 2342, 4014, 5155, 7288, 8392, 9070, 11581, 14153, 20761개의 로그에 대해 최대 8개까지 쓰레드를 사용해서 걸리는 시간과 소요하는 메모리 양을 구해보았습니다. (멘토님의 조언으로 최대 로그의 개수를 20000까지 제한하였습니다) 다음은 총 3번 평가하여 평균값을 낸 데이터입니다.

1. gen

https://github.com/kubernetes-client/gen 로그 수 : 256개	시간 그래프	메모리 그래프

2. C-Plus-Plus

https://github.com/TheAlgorithms/C-Plus-Plus 로그 수 : 1,690개	시간 그래프	메모리 그래프

3. github ranking

https://github.com/EvanLi/Github-Ranking 로그 수 : 2,342개	시간 그래프	메모리 그래프

4. vitest

https://github.com/vitest-dev/vitest 로그 수 : 4,014개	시간 그래프	메모리 그래프

5. SmartThingsPublic

https://github.com/SmartThingsCommunity/SmartThingsPublic 로그 수 : 5,155개	시간 그래프	메모리 그래프

6. argo-cd

https://github.com/argoproj/argo-cd 로그 수 : 7,288개

시간 그래프	메모리 그래프

7. jest

https://github.com/jestjs/jest 로그 수 : 8,392개

시간 그래프	메모리 그래프

8. googleapis

https://github.com/googleapis/googleapis 로그 수 : 9,070개

시간 그래프	메모리 그래프

9. github

https://github.com/atom/github 로그 수 : 11,581개	시간 그래프	메모리 그래프

10. infer

https://github.com/facebook/infer 로그 수 : 14,153개	시간 그래프	메모리 그래프

11. cypress

https://github.com/cypress-io/cypress 로그 수 : 20,761개	시간 그래프	메모리 그래프

로그가 1000개 이상인 경우, 쓰레드 수가 증가함에 따라 작업 속도가 빨라지는 경향을 확인할 수 있었습니다. 그러나 과도하게 많은 쓰레드를 사용할 경우, 메모리 사용량이 크게 증가하는 반면 작업 속도 개선은 상대적으로 미미했습니다. 정확한 수치 분석은 진행되지 않았지만, CPU 코어 수의 절반 정도의 쓰레드를 사용했을 때 가장 효율적인 성능을 보인다고 생각하였습니다. (현재 저의 코어 수는 8개 입니다.)

따라서 쓰레드의 개수가 1000개 이상일 때, 코어 수의 반 개의 쓰레드를 활용하여 작업 진행하므로써 전에 코어 수 - 1개의 쓰레드를 사용했을 때보다 작업 속도를 최적화하면서도 메모리 사용량을 효과적으로 관리할 수 있게 되었습니다.

Work list

쓰레드의 개수가 1000개 이상일 때, 코어 수의 반 개의 쓰레드를 활용하여 작업 진행

Discussion

코어 수의 반 개의 쓰레드를 활용하는 방식이 정확한 정답은 아닙니다. 하지만 확실히 이전 방식보다 적절한 메모리를 사용하여 작업 시간을 단축한다는 것은 맞다고 생각합니다.

githru / githru-vscode-ext