NVMe 성능 비교: Windows Server 2025 vs. Ubuntu Server 24.04.4 LTS

Windows Server 2025의 선택적 네이티브 NVMe 기능에 대한 기사를 게시한 후 , 네이티브 NVMe를 지원하는 Windows Server 2025와 Linux 기반 서버 OS 간의 스토리지 성능 비교를 요청하는 문의가 여러 건 있었습니다. 특히 한 열정적인 Reddit 사용자는 이를 위해 맥주를 제공하겠다고 제안하기도 했습니다! 다른 합리적인 선택지가 없었기 에 , Linux에서 동일한 테스트를 진행하기로 결정했습니다.

아주 오래전, 아주 먼 옛날 운영체제 버전에서

리눅스 커널은 2012년 3월에 출시된 3.3 버전 부터 NVMe를 지원해 왔습니다 . 마찬가지로, 윈도우 서버도 2012 R2 버전(2013년 10월경)부터 (SCSI 변환을 통한 비네이티브 방식으로) NVMe 프로토콜을 지원해 왔습니다. 10년이 넘도록 윈도우와 리눅스 중 어느 운영체제가 스토리지에 더 적합한지에 대한 논쟁이 계속되고 있는 가운데, 저희는 두 운영체제의 벤치마크 결과를 비교하여 이 논쟁에 더욱 불을 지펴보고자 했습니다.

Windows Server 2025에서 네이티브 및 비네이티브 스토리지 스택을 모두 사용한 테스트 결과를 보유하고 있으므로 Linux 환경에서도 두 가지 스토리지 스택을 평가하는 것이 적절하다고 판단했습니다. FIO 벤치마크에서는 스토리지 트랜잭션에 가장 널리 사용되는 API인 libaio와 io_uring을 모두 사용했습니다. io_uring은 훨씬 최신 API이며 비동기 I/O에 대한 많은 개선 사항을 제공하지만, libaio는 유연성과 사용 편의성 덕분에 여전히 널리 사용되고 있습니다(Didona, Pfefferle, Ioannou, Metzler, & Trivedi, 2022). 두 스택의 아키텍처에 대한 자세한 설명은 이 글의 범위를 벗어나지만, 직접적인 비교를 위해 결과를 제공합니다.

Ubuntu Server 24.04.4 LTS에서 NVMe 테스트

이번 비교에 사용된 하드웨어 플랫폼은 Windows Server 2025 네이티브 NVMe 관련 기사 에서 사용된 것과 동일한 서버입니다 . 최대 처리량과 일관된 결과를 보장하기 위해 128코어 AMD EPYC 9754 CPU 2개, 4800 MT/s 속도의 DDR5 메모리 768GB, 그리고 JBOD 구성의 PCIe 4.0을 지원하는 30.72TB Solidigm P5316 NVMe SSD 15개가 장착되어 있습니다 .

이전 기사에서 언급했듯이 Solidigm P5316은 간접 단위 크기가 64킬로바이트이므로 4K 테스트와 같은 작은 크기의 블록에 대한 쓰기 성능이 예상보다 떨어지는 경우가 많습니다. 이번에도 읽기 및 쓰기 작업에 대한 광범위한 결과를 제공하기 위해 4K, 64K, 128K의 다양한 블록 크기로 여러 테스트 패턴을 실행했습니다.

우리는 인기도와 장기 지원 때문에 우분투 서버 24.04.4 LTS를 리눅스 예시로 선택했습니다. 이 시스템은 기본적으로 리눅스 커널 6.8을 사용하는데, 이는 최신 버전은 아니지만 전 세계적으로 많은 설치 사례에서 사용되고 있을 가능성이 높습니다.

Highlights

• Windows Server 2025의 네이티브 NVMe가 4가지 읽기 성능 벤치마크 중 3가지에서 우위를 차지했습니다.
• 대부분의 테스트에서 Windows Server를 사용할 때 CPU 사용량이 더 낮게 나타났습니다.
• Ubuntu Server 24.04.4 LTS가 4가지 쓰기 성능 벤치마크 중 3가지에서 우위를 차지했습니다.

메트릭	랜덤 4K				랜덤 64K
	Windows 비네이티브	윈도우 네이티브	리눅스 libaio	Linux io_uring	Windows 비네이티브	윈도우 네이티브	리눅스 libaio	Linux io_uring
무작위 읽기
대역폭(GiB/s)	6.1	10.058	9.198	9.504	74.291	91.165	77.517	77.7
IOPS	1,598,959	2,636,516	2,411,000	2,491,000	1,217,176	1,493,637	1,270,000	1,273,000
평균 지연 시간(밀리초)	0.169	0.104	0.198	0.192	0.239	0.207	0.377	0.376
총 CPU 사용률(%)	72.67	74.22	99.77	99.76	68.44	65.11	83.16	84.72

 

메트릭	순차 64K				순차 128K
	Windows 비네이티브	윈도우 네이티브	리눅스 libaio	Linux io_uring	Windows 비네이티브	윈도우 네이티브	리눅스 libaio	Linux io_uring
순차적 읽기
대역폭(GiB/s)	35.596	35.623	31.867	31.433	86.791	92.562	97.05	97
IOPS	583,192	583,638	522,000	515,000	710,978	758,252	795,000	795,000
평균 지연 시간(밀리초)	0.809	0.812	0.919	0.932	0.613	0.608	0.603	0.604
총 CPU 사용률(%)	44.89	37.11	53.94	41.74	61.56	49.56	75.14	76.90

 

메트릭	랜덤 4K				랜덤 64K
	Windows 비네이티브	윈도우 네이티브	리눅스 libaio	Linux io_uring	Windows 비네이티브	윈도우 네이티브	리눅스 libaio	Linux io_uring
임의 쓰기
대역폭(GiB/s)	1.803	1.756	1.876	1.815	7.654	7.655	7.652	7.651
IOPS	472,725	460,383	492,000	476,000	125,391	125,406	125,000	125,000
평균 지연 시간(밀리초)	0.992	1.028	0.974	1.007	3.814	3.816	3.827	3.828
총 CPU 사용률(%)	26.00	20.67	45.76	22.80	12.22	9.33	20.07	10.90

 

메트릭	순차 64K				순차 128K
	Windows 비네이티브	윈도우 네이티브	리눅스 libaio	Linux io_uring	Windows 비네이티브	윈도우 네이티브	리눅스 libaio	Linux io_uring
순차적 쓰기
대역폭(GiB/s)	44.67	50.087	52.283	52.25	50.477	50.079	52	52.083
IOPS	731,859	820,603	856,000	856,000	413,495	410,232	426,000	427,000
평균 지연 시간(밀리초)	0.399	0.558	0.560	0.560	1.022	1.149	1.126	1.125
총 CPU 사용률(%)	70.44	57.78	61.88	62.75	58.44	47.33	61.49	44.27

참고 : Windows Server 2025와 Ubuntu Server 24.04.4 LTS 간의 FIO 보고 방식 차이로 인해 Linux IOPS 결과는 천 단위로 반올림됩니다. 대역폭, 지연 시간 및 CPU 사용률 결과는 두 플랫폼 모두에서 일관되게 반올림됩니다.

숫자는 거짓말을 하지 않는다

곧바로 알 수 있듯이 우분투는 모든 면에서 윈도우보다 뛰어난 성능을 보이지는 않습니다. libaio와 io_uring은 무작위 읽기 대역폭 테스트에서 탁월한 처리량을 보여주었지만, 마이크로소프트의 네이티브 NVMe 스택 성능에는 미치지 못했습니다. 윈도우 NT 커널은 64K 무작위 읽기 테스트에서 네이티브 NVMe 환경에서 91.165GiB/s를 기록하며 리눅스 커널보다 약 17% 높은 성능을 보였고, io_uring의 최고 성능은 77.7GiB/s였습니다.

하지만 토르발스의 기술적 공포에 대한 희망이 완전히 사라진 것은 아닙니다. 우분투 서버는 읽기 성능 벤치마크 중 하나인 순차 128K 테스트에서 윈도우 서버를 근소한 차이로 앞섰습니다. 이 테스트에서 리눅스의 libaio는 97.05GiB/s의 성능을 보였고, 윈도우의 네이티브 NVMe는 92.562GiB/s를 기록하여 약 5%의 차이를 보였습니다. 이는 리눅스가 드라이브의 간접 참조 단위보다 큰 블록 크기를 처리할 때 약간의 우위를 점할 수 있음을 시사합니다.

랜덤 쓰기 대역폭은 Linux와 Windows 모두에서, 특히 64K 벤치마크에서 일관된 성능을 보였습니다. 해당 테스트에서 최고 결과와 최저 결과의 차이는 단 0.05%에 불과하여 모든 스토리지 스택이 드라이브의 잠재력을 최대한 발휘했음을 시사합니다.

흥미롭게도 리눅스 6.8 커널은 64KB 및 128KB 블록 크기에 대한 순차 쓰기 대역폭 테스트에서 우위를 점했습니다. 차이는 크지 않았지만, 오픈 소스 소프트웨어 스택은 두 경우 모두에서 윈도우 서버의 네이티브 NVMe보다 약 2GiB/s 더 높은 성능을 보였습니다.

지연 시간 결과는 일반적으로 처리량 테스트 결과와 유사했으며, 특히 무작위 읽기 평균 차이에서 이러한 경향이 가장 잘 나타났습니다. 하지만 Tux의 경우 libaio와 io_uring의 지연 시간이 더 높았으며, 64K 무작위 읽기에서 Windows Server 네이티브 NVMe(0.207ms)와 libaio(0.377ms) 간의 차이가 0.17ms로 가장 컸습니다.

벤치마크 테스트에서 가장 놀라운 결과는 Windows Server 2025와 Ubuntu Server 24.04.4 LTS 간의 CPU 사용량 차이가 엄청나다는 점입니다. 4개의 무작위 및 순차 읽기 벤치마크 중 3개에서 Windows Server의 네이티브 NVMe가 가장 낮은 CPU 사용량을 기록했습니다. 특히 128K 순차 읽기 벤치마크에서 Windows가 Linux보다 27.34% 더 적은 CPU 사용량을 보인 것이 가장 눈에 띄는 결과였습니다.

libaio와 io_uring을 사용했을 때 CPU 사용률은 무작위 및 순차 쓰기 테스트에서 약간 더 나은 성능을 보였지만, Windows Server의 네이티브 NVMe가 세 가지 벤치마크에서 여전히 우위를 점하는 것을 막기에는 충분하지 않았습니다. 주목할 만한 예외는 4K 무작위 쓰기 테스트에서 libaio의 CPU 사용률이 시스템 CPU의 45.76%에 달했던 반면, 다른 스토리지 스택은 약 20%를 유지했다는 점입니다.

우승자, CPU 저녁 식사

테스트 결과에서 볼 수 있듯이, Windows Server와 Ubuntu Server는 다양한 블록 크기에서 수행된 무작위 및 순차 성능 테스트 모두에서 매우 유사한 성능을 보였습니다. 대역폭 측면에서는 네이티브 NVMe를 탑재한 Windows Server 2025가 대부분의 읽기 테스트에서 Linux보다 우수한 성능을 나타냈으며, 쓰기 테스트에서는 Linux가 약간 더 나은 결과를 보였습니다. 지연 시간 수치에서도 비슷한 결과가 나타났지만, 가장 주목할 만한 점은 네이티브 NVMe를 사용할 때 Windows Server 2025의 CPU 효율성이었습니다.

마이크로소프트는 최신 스토리지 스택을 최고의 성능으로 만들기 위해 상당한 노력을 기울였으며, libaio 및 io_uring과의 경쟁에서 항상 우위를 점하는 것은 아니지만, 상당한 경쟁력을 보여줍니다. 이러한 결과가 모든 사용 사례 및 서버 환경에서 확정적인 것은 아니지만, 스토리지 성능이 운영체제 호환성보다 더 중요한 경우 서버 관리자가 Windows 또는 Linux 서버를 배포할지 결정하는 데 도움이 될 수 있습니다.

이번 결과에 대한 여러분의 생각을 소셜 미디어나 SR 디스코드 에 댓글로 남겨주세요 ! 윈도우 서버가 테스트에서 이렇게 좋은 결과를 보일 거라고 예상하셨나요, 아니면 리눅스를 응원하셨나요? 더 많은 리눅스 서버 배포판이나 커널 테스트를 보고 싶으신가요? 저희는 항상 여러분의 의견을 기다리고 있으며, 독자 여러분의 요청으로 진행하는 테스트는 저희에게 가장 인기 있는 기사가 되곤 합니다.

참고자료

Didona, D., Pfefferle, J., Ioannou, N., Metzler, B., & Trivedi, A. (2022년 6월 13일). 최신 스토리지 API 이해: libaio, SPDK 및 io_uring에 대한 체계적인 연구. SYSTOR '22, 120-121. 2026년 4월 3일 https://atlarge-research.com/pdfs/2022-systor-apis.pdf 에서 검색됨