클라우드 서버 메모리 대역폭 검사: 용량이 충족되는데도 속도가 떨어지는 이유

용량이 충분하다고 대역폭이 충분한 것은 아닙니다. 3차원 증거로 명확히 확인하세요.

업데이트됨 2026-10-07 · CloudWorth

메모리 대역폭STREAMNUMA오버셀 탐지FinOpsCloudWorthSteal TimeVPS 오버셀링VPS 점검

용량 충족이 대역폭 충족을 의미하지 않습니다. STREAM과 Steal Time, NUMA 바인딩을 교차 검증하고, 프리미엄 비율과 비교하여 업그레이드할지 환불할지 결정하세요.

용량을 먼저 측정하고, 그다음 대역폭을 측정하세요

클라우드 서버를 구매할 때, 거의 모든 사람이 첫눈에 보는 것은 메모리 용량입니다: 8GB, 16GB, 32GB. 용량은 주문 페이지에 적혀 있어 눈에 보이고 일치하므로 “메모리는 문제없다”라고 기본적으로 간주됩니다. 그러나 용량은 창고 면적일 뿐이고, 대역폭이 지게차 속도입니다 — 8GB 인스턴스는 용량이 모두 정상인 상황에서도 메모리 처리량이 동세대 표기값의 절반에 불과할 수 있습니다.

이것이 바로 용량은 기준을 충족했지만 속도가 떨어지는 전형적인 시나리오입니다: AI 추론, 벡터 검색, Redis 큰 value, JVM 힙 내 복사 같은 워크로드는 GB에 대한 민감도보다 GB/s에 대한 민감도가 훨씬 높아, 용량이 충분해도 오히려 대역폭 한계에 먼저 부딪힙니다.

먼저 두 단계로 분리합니다:

1. 용량 측면: free -h로 total/available을 확인하고, 주문 사양과 다시 대조하여 숨겨진 balloon 드라이버 회수가 없는지 확인합니다. KVM에서는 dmesg | grep -i balloon으로 확인할 수 있습니다.
2. 대역폭 측면: 용량이 일치한다고 해서 대역폭이 일치하는 것은 아니므로, 전용 메모리 처리량 테스트가 필요하며 다음 섹션에서 다룹니다.

순서는 반드시 용량 먼저, 대역폭 나중이어야 합니다. 용량이 기준에 미달하면 허위 표기이므로 바로 환불을 진행하세요; 용량은 기준을 충족하는데 대역폭이 떨어지면, 그것이 더 은밀한 초과 판매 / 속도 제한 문제이며, 아래의 증거 수집 체인을 사용해야 합니다.

경험적 판단 기준: 만약 “동일 용량이지만 가격이 눈에 띄게 한 단계 낮은” 인스턴스를 구매했다면, 일단 대역폭을 의심 항목으로 기본 설정하고, 싸게 잘 샀다고 기본 가정하지 마세요. 이런 저렴함은 종종 CPU 초과 할당, NUMA 교차 노드 배치 또는 메모리 주파수 하향에서 비롯되며, 최종적으로 가성비 프리미엄 비율의 형태로 역습합니다 — 용량은 샀지만 처리량은 사지 못한 것입니다.

원시 데이터 기록(인스턴스 사양, 리전, 이미지, 과금 유형, 주문 시간)을 마친 후, 실제 테스트에 들어갑니다. 기록 자체가 이후 티켓과 사양 축소 결정의 증거가 되며, 티켓에 “메모리가 매우 느리다”라고만 적으면 거의 효과적인 처리를 받지 못합니다.

STREAM과 sysbench 실측

메모리 대역폭 검사에는 상호 보완적인 두 가지 도구가 있습니다. STREAM은 지속 가능한 벡터 처리량(Copy/Scale/Add/Triad)을 측정하고, sysbench memory는 더 '작은 블록 읽기/쓰기'에 가까운 시나리오를 측정합니다. 클라우드 서버를 위한 sysbench vs STREAM 메모리 대역폭 테스트 논쟁은 의미가 없습니다. 둘 다 실행해야 하는데, 왜냐하면 왜곡되는 방향이 서로 다르기 때문입니다. STREAM은 소형 인스턴스의 L3 캐시에 지나치게 우호적이고, sysbench는 명령 오버헤드에 지나치게 민감하므로, 교차 확인해야 단일 수치에 속지 않습니다.

STREAM 사용법(root 없이 홈 디렉터리에 컴파일 가능):

sudo apt install -y gcc gfortran make
# 下载 stream.c 后：
gcc -O3 -fopenmp -DSTREAM_ARRAY_SIZE=200000000 stream.c -o stream
OMP_NUM_THREADS=$(nproc) ./stream

배열 크기는 메모리의 1/4~1/2로 설정합니다. 너무 작으면 모두 캐시에 들어가 '부풀려진 대역폭'이 나옵니다. 그렇지 않으면 DRAM이 아니라 L3를 측정하게 됩니다.

sysbench 쪽:

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

판단 포인트는 세 가지입니다:

• 단일 코어 vs 전체 코어: taskset -c 0과 전체 코어를 각각 실행하고 GB/s를 기록합니다. 전체 코어에서 거의 늘지 않으면 대역폭이 이미 제한된 것이지, 코어 수가 부족한 것이 아닙니다.
• 공칭 사양과 비교: DDR4와 DDR5의 세대 차이는 약 1.5~2배 수준이며, 같은 세대 같은 주파수의 클라우드 인스턴스 사이에 2~3배 차이가 나서는 안 됩니다. 나온다면 이상입니다.
• vCPU당 대역폭으로 환산: 총 대역폭 / vCPU 수는 메모리 대역폭 오버서브스크립션을 판단하는 가장 실용적인 지표입니다. 공유형 인스턴스의 vCPU당 대역폭은 전용형의 절반에 불과한 경우가 많으며, 이것이 클라우드 서버 프리미엄률의 실제 원천 중 하나입니다.

세 번 실행해 중앙값을 취하고, 정각에 몰리는 이웃 피크를 피하십시오. 이 숫자들을 vCPU당 대역폭과 프리미엄률로 자동 환산하려면 /app에서 템플릿을 만들고 STREAM, sysbench, 인스턴스 가격을 함께 입력해 비교 가능한 가성비 프로필을 생성할 수 있습니다. 다음 섹션에서는 Steal Time과 NUMA로 '속도 저하'를 구체적인 원인에 귀속시킵니다.

Steal Time과 NUMA 포렌식

이전 섹션에서는 '속도 저하'만 증명할 수 있었고, 원인 분석은 다른 두 지표에 의존해야 합니다: Steal Time과 NUMA 토폴로지. 이는 클라우드 서버 메모리 대역폭 검사에서 가장 쉽게 건너뛰는 계층이기도 합니다—용량은 충분하고 단독 실행도 기준을 충족하지만, 병목은 스케줄링과 메모리 선호도에 숨어 있습니다. 공식 스펙 페이지에는 이 두 항목이 결코 적혀 있지 않으며, 실제 벤치마크 점수의 차이는 종종 여기서 발생합니다.

먼저 st를 확인합니다:

vmstat 1 10        # 盯 st 列（Steal Time）
mpstat -P ALL 1    # 逐核 %steal

st가 장기적으로 >3%이고 대역폭 하락과 동기화된다면, vCPU 시간이 이웃에 의해 빌려가고 있음을 의미합니다. 공유형 KVM에서 CPU steal과 메모리 대역폭의 상관관계는 매우 높으며, 떨어지는 것은 전체 경로이지 단순한 연산 능력만이 아닙니다.

다음으로 NUMA를 봅니다:

lscpu | grep -i numa
numactl --hardware
numactl --cpunodebind=0 --membind=0 \
  sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read run

프로세스를 로컬 노드에 바인딩한 후 대역폭이 뚜렷하게 회복되면, 이는 노드 간 페널티(일반적으로 20%～40%)이지 오버셀링이 아닙니다; 바인딩 후에도 여전히 1인당 대역폭 상한에 붙어 있다면, 그게 진짜 속도 제한입니다.

st, NUMA 토폴로지, 바인딩 전후 대역폭 세 가지 스크린샷을 가지고 티켓을 여는 것이 '느려졌다'고 말로만 하는 것보다 훨씬 효과적입니다. 재사용 가능한 포렌식 템플릿으로 정착시키고 싶다면, /app에서 이 세 수치와 지불한 단가를 함께 놓고, 프리미엄 비율을 계산한 후 업그레이드, 가용 영역 변경, 또는 환불 절차를 결정하세요.

디스크 캐시 절벽 검증

NUMA 바인딩 후에도 대역폭이 여전히 천장에 붙어 있다면, 마지막 증거가 하나 남았습니다: 캐시 절벽으로 ‘메모리 느림’과 ‘디스크 느림’을 분리하는 것입니다. 방법은 같은 파일을 먼저 핫 리드하고, 다음에 콜드 리드하면서 어느 워킹셋 크기에서 대역폭이 떨어지는지 보는 것입니다.

# 1) 热路径：让 page cache 命中，测的是缓存速度
fio --name=hot --filename=/data/blob --rw=read --bs=1M \
    --size=4G --direct=0 --runtime=30 --time_based

# 2) 冷路径：清缓存后测真实内存→IO 通路
sync && echo 3 > /proc/sys/vm/drop_caches
fio --name=cold --filename=/data/blob --rw=read --bs=1M \
    --size=4G --direct=1 --runtime=30 --time_based

해석 포인트:

• 콜드 리드 대역폭이 워킹셋이 256M에서 4G로 커질 때 완만하게 감소하는 것은 정상적인 메모리 계층과 프리페치 동작입니다;
• 절벽처럼 떨어지고(예: 2G 전후에서 곧바로 반토막), 변곡점이 인스턴스의 공식 L3/캐시 예상치보다 훨씬 작다면, 보통 메모리 대역폭이 스로틀링되고 있음을 의미하며 디스크가 먼저 버티지 못한 것은 아닙니다;
• 겸사겸사 vmstat 1의 bi/bo와 si/so를 보세요. IO는 높지 않은데 처리량이 급감한다면 문제는 대개 메모리 쪽입니다.

이것은 또한 ‘실제 벤치마크 vs 공식 스펙’에서 가장 쉽게 무너지는 부분입니다: 8GB 인스턴스의 DDR4/DDR5 표기와 용량은 틀리지 않았지만, AI 추론의 KV cache나 벡터 검색이 워킹셋을 캐시 밖으로 밀어내면 대역폭이 먼저 떨어지고 지연이 곧바로 흔들립니다. 절벽 지점, NUMA 바인딩 전후 대역폭, %steal 세 수치와 실제 지불 단가를 함께 놓고 프리미엄 비율을 계산한 뒤, 업그레이드할지, 가용 영역을 바꿀지, 환불을 받을지 결정하는 것이 반복 재부팅보다 훨씬 효과적입니다. 바로 쓸 수 있는 증거 수집 템플릿이 필요하면 /app에서 그대로 적용할 수 있습니다.

한 줄로: 용량 충족은 입장권일 뿐, 클라우드 서버 메모리 대역폭 검사에서 봐야 할 것은 속도 저하의 변곡점이 어디인지, 그리고 변곡점 이후에도 어떤 가격으로 비용을 지불하고 있는지입니다.

벤치마크 대조와 가격 프리미엄 판단

앞서 세 가지 객관적 데이터를 확보했다: STREAM의 Copy/Triad, NUMA 바인딩 전후의 대역폭 차이, 그리고 %steal 곡선. 이제 마지막 한 단계만 남았다 — 이들을 청구서와 맞춰 보는 것이다. 방법은 간단하다. 같은 인스턴스의 '공칭 vs 실측'을 두 열로 적으면 된다:

# 실측 대역폭(GB/s)
sysbench memory --memory-block-size=1M --memory-total-size=10G run | grep transferred
# 단가(위안/GB 메모리/월) = 월 요금 / 공칭 용량
# 가성비 = 실측 대역폭 / 단가

판독 기준은 조금 거칠어도 되지만, 숫자는 반드시 있어야 한다:

• 실측 대역폭이 동세대 DDR4/DDR5 공개값의 70% 이상이고, %steal이 평시 2% 미만이다: 정상적인 공유 환경이므로 계속 사용한다;
• 대역폭이 공칭 예상치의 50%～70%에 불과하고, NUMA 바인딩으로 15%+를 되찾을 수 있다: 스케줄링 문제에 해당하므로, 가용 영역을 바꾸거나 vCPU 친화성을 지정하는 것이 보통 업그레이드보다 저렴하다;
• 대역폭이 50% 미만이고 %steal이 장기간 5% 이상이며 캐시 절벽이 예상보다 일찍 나타난다: 이것이 전형적인 VPS 오버셀링 신호이며, 클라우드 서버 오버셀링을 탐지하는 확실한 증거다.

가성비를 계산한 다음에 조치를 논하라. 8GB 인스턴스의 월 요금이 120위안이고, 실측 대역폭이 같은 가격대 AMD EPYC 인스턴스의 60%에 불과하다고 가정하자. 그러면 당신의 가격 프리미엄률은 사실상 40%다 — 이때 16GB로 업그레이드하는 것은 대개 'GB당 더 비싼' 구조를 키울 뿐이므로, 인스턴스 유형을 바꾸거나 환불을 진행하는 편이 더 이득이다. 업그레이드 전에는 먼저 가격 프리미엄률을 계산하고, 환불 전에는 먼저 증거를 남겨라: 세 번의 벤치마크 원본 출력, vmstat의 %steal, numactl --hardware 스크린샷을 함께 제출하고, 티켓에는 형용사 없이 데이터만 적어라. 그러면 이의 제기 성공률이 훨씬 높아진다. 갱신 전에도 똑같이 한 번 돌려서, 갱신 시 몰래 사양이 낮아지는 일을 막아라. 완전한 증거 수집 표와 티켓 템플릿은 /guides/memory-bandwidth-checklist에 있으니, 그대로 베껴도 된다.

결론을 기억하라: 용량이 기준을 충족한다고 해서 대역폭도 기준을 충족하는 것은 아니다. STREAM에 Steal Time과 NUMA 바인딩을 더해 교차 검증하고, 가격 프리미엄률과 대조해 업그레이드할지 환불할지 결정하라.