▲

Windows Server 2025는 ARM에서 더 잘 실행됨

 (jasoneckert.github.io)
1P by GN⁺ 7시간전 | ★ favorite | 댓글 1개
  • 가상화된 Windows Server 2025 비교에서 ARM64 호스트 위 ARM64 게스트 구성이 안정적으로 동작했고, 서비스 시작과 관리 콘솔 실행, 실습 작업 처리에서도 더 빠른 체감 반응 확인
  • 두 VM은 메모리·가상 프로세서·역할 구성을 동일하게 맞췄고, 측정에서는 Snapdragon 시스템이 CPU 사용률 변동 폭이 작고 Processor Queue Length 0 유지와 CPU Wait Time Per Dispatch의 일관된 값 기록
  • IIS, DNS, Active Directory 조회, 도메인 인증, 파일 I/O 반복 측정에서도 Snapdragon X Elite가 거의 매번 재현 가능한 시간값을 보였고, Intel은 일부 실행에서 더 빨랐지만 전반적으로 편차가 더 큼
  • 차이를 CPU 아키텍처 하나로 단정하지 않았으며, 저장장치·메모리·전력 관리·발열 특성과 함께 지연 시간의 일관성과 예측 가능한 스케줄링이 가상화된 서버 부하에 더 중요하게 작용
  • 최대 처리량 중심 워크로드에서는 x64 장점이 남아 있지만, 소규모 지연 민감 작업이 많은 전형적 Windows Server 배포에서는 ARM64 매력 확대, 다만 교육용 표준 플랫폼은 ARM64의 중첩 가상화 미지원으로 x64 유지

테스트 환경과 비교 기준

  • Windows Server 2025 가상 환경을 두 시스템에 각각 구축해 비교 진행
    • Windows 11 기반 14세대 Intel Core i9 시스템에서 Hyper-V 가상 머신 다수 운영
    • Windows 11 on ARM 기반 Snapdragon X Elite 시스템에도 동일한 Windows Server 2025 환경 구성
  • Microsoft 웹사이트에서 Windows Server 2025 ARM 공식 설치 ISO를 제공하지 않아, UUP dump로 Microsoft 업데이트 서버 기반 이미지를 생성해 설치
  • 두 Hyper-V VM은 메모리, 가상 프로세서, 설치 역할을 동일하게 맞춘 구성
    • Snapdragon X Elite는 ARM64 guest on ARM64 host
    • Intel Core i9는 x64 guest on x64 host

초기 관찰과 해석 범위

  • ARM 시스템의 Windows Server 2025 환경이 안정적이고 정상 동작했으며, 실사용 가능 수준으로 체감상 전반적인 속도도 더 빠름
    • 서비스 시작 속도 향상
    • 관리 콘솔 실행 속도 향상
    • 교재 집필용 실습 작업 수행 시간 단축
  • 다만 성능 차이를 CPU 아키텍처 하나만의 결과로 단정하지 않음
    • 저장장치, 메모리, 전력 관리, 발열 특성도 결과에 영향 가능
    • “ARM이 더 빠르다”는 단정 대신 전체 시스템 특성 기준 해석 필요
  • Windows Server의 일반적 서비스 부하는 스레드 비중이 높고, 작지만 빈번한 CPU 및 I/O 작업 중심 특징
    • Active Directory, DNS, DHCP, IIS, SMB/NFS/DFS 파일 서비스, Print Services, Certificate Services, Remote Desktop Services, Routing and Remote Access, NPS 등 포함
    • 이런 유형은 지연 시간과 문맥 전환에 민감하며, 지속적으로 일관된 성능의 이점 존재

성능 차이에 대한 관찰

  • Snapdragon 계열 ARM 시스템은 높은 부스트 클록 추구보다 지속적이고 안정적인 성능 제공 경향
  • 최신 Intel CPU는 주파수 가속과 동적 스로틀링 특성으로 높은 최대 성능 제공 가능
    • 대신 지속 부하나 혼합 부하에서는 스케줄링과 지연 시간의 변동성 증가 가능
  • 가상화 환경에서는 이런 변동성이 더 중요하게 작용
    • Hyper-V 같은 하이퍼바이저는 사실상 하드웨어 스케줄러 역할 수행
    • 하드웨어 실행 타이밍이 더 예측 가능할수록 하이퍼바이저 스케줄링도 더 일관된 결과로 이어짐
    • 그 효과가 VM과 VM 내부 서비스 응답성에 반영됨
  • Windows Server ARM64 빌드 자체 차이 가능성도 언급됨
    • 온라인에서 확인한 여러 릴리스 노트 기준, ARM64 버전은 일부 레거시 호환 계층을 피하고 더 현대적이고 최적화된 바이너리 사용 가능성 존재
    • x64 버전보다 더 정리된 빌드일 수 있다는 관찰 포함
    • 구체적 내부 구현 근거는 추가로 제시되지 않음

Performance Monitor 측정

  • 두 Windows 11 호스트에서 Performance Monitor 카운터를 추가해 측정 진행
    • \Processor(_Total)\% Processor Time
      • 전체 코어 기준 CPU 사용률
    • \System\Processor Queue Length
      • CPU 시간을 기다리는 스레드 수
      • 최적이라면 0 유지가 바람직함
    • \Hyper-V Hypervisor Virtual Processor(*)\CPU Wait Time Per Dispatch
      • 가상 프로세서가 CPU에 스케줄되기까지 기다리는 평균 시간
  • 각 VM 내부 PowerShell에서 부하를 생성한 뒤 결과 관찰
    • Get-Process 결과를 CPU 사용량 기준 정렬하고 상위 5개를 반복 조회하는 무한 루프를 8개 실행
  • 측정 결과에서 Snapdragon은 지속적이고 안정적인 성능 패턴 확인
    • % Processor Time 변동 폭이 훨씬 작음
    • Processor Queue Length가 0 유지
    • CPU Wait Time Per Dispatch도 평탄하고 일관된 값 유지
  • Intel 시스템은 부스트/스로틀 변동성이 지표에 반영됨
    • % Processor Time 변동 폭이 더 큼
    • Processor Queue Length가 주기적으로 급증
    • CPU Wait Time Per Dispatch도 유의미한 변동 발생

서비스 응답성 측정

  • 각 VM의 PowerShell에서 Measure-Command를 사용해 일반적 서비스 작업 시간을 측정
  • IIS 웹 서버 대상 테스트 수행
    • Invoke-WebRequest http://localhost -UseBasicParsing | Out-Null를 1000회 반복
  • 같은 방식으로 다른 서비스도 반복 측정
    • DNS
      • Resolve-DnsName "domainX.com" -Server 127.0.0.1 | Out-Null
    • Active Directory 조회
      • Get-ADUser -Filter * -ResultSetSize 1 | Out-Null
    • 도메인 인증 지연
      • Test-ComputerSecureChannel -Verbose:$false
    • 파일 I/O
      • C:\TestFiles 디렉터리 생성
      • 2000회 반복하며 파일 생성, 내용 기록, 읽기, 삭제 수행
  • 여러 차례 반복 실행한 결과, Snapdragon 시스템은 일관되고 재현 가능한 시간값을 거의 매번 기록
  • Intel 시스템은 결과 편차가 더 큼
    • 일부 실행에서는 Snapdragon보다 더 빠를 때도 있음
    • 그러나 대부분의 경우 뒤처짐
  • 전체적으로는 모든 테스트에서 Snapdragon 우세라는 결론

핵심 결론

  • 여러 결과를 관통하는 공통 요소는 지연 시간의 일관성
  • 가상화된 Windows Server 부하는 작고 빈번한 작업에 대한 빠른 응답과 예측 가능한 스케줄링의 중요성 큼
  • 최대 처리량이 중요한 워크로드에서는 x64 시스템이 여전히 분명한 장점 보유
  • 반대로 전형적인 Windows Server 배포처럼 많은 소규모 지연 민감 작업이 가상화 아래에서 함께 실행되는 환경에서는 순수 최고 속도보다 일관성이 더 중요함
  • 그런 맥락에서 ARM64의 매력 확대
  • ARM64는 이미 클라우드 환경에서 널리 사용 중이며, 성능 대비 비용 비율이 x64보다 더 좋다는 언급 포함
  • Microsoft가 Windows Server의 미래에서 ARM64 비중 확대를 검토할 필요 제기
    • 현재 Microsoft는 Windows Server on ARM64를 완전 지원하지 않음
    • 그러나 지난 해 신규 Microsoft Azure VM 인스턴스의 33% 가 ARM64였고, Amazon AWS는 50% 가 ARM64였다는 수치 제시

교육용 표준 플랫폼 선택

  • 교재용 실습 환경은 여전히 x64 표준화 유지
  • 이유는 실습 구성에 중첩 가상화가 포함되기 때문
  • Hyper-V의 ARM64에서 중첩 가상화 미지원으로 인해 ARM64는 현재 교육용 기본 환경으로 채택되지 않음
  • 학생이 실습을 우회 구성하는 것은 가능하나, 교재 목표 중 하나가 재현성이므로 단계별로 동일하게 동작하는 환경 우선
  • 현재 시점에서는 교육 목적상 x64가 실용적 선택지로 유지

함께 보면 좋은 글 β

▲
GN⁺ 7시간전  [-]
Hacker News 의견들
  • 테스트 재현에 필요한 설정, 추측, 코드까지는 다 공개했는데 체감 결과값 자체가 빠져 있어서 조금 의심스러웠음. ARM이 실제로 얼마나 빠른지 수치가 궁금했음
    • 출력 스크린샷을 일부러 뺐던 이유가 있었음. 벤치마크 글로 흐리는 걸 피하고 싶었고, ARM 하드웨어나 Snapdragon X Elite 세부 모델에 따라 결과가 달라져 오해를 부를 수 있다고 봤음. 대신 누구나 재현할 수 있게 PowerShell 스니펫을 넣었음. 대략적인 결과는 Snapdragon VM이 Intel VM보다 테스트별로 약 20~80% 빨랐고, DNS는 약 20%, IIS는 약 50%, 나머지는 대체로 80%에 가까웠음
  • Windows 개발자 관점에서 보면 이건 segment heap 영향일 가능성이 커 보였음. Windows 힙 구현에는 오래된 NT heap과 2010년대의 segment heap이라는 서로 독립적인 두 계열이 있고, segment heap이 메모리 단편화와 작은 할당 재사용 면에서 더 효율적이었음. 다만 Windows는 레거시 호환성을 극도로 중시해서, 오래된 앱들이 use-after-free 같은 위험한 동작이나 내부 NT heap 구조체에 의존할 수 있었기 때문에 기본값을 일괄 전환하지 않았음. 그래서 packaged 실행 파일에는 segment heap을 기본 적용하고, unpackaged 쪽은 그대로 두는 절충을 택했음. 그런데 UWP 전환이 실패하면서 Windows 생태계는 더 쪼개졌고, 중요한 소프트웨어 대부분은 여전히 unpackaged x64로 남았음. 반면 arm64 바이너리는 오래된 레거시 코드일 가능성이 낮아서 arm에서는 segment heap이 기본 활성화됨. 사용자가 arm Windows가 더 반응성 좋다고 느끼는 이유 중 적지 않은 부분이 여기에 있다고 봄. x64에서 segment heap을 강제로 켜고 이 테스트를 다시 해보면 흥미로울 것 같았음. 실행 파일별로는 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\.exe 아래 FrontEndHeapDebugOptions DWORD를 8로 주면 되고, 전역으로는 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap 아래 Enabled DWORD를 3으로 주면 됨. 내 개발 머신에서는 전역 활성화 후 문제를 못 봤고, 메모리 사용량은 테스트 기준 약 15% 절감됐음
    • 내 RAM/CPU 집약 워크로드에서는 NT Heap 대비 Segment Heap으로 전체 성능이 안정적으로 약 7% 좋아졌음. 합쳐진 작업이 7% 더 빨리 끝났음. 예전의 "Compatible with Windows XXX" 같은 인증이 Windows 10/11에도 있었다면, 여기에 segment heap 체크 항목을 넣어 더 많은 앱과 사용자에게 성능, 전력 효율, 친환경성 이점을 줄 수 있었을 것 같음. 그리고 UWP의 문제는 기술 자체보다 패키징과 Store 결합을 고집한 점이었고, 그건 Windows라는 OS의 존재 방식과 충돌했다고 봤음
    • 관심 있는 사람이라면 자기 실행 파일의 application manifest에서 heapType을 SegmentHeap으로 설정해 이 동작을 opt-in할 수 있음. 문서에 설명이 있음
    • 이런 식의 실전 팁이야말로 HN의 가치라고 느낌. 전역 레지스트리 키는 재부팅이 필요한지, 아니면 실행 파일 시작 시점부터 바로 적용되는지가 궁금했음
    • 이 내용은 포럼 댓글보다 블로그 글로 남아야 할 수준으로 흥미로웠음
    • 예전에 이 전역 설정은 0 대 non-zero로 설명된 걸 봤는데, 값이 왜 하필 3인지 궁금했음. 2는 어떤 의미인지, 이런 값들의 뜻을 스스로 어디서 확인할 수 있는지도 알고 싶었음
  • 글의 "ARM은 높은 boost clock을 쫓지 않고 꾸준한 성능을 낸다"는 표현은 조금 과장처럼 느껴졌음. 내가 써본 ARM 시스템도 전부 주파수 스케일링을 했고, 그 점에서는 x86과 비슷하게 동작했음. 결국 차이는 얼마나 높이 올라가느냐 정도로 보였음
    • 워크로드 의존성은 있겠지만, 내가 일한 여러 조직의 클라우드 환경에서는 x86에서 ARM 전환만으로도 비용 절감 효과가 꽤 컸음. 인스턴스 가격이 더 낮은 데다 효율도 더 좋았기 때문임. 특히 한 조직에서는 수백 개의 Kubernetes 노드를 동적 오토스케일링하는 환경에서 추가 변경 없이 x86 -> ARM만으로 보수적으로도 약 15% 절감 효과를 예상했고 실제로 달성했음. CPU 바운드이면서 x86 특화 기능에 덜 묶인 워크로드라면 15%보다 훨씬 더 클 수도 있다고 봤음
  • ARM CPU의 덜 흔들리고 더 예측 가능한 성능이 핵심이었다면, 데스크톱 CPU 대신 Epyc 같은 서버 CPU를 써도 비슷한 이점을 볼 수 있다고 생각했음. 서버 CPU는 클럭 변동 폭이 더 작고 boost 정책도 덜 공격적이기 때문임. 심지어 지금 있는 데스크톱 하드웨어에서도 BIOS에서 Turbo를 꺼서 Intel CPU를 기본 클럭으로 고정하면, 낮더라도 안정적이고 예측 가능한 성능을 만들어 비교해볼 수 있다고 봤음
    • 전원 관리 계획에서도 turbo 동작을 끌 수 있었음. 다만 그 설정이 GUI에 기본으로 보이지 않을 수도 있었음
  • Windows on ARM이 VBS나 Virtualization Based Security를 쓰는지, 그리고 VM 안에서도 nested virtualization으로 그걸 지원하는지가 궁금했음. 또 CPU 취약점 완화가 VM에서 이중으로 걸려 성능에 영향을 주는지 여부도 중요해 보였음. 요즘 Windows를 VM에 넣었을 때 흔히 보는 성능 문제 상당수가 여기서 오기 때문임. 그런데 글에서는 이 부분을 언급하지 않아 아쉬웠음
  • 두 시스템의 RAM과 스토리지 구성이 궁금했음. Snapdragon 쪽이 패키지드 RAM이라 인터커넥트가 더 빠를 수도 있고, x86 쪽은 DIMM이라 트레이스가 더 길 수도 있다고 봤음. 스토리지나 CPU 모델도 성능 차이를 크게 좌우할 수 있음. 벤치마크는 시스템 한 부분만 과하게 자극하는 경우가 많아서, 진짜 차이가 ARM 아키텍처 자체보다 RAM, syscall, SSD 같은 다른 요소에서 오는 것일 수도 있다고 생각했음
    • 두 시스템 모두 메인보드에 납땜된 DDR5와 NVMe SSD를 사용했음. 오히려 Intel 쪽 SSD가 Snapdragon 쪽 Foresee보다 더 빠른 Samsung 모델이었음
  • Linux에서는 전부 더 잘 돌아가고, 감시 오버헤드로 사이클을 낭비하지 않는다고 느꼈음
  • 글이 Intel 프로세서가 뭔지 일부러 말을 피하는 것처럼 보여서, 내가 뭘 놓친 건지 궁금했음
    • 사용한 CPU는 14th Gen Intel Core i9였음
  • HV 서버에서는 보통 C States 비활성화, 전원 관리 high 설정 같은 방식으로 x86이 다운클럭하지 않게 막는 편임. CPU가 위아래로 흔들리지 않게 하면 성능이 크게 좋아질 수 있음. 다만 이런 건 보통 개인용이나 실험실 장비에서는 잘 하지 않음
    • 아니면 그냥 turbo boost 비활성화만 해도 됨
  • 글을 읽고 나니 핵심은 두 가지로 보였음. 첫째, ARM64는 x64보다 덜 "똑똑"해서, Core i9처럼 공격적으로 부스트와 스로틀링을 반복하기보다 일정한 성능을 내고, 그 덕분에 OS 스케줄링이 쉬워진다는 점임. 둘째, Windows가 ARM에서는 x64보다 역사적 짐이 덜해서 ARM 빌드 자체가 더 효율적일 가능성도 있어 보였음. 결국 CPU 스로틀링이 너무 영리해져서 오히려 해가 되는 지점에 온 건지 궁금했음
    • 다만 이건 서버 OS를 데스크톱 x86 CPU에서 테스트한 사례라는 점을 같이 봐야 했음. AMD Epyc나 Intel Xeon 같은 x86 서버 CPU는 클럭 변동 범위가 더 작고 정책도 덜 공격적이라, 데스크톱 CPU보다 더 일정하고 예측 가능한 성능을 냄. 이런 특성은 멀티스레드 워크로드에 유리하고, 데스크톱 CPU는 단일 스레드 최고 성능을 위해 조정되다 보니 멀티스레드에는 오히려 손해가 날 수 있다고 봤음
답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.