없다. 하이퍼스레딩(Intel HT · AMD SMT) 은 물리 CPU 의 기능이고 호스트 펌웨어에서 켜고 끈다. 게스트가 보는 것은 하이퍼바이저가 만들어 준 vCPU 이며, 그 vCPU 가 물리 코어에 앉을지 논리 스레드에 앉을지는 하이퍼바이저의 스케줄러가 정한다.
따라서 "VM 에서 하이퍼스레딩을 켠다" 는 표현은 성립하지 않는다. 호스트에서 켜져 있으면 그 효과를 간접적으로 받을 뿐이다.
lscpu | egrep 'Thread|Core|Socket|Model name'
게스트에서 이 값을 봐도 하이퍼바이저가 노출하기로 한 토폴로지가 보일 뿐, 물리 배치와 같다는 보장이 없다.
논리 코어가 두 배로 늘어난다고 처리량이 두 배가 되지는 않는다. 두 스레드가 같은 물리 코어의 실행 유닛과 캐시를 나눠 쓰기 때문이다.
호스트 CPU 사용률이 낮은 환경이라면 하이퍼스레딩 여부는 거의 체감되지 않는다. vCPU 가 물리 코어 수를 넘어 과잉 할당된 상태에서 성능을 논하는 것이 순서상 먼저다. vCPU 를 필요 이상으로 많이 준 VM 은 스케줄러가 동시에 실행할 코어를 모으느라 오히려 대기가 늘어난다.
성능을 다듬을 때 효과가 큰 순서는 대체로 이렇다.
보안 쪽 고려도 있다. 논리 스레드를 공유하는 데서 오는 부채널 위험 때문에, 신뢰 경계가 다른 워크로드를 한 물리 코어에 섞지 않는 정책을 두는 환경이 있다. 이런 곳에서는 하이퍼스레딩을 끄거나 코어 단위 스케줄링을 쓴다.
하둡은 dfs.datanode.data.dir 에 /data01 ~ /data05 처럼 여러 경로를 준다. 이것은 물리 디스크를 여러 장 병렬로 쓰기 위한 것이다. 목적이 두 가지다.
VM 안에서 가상 디스크 한 장을 파티션이나 디렉터리로 쪼개 /data1 ~ /data5 를 만드는 것은 이 둘 중 어느 것도 얻지 못한다. 뒷단은 여전히 한 장이라 병렬성이 늘지 않고, 그 한 장이 죽으면 다섯 경로가 함께 죽는다. 오히려 공간을 미리 갈라 두어 한쪽만 차는 불균형이 생긴다.
의미가 있으려면 가상 디스크를 서로 다른 물리 장치(또는 서로 다른 데이터스토어·LUN) 에서 따로 붙여야 한다. 그때는 게스트에서 여러 장으로 보이고 실제로도 독립적이다.
의미 없음: 1개 물리 디스크 → 1개 VDI/VMDK → 파티션 5개 → /data1..5
의미 있음: 물리 디스크 5장 → VDI/VMDK 5개 → /data1..5
가상화 위에서 하둡·카프카처럼 디스크를 직접 쓰는 것을 전제로 설계된 소프트웨어를 돌릴 때는, 스토리지 계층이 이미 RAID 나 분산 스토리지로 한 번 묶여 있는지도 함께 본다. 아래에서 이미 여러 장으로 분산하고 있다면 위에서 다시 나누는 이득은 크지 않다.