하이퍼스레딩 (Hyper-Threading) 사용할 것인가 말것인가?

SQL Server 혹은, .NET 이나 J2EE applicadtion 환경에서 인텔 계열 CPU를 사용할 때 Hyper-Threading이 과연 어떠한 영향을 미치는지 생각해 보도록 하자

• Hyper-Threading이란?

먼저 Hyper-Threading 이라 부르는 이 인텔의 cpu 기술은 multi-thread기술을 CPU layer에 도입한것이지만 실상 이것과는 다른다. 이것은 시분할 처럼 thread의 인터리빙 방식이 아니라 cpu 아텍처상 길게 늘어진 pipeline을 통해 있는 비어있는(놀고) 사이클을 다른 프로세스에게 사용할 수 있는 기회를 주는 것이다. 다시 말해서 현재 어떤 쓰레드가 RAM 액세스나 I/O 액세스 같은 오랜 시간이 걸리는 작업이 끝나기만을 기다리고 있다면 이를 다른 쓰레드에 할당하여 cpu의 활용도를 높이는 기술이다.
통상 Hyper-Threading을 사용하면 5% ~ 15%의 성능 향상을 기대할 수 있다.
하지만 이게 다가 아니다. 이 기술의 이면에는 조금은 깊게 생각해야할 성능적 문제가 자리잡고 있다.

• Hyper-Threading의 성능문제

위에서 설명한 대로 hyper-threading 기술은 놀고있는 cycle를 다른 쓰레드에게 할당해주는 방식이기에 마치 2개의 cpu 처럼 보일 뿐이지, 물리적으론 하나다. 그 말은 L1&L2 캐쉬를 공유한다는 의미이다. (마치 다중 thread가 프로세스내의 메모리를 공유하는것가 동일하다)
문제는 여기에서 출발한다.
Thread는 크게 두개로 나눌수 있다. 하나는 사용자의 요청을 처리하는 worker thread이고 , 다른 하나는 system thread로 백그라운드로 수행되는 쓰레드인데, GC나 Lazy writer 같은 것이 이에 해당한다. 왜 이것을 말하냐 하면, worker thread는 비교적 작은 단위 작업을 처리하는데 비해 백그라운드 쓰레드는 대용량 메모리나/object/cache 를 스캔하거나 하는 작업이 이루어 진다.
다음과 같은 시나리오를 생각해보자.
만약 동일한 물리적 CPU 안에서, worker thread가 작업을 수행 하다가 i/o 를 처리하기위해 대기 하고 있는데 이때 system thread가 수행되어 대용량 메모리 스캔을 위해 CPU를 할당하면 대용량 작업을 수행하기 때문에 공유된 L1&L2 캐시를 지워버린다. 다시 worker thread로 돌아와서 나머지 작업을 처리할려고 하니 이미 L1&L2 캐시에 없기 때문에 cache miss가 발생하고, 보조 기억장치인 RAM을 뒤지고, 여기에도 없다면 disk page i/o가 발생하게 된다.
이와같은 상황은 부하가 매우 높은 시스템에서라면 심각한 성능저하를 일으킬 수 있다.

또한 이런 시나리오는 SQL Server 환경이나, .NET, J2EE환경에서는 빈번하게 발생된다.
특히 SQL Server환경이라면, Lazy writer 뿐만아니라, worker thread 자체가 대용량 메모리를 스캔할수도있다(인덱스 부재로).

• 그럼 Hyper-Threading을 사용하지 말아야 하나?

그것은 아니다. 앞서 말한데로 Hyper-Threading 을 사용한 성능향상은 분명이 존재한다.
그리고 이것은 사용하고 있는 application 이나, 시스템 환경에 따라 달라진다.
또한 시나리오에 따른 성능저하 현상은 매우 높은 시스템 부하에서만이 확인해 볼수 있다.
따라서 우리 시스템에서 Hyper-Threading을 사용할지 말지는 그 시스템의 환경에 따라
충분한 테스트를 수행하고 나서 결정을 해야한다.

그것이 SQL Server라면, 메모리가 충분한지(lazy writer), 그리고 인덱스가 적절히 사용되어 대용량 메모리 스캔이 드물다면, 또한 heavy load가 아니면 개인적인 생각으로는 사용하는 것이 좋다고 판단한다.

이것에 관한 sql server 개발자의 의견은 많은 도움을 줄것이다..