WSL1은 윈도우 파일 시스템을 이용했기 때문에 WSL 내의 읽기/쓰기가 매우 느렸습니다. 대신 윈도우에서 WSL을 읽고 쓰는 것은 빨랐습니다.
이에 비해 WSL2는 가상 하드 디스크(VHDX)를 사용합니다. 그래서 WSL2 내의 읽기/쓰기는 매우 빨라졌습니다. 대신 윈도우에서 WSL 내의 파일을 읽고 쓰는 것이 느려졌습니다. 가상화 계층을 거쳐야 하기 때문입니다.
윈도우에서 PhpStorm과 IntelliJ IDEA, VSCode를 설치하고 \\wsl$\... 경로를 통해서 WSL2 내에 있는 프로젝트 소스 코드에 접근해 작업을 해 봤습니다.
PhpStorm과 VSCode는 그럭저럭 쓸만했는데, IntelliJ IDEA는 프로젝트 인덱싱중에 자꾸 뻗어서 결국 WSL2 내에 리눅스 버전 IDEA을 설치하고 WSL2 GUI를 이용하게 됐습니다.
그래서 질문이 생겼습니다. 윈도우에서 WSL2 내에 있는 파일에 접근하는 것은 얼마나 느리길래 IDE가 뻗는 것일까?
결과 요약
읽기 성능은 최소 1.1배, 최대 10.2배 차이가 발생했습니다.
쓰기 성능은 최소 1.7배, 최대 2.8배 느렸습니다.
컴퓨터의 성능을 제대로 쓰기 위해 WSL2 프로젝트는 WSL2에서 GUI로 IDE를 사용하는 편이 낫겠다는 결론입니다.
비교 상세 내용은 밑에 있습니다.
MS의 안내
MS는 다음과 같이 안내하고 있습니다(영문. 한국어 페이지도 있지만 번역이 부정확합니다):
윈도우와 리눅스 운영체제 사이를 건너는 파일 성능은 WSL1이 WSL2보다 더 빠릅니다. 따라서 윈도우 프로그램에서 리눅스 파일에 접근하는 경우, 현재 WSL1을 사용해야 더 빠른 성능을 얻을 것입니다.
File performance across the Windows and Linux operating systems is faster in WSL 1 than WSL 2, so if you are using Windows applications to access Linux files, you will currently achieve faster performance with WSL 1.
하드웨어 스펙
제 컴퓨터의 SSD는 기가바이트 GP-GSTFS31240GNTD로 6Gbps SATA 케이블에 꽂혀 있습니다. CPU는 Ryzen 4350G이고, 램은 16GB입니다.
아래는 상세한 벤치마크 내용입니다.
iozone 벤치마크 결과
결과 요약
iozone으로 테스트한 결과 다음과 같았습니다.
- 첫 번째 쓰기: 2.8배 느림
- 다시 쓰기(캐시 이용): 2.4배 느림
- 첫 번째 읽기: 5.3배 느림
- 다시 읽기(캐시 이용): 10.2배 느림
데이터
읽기 성능의 차이가 생각보다 컸습니다. 다음은 데이터입니다.
| 작업 | 윈도우→윈도우 파일(MB/s) | 윈도우→WSL2 파일(MB/s) |
|---|---|---|
| 첫 번째 쓰기 | 55.73 | 19.84 |
| 다시 쓰기(캐시) | 40.80 | 17.12 |
| 첫 번째 읽기 | 119.62 | 22.69 |
| 다시 읽기(캐시) | 234.15 | 22.88 |
(보면 윈도우-윈도우의 경우에도 SSD의 최대 읽기 속도가 나오지 않는데요. iozone이 4KB 블록 크기로 읽기·쓰기 작업을 수행하기 때문에 작은 파일 크기로 인해 SSD의 최대 성능을 발휘하지 못하는 것이라고 합니다. CrystalDiskMark로도 테스트해 봤는데, 대용량 파일 테스트를 하니 최대 속도가 나왔습니다.)
CrystalDiskMark 벤치마크 결과
결과 요약
IDE에서는 작은 파일을 자주 읽고 씁니다. 따라서 블록이 4KiB인 테스트 데이터가 현실에 가깝다고 합니다.
이 때 읽기는 1.1배에서 5.4배, 쓰기는 2.7~2.8배 성능차가 발생합니다.
큐(병렬 처리 작업량)가 32인 경우에 읽기 성능은 큰 차이가 나지 않지만(1.1배) 큐가 1인 경우의 읽기, 그리고 큐와 상관없이 쓰기 성능은 큰 차이가 납니다.
아래 그래프는 그런 유형에 대한 벤치마크 결과를 보여 줍니다.
| 작업 | 윈도우→윈도우(MB/s) | 윈도우→WSL2(MB/s) | 성능차(배) |
|---|---|---|---|
| RND4K Q32T1 읽기 | 35.18 | 32.59 | 1.1 |
| RND4K Q1T1 읽기 | 18.40 | 3.41 | 5.4 |
| RND4K Q32T1 쓰기 | 86.55 | 30.76 | 2.8 |
| RND4K Q1T1 쓰기 | 59.20 | 21.60 | 2.7 |
대용량 파일 테스트 결과 요약
아래는 순차 읽기 쓰기, 블록 사이즈 1MB일 때의 성능 비교입니다.
읽기 성능은 1.1~5.3배, 쓰기 성능은 1.7~2.4배 차이납니다.
역시 큐가 클 때의 읽기 성능은 별 차이가 나지 않지만(1.1배) 나머지는 차이가 큽니다.
| 작업 | 윈도우→윈도우(MB/s) | 윈도우→WSL2(MB/s) | 성능차(배) |
|---|---|---|---|
| SEQ1M Q8T1 읽기 | 452.45 | 415.56 | 1.1 |
| SEQ1M Q1T1 읽기 | 474.65 | 89.71 | 5.3 |
| SEQ1M Q8T1 쓰기 | 355.63 | 205.53 | 1.7 |
| SEQ1M Q1T1 쓰기 | 261.70 | 110.54 | 2.4 |
테스트 상세 설명
아래는 각 테스트가 무슨 테스트인지 상세 설명입니다.
- RND4K Q32T1: 랜덤, 블록 사이즈 4KiB, 큐 32개, 스레드 1개.
- RND4K Q1T1: 랜덤, 블록 사이즈 4KiB, 큐 1개, 스레드 1개.
- RND4K Q32T1: 랜덤, 블록 사이즈 4KiB, 큐 32개, 스레드 1개.
- RND4K Q1T1: 랜덤, 블록 사이즈 4KiB, 큐 1개, 스레드 1개.
- SEQ1M Q8T1: 연속, 블록 사이즈 1MiB, 큐 8개, 스레드 1개.
- SEQ1M Q1T1: 연속, 블록 사이즈 1MiB, 큐 1개, 스레드 1개.
- SEQ1M Q8T1: 연속, 블록 사이즈 1MiB, 큐 8개, 스레드 1개.
- SEQ1M Q1T1: 연속, 블록 사이즈 1MiB, 큐 1개, 스레드 1개.
