VPS 벤치마크 제대로 하는 방법과 수치 해석

VPS 벤치마크의 의미

VPS를 벤치마크할 때는 4가지를 측정합니다. 단일 CPU 코어가 얼마나 빠르게 실행되는지, 시스템의 메모리 대역폭이 얼마나 되는지, 스토리지가 초당 소규모 임의 디스크 작업을 몇 건 처리하는지, 네트워크 링크가 얼마나 많은 처리량을 제공하는지 측정합니다. yabs.sh를 1회 실행하면 약 10분 안에 4가지 결과를 모두 얻을 수 있습니다. 결과를 해석하는 일이 더 어렵습니다. VPS(virtual private server)는 다른 테넌트와 물리 하드웨어를 공유하기 때문입니다. 따라서 동일한 시스템도 03:00에는 1개의 수치를 보고하고 20:00에는 크게 다른 수치를 보고할 수 있습니다.

여기서는 먼저 yabs.sh를 실행해 개괄적인 상태를 확인한 다음, 그 내부에서 사용하는 도구를 직접 실행합니다. 도구를 직접 실행하면 플래그 1개를 변경하고 수치가 어떻게 달라지는지 확인하면서 해당 수치가 실제로 무엇을 측정하는지 파악할 수 있습니다. 이 작업은 시스템을 설정한 후에 수행해야 합니다. 설정하기 전에는 수행하지 않습니다. 새 VPS에서 처음 10분 동안 수행할 작업의 단계가 먼저입니다. 첫 번째 업데이트를 아직 적용 중인 시스템은 하드웨어와 관계없는 이유로 벤치마크 결과가 부정확하기 때문입니다.

측정하기 전에 시스템을 확인합니다

모든 잘못된 벤치마크의 절반은 작성자가 이해하지 못한 시스템에서 발생합니다.

nproc
lscpu | grep -E 'Model name|Hypervisor|Thread'
free -h
df -hT /
uname -r
systemd-detect-virt

Hypervisor vendor: KVM은 완전 가상화를 의미하므로 자체 커널을 실행합니다. systemd-detect-virt 인쇄 결과가 lxc 또는 openvz이면 컨테이너 가상화를 사용한다는 뜻입니다. 이 경우 호스트 커널을 공유하며 CPU 및 메모리 제한은 가상 하드웨어가 아니라 cgroup (control group) 설정으로 적용됩니다. cgroup v2 시스템에서는 CPU 제한을 직접 확인할 수 있습니다.

cat /sys/fs/cgroup/cpu.max

max 100000는 할당량이 없다는 뜻입니다. 200000 100000은 100000마이크로초 주기마다 CPU를 200000마이크로초 사용할 수 있다는 뜻이며, 이는 2코어에 해당하는 할당량입니다. 4 vCPU로 광고된 요금제가 2코어 할당량만 제공한다면 4코어와 같은 점수를 받을 수 없습니다. 또한 어떤 벤치마크 도구도 그 이유를 설명하는 행을 출력하지 않습니다.

다른 이유로 df -hT /도 중요합니다. Type 열을 확인해야 하기 때문입니다. 이 값이 overlay이면 컨테이너 내부에 있는 것이므로 아래의 디스크 테스트를 변경해야 합니다. 지금 확인해 두십시오.

steal time을 전체 시간 동안 모니터링

steal time은 가상 CPU가 실행할 준비가 되었지만 하이퍼바이저가 물리 코어를 다른 작업에 할당한 시간의 비율입니다. 이 값은 결과가 하드웨어가 아니라 같은 호스트의 다른 사용자 때문에 발생했는지 판단하는 데 가장 유용한 단일 지표입니다.

vmstat 1 10

오른쪽의 st 열을 확인합니다. 값이 0 또는 1로 안정적으로 유지되면 정상입니다. 5를 초과하는 값이 지속되면 해당 시점에 호스트의 리소스가 과도하게 할당된 상태입니다. 따라서 그 시간대에 기록하는 모든 CPU 수치는 시스템의 문제와 관계없이 낮게 나타납니다. top은 CPU 줄에서 %st와 동일한 값을 표시합니다. 벤치마크를 실행하는 동안 별도의 SSH 세션에서 vmstat 1을 계속 실행하고, 각 결과 옆에 steal 수치를 기록합니다.

yabs.sh로 시작하기

yabs.sh (Yet Another Bench Script)은 정적 fio, iperf3 및 Geekbench 바이너리를 다운로드하고 실행한 후 결과를 하나의 요약으로 출력하는 shell script입니다. VPS 벤치마크 논의에서 공통으로 사용하는 도구이므로, yabs 출력은 다른 사람의 결과와 비교할 때 가장 빠른 방법입니다.

프로젝트에서 제공하는 한 줄 실행 형식은 다음과 같습니다.

curl -sL yabs.sh | bash

이 명령은 URL이 현재 제공하는 내용을 그대로 shell에 전달합니다. 먼저 다운로드하고 내용을 확인한 후 실행하십시오.

curl -sLo yabs.sh https://raw.githubusercontent.com/masonr/yet-another-bench-script/master/yabs.sh
less yabs.sh
bash yabs.sh

파이프를 사용할 때는 -s -- 뒤에 플래그를 지정합니다. 로컬 복사본을 실행할 때는 파일 이름 바로 뒤에 지정합니다. 유용한 플래그는 다음과 같습니다. -f은 디스크 테스트를 건너뛰고, -i은 네트워크 테스트를 건너뛰며, -g은 Geekbench를 건너뜁니다. -r는 iperf3 위치를 2개로 줄이고, -j은 결과를 JSON으로 출력하며, -w results.json은 해당 JSON을 파일에 기록합니다.

bash yabs.sh -r -w yabs-run1.json

첫 실행 전에 알아야 할 사항이 2가지 있습니다. Geekbench는 결과를 업로드하고 공개된 browser.geekbench.com URL을 출력합니다. 따라서 해당 링크를 가진 사람은 누구나 CPU 모델과 점수를 확인할 수 있습니다. -g를 사용하면 이 테스트를 완전히 건너뜁니다. 둘째, iperf3 단계에서는 여러 리전에 있는 서버로 실제 네트워크 트래픽을 전송하므로 월간 bandwidth allowance가 차감됩니다. 1 Gbit/s 링크에서는 전체 네트워크 단계가 수십 GB를 전송할 수 있습니다. 따라서 allowance가 적으면 -r을 사용하고, 종량제 링크에서는 -i를 사용하십시오.

yabs 출력의 각 부분이 의미하는 내용

디스크 섹션은 4k, 64k, 512k, 1m의 4가지 블록 크기에서 읽기와 쓰기를 50/50 비율로 혼합하여 fio를 실행합니다. 각 블록 크기에 대한 IOPS(초당 입력/출력 작업 수)와 대역폭을 보고합니다. 데이터베이스, 메일 서버 또는 작은 쓰기 작업을 많이 수행하는 시스템에서는 4k 행을 확인해야 합니다. 대부분의 서버 IO는 작은 크기로 분산되어 처리되기 때문입니다. 1m 행은 백업이나 비디오처럼 연속된 데이터를 이동하는 작업에 해당합니다.

네트워크 섹션은 여러 리전에 있는 공용 서버를 대상으로 iperf3를 양방향으로 실행하며, 병렬 스트림을 사용합니다. 여기서 낮은 수치가 나오면 이를 결론이 아니라 확인이 필요한 결과로 보아야 합니다. 공용 iperf3 서버는 여러 사용자가 공유하며 자주 포화되므로, 낮은 결과가 원격 측의 문제일 수 있습니다.

Geekbench 섹션은 싱글 코어 점수와 멀티 코어 점수를 제공합니다. 싱글 코어 점수는 하나의 요청, 컴파일 작업 또는 쿼리가 얼마나 빠르게 완료되는지 예측하는 데 사용됩니다. 멀티 코어 점수는 실제로 사용할 수 있는 코어 수를 주로 보여 줍니다.

디스크: 직접 fio 실행

fio(flexible IO tester)는 yabs의 디스크 섹션에서 사용하는 도구입니다. 직접 실행하면 각 플래그의 의미를 이해할 수 있습니다.

sudo apt update && sudo apt install -y fio sysbench iperf3

실제로 사용할 파일 시스템에서 큐 깊이 32로 4k 무작위 읽기 테스트를 실행합니다.

fio --name=randread4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randread --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting

출력에서 확인할 요약 줄은 다음과 같습니다.

read: IOPS=184k, BW=719MiB/s (754MB/s)(42.1GiB/60001msec)

그 아래에서 fio는 clat percentiles 블록을 출력합니다. 인용할 값은 99.00번째 백분위수입니다. 요청 100개 중 가장 느린 요청 1개가 대기한 시간을 나타내기 때문입니다. 평균 지연 시간은 사용자가 실제로 인지하는 지연을 숨깁니다.

• --direct=1은 O_DIRECT을 사용해 파일을 엽니다. 따라서 읽기 작업이 kernel page cache를 우회합니다. 이 옵션이 없으면 RAM이 8G인 시스템에서 2G 파일을 두 번째로 읽을 때 메모리에서 처리됩니다. 그러면 fio가 IOPS를 수백만 단위로 보고합니다. 이 수치는 실제 값이지만 메모리 성능을 나타냅니다.
• --ioengine=libaio은 비동기 요청을 제출합니다. 따라서 --iodepth=32이 32개의 요청을 동시에 처리할 수 있습니다. psync과 같은 동기식 엔진에서는 iodepth가 1보다 커도 아무런 효과가 없습니다. 요청을 한 번에 하나씩 측정하게 됩니다.
• --time_based --runtime=60은 고정된 작업량이 아니라 60초 동안 실행합니다. 따라서 빠른 디스크와 느린 디스크에 동일한 실제 시간이 적용되고 비교가 공정해집니다.
• --size=2G은 테스트 파일 크기를 설정합니다. 경로에 있는 모든 캐시보다 크게 설정하고, 먼저 디스크에 충분한 여유 공간이 있는지 확인합니다.

무작위 쓰기는 --rw=randwrite을 사용하면 됩니다. 별도로 실행한 다음 파일을 삭제합니다.

fio --name=randwrite4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randwrite --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting
rm -f ./fio-testfile

실제 네트워크 트래픽에 더 가까운 혼합 작업에는 --rw=randrw --rwmixread=70을 사용합니다. 사용하는 스토리지 유형은 어떤 플래그보다 결과에 큰 영향을 줍니다. 이 차이는 VPS에서 NVMe와 SATA SSD 스토리지의 차이에서 설명합니다.

fio가 Unknown error -1로 종료되는 경우

모든 파일시스템에서 Direct IO를 사용할 수 있는 것은 아닙니다. overlay는 Docker가 컨테이너에 기본으로 제공하는 파일시스템이며, 여러 네트워크 파일시스템도 O_DIRECT을 지원하지 않습니다. 따라서 libaio가 커널에서 완료할 수 없는 요청을 제출하고 fio가 중단됩니다.

fio: io_u error on file ./fio-testfile: Unknown error -1: read offset=0, buflen=4096
fio: pid=1234, err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1

먼저 df -hT .을 실행합니다. Type 열에 overlay가 표시되면 --filename을 bind mounted volume과 같은 실제 스토리지의 경로로 지정하거나, 컨테이너 내부가 아니라 호스트에서 fio를 실행합니다. 실제 스토리지에 접근할 수 없다면 buffered synchronous 실행으로 명령 자체가 올바른지라도 확인할 수 있습니다.

fio --name=randread4k-buffered --filename=./fio-testfile --size=256M --bs=4k \
  --rw=randread --ioengine=psync --direct=0 --numjobs=1 \
  --runtime=15 --time_based --group_reporting
rm -f ./fio-testfile

이 실행 결과의 의미를 정확히 파악해야 합니다. 첫 번째 실행이 끝나면 256M 파일이 page cache에 남으므로 IOPS 수치는 RAM의 성능을 나타냅니다. 이 결과는 fio가 설치되어 있고 플래그가 올바르게 해석되는지 확인하는 용도로만 사용합니다. 디스크 성능 결과로 인용해서는 안 됩니다.

dd가 디스크 벤치마크가 아닌 이유

dd은 많은 VPS 게시물에 등장하며, 한 가지 좁은 질문에 답합니다.

dd if=/dev/zero of=./ddtest bs=1M count=1024 oflag=direct conv=fdatasync
rm -f ./ddtest

이 명령은 단일 스레드와 단일 미처리 요청으로 순차 쓰기 처리량을 측정합니다. 기본적인 정상 여부를 확인하는 데는 적절합니다. 무작위 IO에 대해서는 아무것도 알려 주지 않으며, 32개의 요청이 동시에 도착할 때 어떤 일이 발생하는지도 알 수 없습니다. oflag=direct을 생략하면 커널이 메모리에 쓰기를 수용하는 속도를 대부분 측정하게 됩니다. 따라서 포럼 게시물에 인용된 dd 수치가 터무니없는 경우가 많습니다.

CPU: sysbench cpu

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

기준으로 사용할 수치는 events per second입니다. 먼저 단일 스레드로 실행합니다. 이 수치는 하나의 PHP 요청이 완료되거나 하나의 컴파일 작업이 끝나는 속도를 결정하며, 같은 가격대의 호스트 간 차이가 가장 크게 나타납니다. 그런 다음 모든 스레드로 실행합니다. 이를 통해 vCPU가 별도의 코어인지, 하나의 코어를 나누어 사용하는지 확인할 수 있습니다.

이 테스트가 측정하는 범위를 명확히 이해해야 합니다. sysbench cpu는 64비트 정수 연산을 사용해 소수를 반복해서 찾습니다. 실제 워크로드와 유사한 방식으로 메모리 대역폭, 벡터 유닛 또는 캐시를 집중적으로 사용하지는 않습니다. 따라서 두 호스트의 순위를 비교하는 데는 유용하지만, 애플리케이션의 실제 실행 성능을 예측하는 데는 적합하지 않습니다.

Ubuntu 24.04에는 테스트 이름을 먼저 지정하는 sysbench 1.0.20이 포함되어 있습니다. 이전 게시물에서 --test=cpu가 포함된 명령을 복사하면 WARNING: the --test option is deprecated이 됩니다. sysbench 0.4와 sysbench 1.0의 점수는 전혀 비교할 수 없습니다. 따라서 버전을 명시하지 않은 게시된 수치와 자신의 결과를 절대 비교하지 마십시오.

메모리: sysbench memory

sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=write --threads=1 run
sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read --threads=1 run

결과 단위는 MiB/sec이며, 모든 시스템에서 읽기 속도가 쓰기보다 빠르게 나타납니다. --memory-block-size은 1M으로 설정하고, 비교하는 모든 호스트에서 동일하게 유지합니다. 1K에서는 작업당 오버헤드를 1,000배 더 자주 부담하므로 수치가 급격히 낮아집니다. 따라서 메모리 대역폭이 아니라 반복문 실행 비용을 측정하게 됩니다. 이 플래그는 공개된 메모리 성능 점수에서 가장 자주 일치하지 않는 항목입니다.

Network: iperf3

처리량을 정확하게 테스트하려면 관리하는 두 번째 머신을 대상으로 테스트해야 합니다. 그러면 양쪽에서 어떤 작업이 수행되는지 확인할 수 있습니다.

원격 측에서 다음을 실행합니다.

iperf3 -s

이 명령은 TCP 5201에서 연결을 수신 대기합니다. 테스트를 수행하는 주소에 대해서만 포트를 열고, 테스트가 끝나면 닫습니다. VPS의 기본 ufw 방화벽 규칙에서 구문을 설명합니다.

테스트 대상 VPS에서 다음을 실행합니다.

iperf3 -c 203.0.113.10 -t 30
iperf3 -c 203.0.113.10 -t 30 -R
iperf3 -c 203.0.113.10 -t 30 -P 8

첫 번째 명령은 테스트 대상 머신에서 업로드를 측정합니다. -R는 방향을 반대로 전환하여 다운로드를 측정합니다. -P 8은 8개의 병렬 스트림을 엽니다.

단일 스트림과 병렬 버전을 모두 실행해야 합니다. 두 명령은 서로 다른 질문에 답하기 때문입니다. 하나의 TCP 연결은 윈도우가 허용하는 만큼의 미확인 데이터만 보낼 수 있습니다. 따라서 한계 처리량은 대략 윈도우 크기를 왕복 시간으로 나눈 값입니다. 지연 시간이 80 ms이고 윈도우 크기가 4 MB이면, 하위 링크가 아무리 빨라도 한계는 약 400 Mbit/s입니다. 단일 스트림 수치는 하나의 다운로드가 얻을 처리량을 보여 줍니다. 병렬 수치는 링크의 용량을 보여 줍니다.

이 테스트를 실행하는 동안 대역폭 허용량을 확인해야 합니다. 1 Gbit/s로 30초 동안 전송하면 약 3.75 GB가 이동합니다. 또한 각 방향으로 여러 번 실행하게 됩니다.

기준 수치와 측정 결과 해석 방법

[
  {
    "device": "Local NVMe",
    "iops_4k_read": "180,000"
  },
  {
    "device": "Local SATA SSD",
    "iops_4k_read": "90,000"
  },
  {
    "device": "Network block",
    "iops_4k_read": "12,000"
  },
  {
    "device": "Spinning disk",
    "iops_4k_read": "180"
  }
]

공개된 결과에서 로컬 NVMe 볼륨은 일반적으로 180,000 4k 무작위 읽기 IOPS에 가깝습니다. 로컬 SATA SSD는 약 90,000입니다. 모든 요청이 디스크에 도달하기 전에 네트워크를 통과하는 네트워크 연결 블록 스토리지는 12,000에 더 가깝습니다. 회전식 디스크는 무작위 요청마다 물리 헤드를 이동해야 하므로 대략 180을 처리합니다.

이 수치는 각 스토리지 유형에 대해 공개된 일반적인 값이며, 특정 호스트에서 측정한 값이 아닙니다. 이 수치는 한 가지 목적으로만 사용합니다. 직접 측정한 결과가 대략적으로 적절한 규모인지 확인하는 용도입니다. NVMe로 판매된 요금제의 벤치마크 결과가 4k IOPS 기준으로 수천 단위에 불과하다면 먼저 --direct=1이 활성화되어 있었는지 확인합니다. 활성화되어 있었다면 스토리지가 제품 페이지의 설명과 다르거나, 매우 부하가 높은 다른 사용자와 스토리지를 공유하고 있는 것입니다.

한 번의 실행은 벤치마크가 아니다

단일 결과는 공유 시스템에서 1분 동안 측정한 스냅샷입니다. 하나의 샘플로 취급해야 합니다.

• 모든 테스트를 최소 5회 실행합니다. 실행 시간은 서로 다른 시간대로 분산하고, 최소 2일에 걸쳐 진행합니다. 중앙값과 분산 범위를 기록합니다. 분산 범위 없이 게시된 결과는 마케팅 수치입니다.
• 각 실행 결과 옆에 steal time을 기록합니다. st가 높았던 실행 결과는 제외하거나, 최소한 해당 사실을 기록합니다.
• 디스크 테스트를 2가지 지속 시간으로 실행합니다. 많은 요금제가 시간이 지나면 다시 충전되는 burst IOPS allowance를 제공합니다. 따라서 60초 fio 실행은 burst를 측정하고, --runtime=600는 하한을 측정합니다. 하한은 상태가 나쁜 날에 얻는 성능입니다.
• 다른 작업이 실행 중이지 않은지 확인합니다. CPU 테스트 중간에 unattended-upgrades가 apt transaction을 시작하면 실제 점수가 낮아집니다. 또한 각 실행 전에 ps -e -o comm= | grep -E 'apt|dpkg'를 수행하는 데 1초가 걸립니다.
• 한 번에 변수 하나만 변경합니다. 도구 버전, block size 또는 thread 수가 다르면 수치가 아무리 비슷해 보여도 서로 비교할 수 없습니다.

두 provider를 비교할 때는 같은 날 같은 시간에 실행합니다. 그렇지 않으면 측정한 것은 시간대입니다.

자체 워크로드를 마지막에 벤치마크합니다

Synthetic 도구는 시스템의 순위를 매깁니다. 시스템이 충분한지는 자체 워크로드만 알려 줍니다. 실제로 수행하는 작업의 시간을 측정합니다.

time tar -czf /tmp/bench.tgz /usr/share
rm -f /tmp/bench.tgz

이 작업은 수백 메가바이트를 압축하므로 CPU와 디스크를 함께 사용합니다. 따라서 둘 중 하나가 변경되면 측정 결과도 달라집니다. Removing leading / from member names 경고는 정상입니다. 더 좋은 방법은 자체 빌드, 가장 느린 쿼리 또는 자체 페이지 렌더링의 시간을 측정하는 것입니다. 한 호스트에서 4분, 다른 호스트에서 7분이 걸리는 빌드라면 Geekbench의 결과와 관계없이 어느 쪽이 나은지 알 수 있습니다. 또한 이 측정은 더 많은 시스템 자원에 비용을 지불해도 더 이상 가치가 없어지는 시점을 알려 줍니다. VPS의 실제 월별 비용을 확인하거나 워크로드를 dedicated server로 이전하기 전에 알아 두면 유용합니다.

FAQ

실행할 때마다 벤치마크 결과가 다른 이유는 무엇입니까?

VPS는 다른 테넌트와 물리 CPU, 스토리지 및 네트워크를 공유합니다. 따라서 결과는 해당 시점에 다른 테넌트가 무엇을 하는지에 따라 달라집니다. 테스트 중에 vmstat 1을 실행하고 st 열을 확인합니다. 지속적인 steal time이 5를 초과하면 호스트가 사용 중이었던 것이며, CPU 점수가 낮은 이유는 사용자 시스템 외부에 있습니다. 해결 방법은 튜닝이 아니라 측정 방법을 개선하는 것입니다. 각 테스트를 서로 다른 시간대에 5회 이상 실행한 다음, 변동 범위와 함께 중앙값을 보고합니다.

fio가 수백만 IOPS를 보고하는 이유는 무엇입니까?

거의 항상 --direct=1가 없기 때문입니다. 이 옵션이 없으면 fio가 kernel page cache를 통해 읽습니다. 따라서 첫 번째 통과 후에는 2G 테스트 파일이 RAM에서 제공되며, 실제로 측정한 것은 메모리 대역폭입니다. --direct=1를 추가하고 테스트 파일을 경로상의 어떤 캐시보다 크게 유지합니다. 이후 --direct=1이 err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1와 함께 실패하면 df -hT .을 실행합니다. Type의 overlay는 O_DIRECT을 지원하지 않으므로 테스트 대상을 실제 스토리지로 지정해야 합니다.

yabs.sh만으로 충분합니까?

처음 확인하는 용도라면 충분합니다. yabs.sh는 4가지 블록 크기로 fio를 실행하고, 양방향으로 iperf3를 실행하며, 다른 사람이 읽을 수 있는 요약 하나를 출력합니다. 그러나 수치가 왜 그렇게 나왔는지 확인하려는 경우에는 충분하지 않습니다. 테스트별로 플래그를 변경할 수 없기 때문입니다. yabs 결과가 이상해 보이면 fio 또는 sysbench를 직접 실행하여 재현하고, 한 번에 플래그 하나만 변경합니다.

애플리케이션의 체감 성능을 예측하는 단일 수치는 무엇입니까?

대부분의 웹 및 데이터베이스 워크로드에서는 단일 코어 CPU 속도와 4k 랜덤 읽기 지연 시간이 중요하며, 우선순위도 이 순서입니다. 일반적인 요청은 작기 때문에 처리량 수치는 인상적으로 보이지만 실제 결과를 결정하는 경우는 드뭅니다. 평균값 대신 fio의 clat percentiles 블록에서 99번째 백분위수를 인용합니다. 100건 중 느린 1건이 사용자가 체감하는 요청이기 때문입니다.

벤치마크 전에 무엇인가를 설치해야 합니까?

fio, sysbench 및 iperf3는 모두 Ubuntu 및 Debian 아카이브에 있습니다: sudo apt install -y fio sysbench iperf3. yabs.sh에는 curl만 필요합니다. 누락된 항목에 사용할 정적 바이너리를 다운로드하기 때문입니다. 작업을 마치면 모든 테스트 파일을 삭제합니다. 20G 디스크에 남겨 둔 2G fio 파일이 몇 주 후 다른 사람에게 디스크 공간 부족 경고를 발생시킬 수 있습니다.