13강 / 20강

버스와 입출력 — CPU가 기다리지 않는 법

PCIe · 인터럽트 · DMA, 그리고 네트워크 카드

지금까지 CPU·메모리·디스크를 봤습니다. 그런데 이들이 어떻게 서로 이야기할까요?

그리고 더 중요한 질문 — 디스크에서 1MB를 읽어 오는 동안(0.15ms 정도) CPU는 무엇을 하고 있을까요? 멍하니 기다린다면 엄청난 낭비입니다.

고등학생CPU 가 기다리지 않는 법

7강 표를 다시 봅시다. 디스크는 CPU 보다 백만 배 느립니다.

CPU 가 디스크를 지켜보고 있으면 백만 사이클을 논다

그래서 두 가지 발명이 나옵니다

발명	해결
인터럽트	"다 되면 불러 줘"
DMA	"자료는 알아서 옮겨 줘"

둘 다 CPU 를 해방시키는 장치다

비유 — 라면 끓이기

방식	비유
폴링	냄비 앞에서 계속 들여다본다
인터럽트	타이머를 맞추고 딴 일을 한다

끓을 때까지 다른 일을 할 수 있다

DMA 는 한 걸음 더

인터럽트로 알림은 받았는데, 자료를 옮기는 건 여전히 CPU 일입니다.

DMA 는 전용 일꾼이 옮겨 줍니다. CPU 는 "끝났다" 는 알림만 받으면 돼요.

배달을 시키면 받는 것도 남이 해 주는 셈

이 두 장치 덕에 서버가 디스크를 기다리면서도 다른 요청을 처리합니다.

버스 — 부품들을 잇는 고속도로

요즘 서버의 주된 통로는 PCIe입니다. 차선 수(x1, x4, x16)와 세대(Gen3, Gen4, Gen5)로 속도가 정해져요.

고등학생PCIe — 부품들을 잇는 길

CPU · 메모리 · SSD · 네트워크 카드가 어떻게 이어져 있을까요?

요즘은 대부분 PCIe 라는 길로 이어진다

레인 — 차선 수

PCIe 는 차선이 있습니다. x1, x4, x8, x16 이렇게요.

장치	보통 차선
NVMe SSD	x4
네트워크 카드	x4~x8
GPU	x16

차선이 두 배면 대역폭도 두 배

그런데 차선 수가 한정돼 있습니다

CPU 가 제공하는 레인이 정해져 있어요. 보통 20~128개 입니다.

꽂는 것	레인
GPU 하나	16
NVMe 4개	16
네트워크 2개	16
합	48

서버용 CPU 가 비싼 이유 중 하나가 레인 수다

비유 — 콘센트

방에 콘센트가 4구 입니다. 기기가 6개면? 멀티탭을 씁니다.

그런데 멀티탭에 다 꽂으면 전력을 나눠 씁니다. PCIe 스위치도 똑같아요 — 대역폭을 나눕니다.

꽂히긴 하는데 제 속도가 안 난다 — 흔한 함정

관리자가 확인할 것

NVMe 를 x4 슬롯이 아니라 x1 슬롯에 꽂으면 속도가 1/4 로 떨어집니다. 오류는 안 나고요.

lspci -vv 로 실제 링크 속도를 확인한다

PCIe 차선 수 × 세대 = 대역폭.

Python 브라우저에서 실행

# PCIe 세대별 한 차선(lane) 당 속도 (실효, GB/s)
세대 = {"Gen3": 0.985, "Gen4": 1.969, "Gen5": 3.938}

print(f"{'세대':<8}{'x1':>9}{'x4':>10}{'x8':>10}{'x16':>10}   (GB/s)")
print("-" * 50)
for 이름, 차선당 in 세대.items():
    print(f"{이름:<8}", end="")
    for 차선 in [1, 4, 8, 16]:
        print(f"{차선당*차선:>9.1f}", end=" ")
    print()

print()
print("이 서버의 NVMe SSD는 Gen4 x4 →", f"{세대['Gen4']*4:.1f} GB/s")
print("1GbE 네트워크 카드는          →", f"{1000/8/1000:.3f} GB/s")
print()
print("→ 디스크가 네트워크보다 60배 넓습니다.")
print("  그래서 이미지 서빙은 디스크가 아니라 회선이 먼저 막힙니다.")

NVMe는 01:00.0, 랜카드는 02:00.0과 03:00.0에 있습니다.

bash 브라우저에서 실행

# 이 서버에 무엇이 어느 슬롯에 꽂혀 있나
lspci

CPU가 기다리지 않는 세 가지 방법

👀

폴링

"다 됐어?" 계속 물어본다
CPU를 통째로 낭비

🔔

인터럽트

"다 되면 불러 줘"
그동안 다른 일을 한다

🚚

DMA

"메모리에 직접 넣어 둬"
CPU는 아예 손도 안 댄다

인터럽트 — 손 들고 부르기

디스크가 데이터를 다 준비하면 CPU에게 전기 신호로 손을 듭니다. CPU는 하던 일을 잠깐 저장해 두고, 정해진 처리 함수로 뛰어갔다가 돌아와요.

이 "잠깐 저장하고 뛰어갔다 오기"가 공짜가 아닙니다. 문맥 교환이 일어나거든요 — 레지스터를 전부 저장하고, 캐시가 밀려나고, TLB가 무효화됩니다.

in = 인터럽트, cs = 문맥 교환. 요청이 많아지면 함께 올라갑니다.

bash 브라우저에서 실행

# 초당 인터럽트와 문맥 교환 횟수 — in 과 cs 칸
vmstat 1 3

고등학생인터럽트 폭풍 — 초당 10만 패킷의 저주

note 의 이 이야기가 인터럽트의 어두운 면입니다.

알림이 너무 자주 오면 알림 처리만 하다 끝난다

무슨 일이 벌어지나

패킷 하나마다 인터럽트가 옵니다. 초당 10만 패킷이면 초당 10만 번 방해받아요.

인터럽트 한 번	비용
하던 일 저장	수십~수백 사이클
처리	수백 사이클
복원	수십~수백 사이클

10만 × 1000 사이클 = 1억 사이클 — CPU 의 3%

그리고 캐시가 깨집니다. 방해받을 때마다 캐시 내용이 밀려나요.

직접 비용보다 캐시 손실이 더 크다

비유 — 공부하다 카톡

1분에 한 번 카톡이 옵니다. 답하는 데 5초 밖에 안 걸리는데도 —

다시 집중하는 데 몇 분이 걸립니다. 방해의 진짜 비용은 복귀 시간이에요.

인터럽트도 똑같다 — 맥락 복원이 비싸다

어떻게 막나

기법	방법
인터럽트 병합	여러 패킷을 모아서 한 번만 알린다
NAPI	바쁠 땐 폴링으로 전환
RSS	여러 코어에 나눈다

바쁠 때는 폴링이 더 낫다 — 어차피 계속 있으니까

재미있는 반전이죠. 한가할 땐 인터럽트가 좋고 바쁠 땐 폴링이 좋습니다. 상황이 정답을 바꿉니다.

DMA — CPU를 아예 빼는 방법

인터럽트로 "다 됐다"는 걸 알아도, 데이터를 장치에서 메모리로 옮기는 일은 남습니다. 1MB를 CPU가 4바이트씩 옮기면 26만 번의 복사예요. 미친 짓이죠.

그래서 장치가 직접 메모리에 씁니다. 이게 DMA입니다. CPU는 "여기부터 여기까지 채워 놔"라고 시켜 놓고 다른 일을 하다가, 다 됐다는 인터럽트만 한 번 받으면 끝이에요.

DMA가 없으면 서버가 파일 하나 보내다 멈춥니다.

Python 브라우저에서 실행

# 1MB 를 옮기는 데 CPU 가 얼마나 관여하나
크기 = 1024 * 1024
클럭_GHz = 2.9

# ① 폴링 + CPU 복사 (PIO)
바이트당_클럭 = 4          # 읽고 쓰고 주소 계산
pio_클럭 = 크기 // 4 * 바이트당_클럭
print(f"① PIO(CPU가 직접 복사): {pio_클럭:>12,} 클럭  = {pio_클럭/클럭_GHz/1e6:.2f} ms  CPU 100% 점유")

# ② 인터럽트 + CPU 복사
print(f"② 인터럽트+PIO       : {pio_클럭:>12,} 클럭  (복사는 여전히 CPU가 한다)")

# ③ DMA
dma_클럭 = 2000            # 설정 + 인터럽트 처리 정도
print(f"③ DMA                : {dma_클럭:>12,} 클럭  = {dma_클럭/클럭_GHz/1e6:.4f} ms  CPU 거의 free")
print()
print(f"→ CPU 관여가 {pio_클럭/dma_클럭:,.0f}배 줄어듭니다.")
print("  그 시간에 CPU는 다른 손님의 요청을 처리할 수 있어요.")

고등학생sendfile — DMA 의 실전 응용

note 가 구체적인 최적화 하나를 듭니다. 쇼핑몰에서 상품 사진을 보낼 때 쓰는 기술이에요.

보통은 이렇게 갑니다

단계	복사
1. 디스크 → 커널 버퍼	DMA
2. 커널 → 앱 메모리	CPU ⚠
3. 앱 → 커널 소켓 버퍼	CPU ⚠
4. 커널 → 네트워크 카드	DMA

앱은 자료를 보지도 않는데 두 번 복사한다

sendfile 은 이렇게

단계	복사
1. 디스크 → 커널 버퍼	DMA
2. 커널 → 네트워크 카드	DMA ✔

CPU 복사가 0번 — 그래서 제로 카피

비유 — 택배 중계

방식	과정
보통	택배를 집에 들여 열어 보고 다시 포장해 보낸다
sendfile	주소만 바꿔 바로 넘긴다

내용이 안 바뀔 거면 들여다볼 이유가 없다

효과가 큽니다

지표	개선
CPU 사용	절반 이하
처리량	2~3배

nginx 가 정적 파일에 강한 이유가 이것이다

관리자에게 실전 결론

상품 사진 · CSS · JS 같은 정적 파일은 앱 서버가 아니라 nginx 가 내보내게 하세요.

파이썬이 파일을 읽어 보내면 제로 카피를 못 쓴다

그리고 암호화(HTTPS) 를 하면 내용을 봐야 하므로 제로 카피가 깨집니다. 그래서 요즘은 네트워크 카드가 암호화를 대신 하기도 해요.

네트워크 카드도 병목이 됩니다

회선이 병목일 때는 CPU를 늘려도 소용없습니다.

Python 브라우저에서 실행

회선_Mbps = 1000
평균_페이지_KB = 850        # HTML + CSS + JS + 이미지

초당_바이트 = 회선_Mbps * 1000 * 1000 / 8
동시_페이지 = 초당_바이트 / (평균_페이지_KB * 1024)

print(f"1Gbps 회선 = 초당 {초당_바이트/1024/1024:.0f} MiB")
print(f"페이지 하나 {평균_페이지_KB}KB → 초당 최대 {동시_페이지:.0f} 페이지")
print()
print("이미지를 CDN 으로 빼면?")
for kb in [850, 400, 120]:
    print(f"  페이지 {kb:>3}KB → 초당 {초당_바이트/(kb*1024):>5.0f} 페이지")
print()
print("→ 이미지를 CDN으로 옮기는 것만으로 처리량이 7배가 됩니다.")
print("  CPU도 디스크도 안 건드리고요.")

🤔 확인 문제

nginx가 이미지 파일을 보낼 때 CPU를 거의 쓰지 않는 이유는?

🤔 확인 문제

트래픽이 폭증하자 top의 %si(soft interrupt)가 40%까지 올라갔습니다. 무엇을 의심해야 하나요?