14강 / 20강

내 서버 스펙 읽기 — 명세서를 손에 쥐다

lscpu · free · lsblk · dmidecode 로 부품표 만들기

1부와 2부에서 컴퓨터 구조를 배웠습니다. 이제 그 지식을 실제 서버 한 대에 씁니다.

관리자가 새 서버를 받으면 가장 먼저 할 일은 부품표를 만드는 것입니다. 왜냐하면 장애가 났을 때 "이 서버 CPU가 몇 개였지?"를 그때 찾으면 이미 늦거든요.

고등학생명세서를 손에 쥐다

여기서부터 실전입니다. 1~13강이 원리였다면 14~20강은 손으로 하는 일이에요.

서버를 받으면 부품표부터 만든다

왜 부품표가 먼저인가

모르면	생기는 일
코어 수를 모른다	워커 수를 못 정한다
메모리를 모른다	OOM 이 난다
디스크 종류를 모른다	느린 이유를 못 찾는다

진단은 정상값을 알아야 가능하다

비유 — 건강검진

의사가 키와 몸무게 부터 잽니다. 그래야 "이 수치가 높다" 를 판단할 수 있으니까요.

서버도 같습니다. load average 8 이 높은 건가요?

코어 수	load 8 은
4코어	과부하 ⚠
8코어	딱 찼다
32코어	한가하다

같은 숫자가 서버마다 다른 뜻이다

명령 네 개면 됩니다

명령	보는 것
`lscpu`	CPU · 코어 · 캐시
`free -h`	메모리
`lsblk`	디스크
`ip -s link`	네트워크

다섯 줄이면 충분합니다

서버 스펙의 90%는 이 다섯 명령으로 나옵니다.

명령	알려 주는 것
`lscpu`	CPU 모델·코어·스레드·캐시·NUMA
`free -h`	메모리와 스왑
`lsblk`	디스크 구성과 마운트
`lspci`	랜카드·NVMe 등 꽂혀 있는 카드
`sudo dmidecode`	메인보드·BIOS·DIMM 슬롯 (메모리 증설 계획용)

고등학생lscpu 를 제대로 읽기

lscpu 출력에서 혼동하기 쉬운 줄들을 봅시다.

CPU(s) 는 논리 코어 수 — 물리 코어가 아니다

세 줄을 곱해야 합니다

줄	뜻
Socket(s)	CPU 칩 개수
Core(s) per socket	칩당 물리 코어
Thread(s) per core	2 면 하이퍼스레딩 ON

CPU(s) = 소켓 × 코어 × 스레드

예를 들어

줄	값
Socket(s)	1
Core(s) per socket	8
Thread(s) per core	2
CPU(s)	16

"16코어" 가 아니라 8코어 16스레드 — 성능은 8×1.25 쯤

캐시 줄도 중요합니다

줄	보통	의미
L1d	32~48KB	코어당 자료 캐시
L2	1~2MB	코어당
L3	16~64MB	전체 공유

L3 크기가 DB 성능에 크게 영향을 준다

그리고 놓치기 쉬운 줄

줄	왜 보나
Hypervisor vendor	가상 머신인지 — 스펙이 안 맞을 수 있다
NUMA node(s)	2 이상이면 메모리 배치를 신경 써야
Vulnerability	스펙터 패치 상태 (10강)

클라우드에서 vCPU 2개 = 물리 코어 1개인 경우가 많다

CPU 명세를 통째로 봅니다.

bash 브라우저에서 실행

# ① CPU
lscpu

여기서 관리자가 실제로 쓰는 줄은 이렇습니다.

Model name — 세대와 등급. 클라우드 견적 비교의 기준
CPU(s) — 논리 CPU. 워커 수 계산의 출발점
Thread(s) per core / Core(s) per socket — 진짜 코어가 몇 개인지
L3 — 여럿이 나눠 쓰는 캐시. 워커를 몇 개까지 늘려도 되나의 힌트
NUMA node(s) — 2 이상이면 메모리 배치를 신경 써야 함

DIMM 슬롯 4개 중 2개가 비어 있으면 증설이 가능합니다.

bash 브라우저에서 실행

# ② 메모리 — 총량, 지금 쓰는 양, 스왑
free -h
echo "=== 슬롯이 몇 개 비어 있나 (증설 가능한가) ==="
sudo dmidecode -t memory | grep -E 'Size|Locator|Speed|Type:'

고등학생메모리 증설 전에 확인할 것

note 의 이 체크리스트가 돈을 아껴 줍니다.

메모리는 아무거나 꽂히지 않는다

확인할 다섯 가지

항목	확인 명령
빈 슬롯이 있나	`dmidecode -t memory`
최대 용량은	메인보드 사양
종류 (DDR4/5)	dmidecode
속도	섞으면 느린 쪽에 맞춰진다
ECC 인가	서버는 ECC (19강)

한 가지만 안 맞아도 안 켜진다

그리고 정말 메모리가 문제인지

가장 중요한 확인입니다.

증상	진짜 원인일 수도
free 가 적다	정상 — 캐시가 쓰고 있다 (16강)
느리다	디스크 · DB · 네트워크
OOM 발생	메모리 누수 — 늘려도 또 난다

누수는 증설로 안 고쳐진다 — 시간만 번다

비유 — 새는 양동이

양동이에 구멍이 났습니다. 더 큰 양동이를 사면 해결되나요?

물이 차는 시간이 길어질 뿐입니다. 구멍은 그대로예요.

메모리가 계속 늘어나면 누수 — 증설이 아니라 수리

어떻게 구별하나

패턴	진단
재시작 후 일정하게 유지	정상 — 부족하면 증설
시간이 갈수록 계속 증가	누수 — 코드를 고친다

며칠간 그래프를 봐야 안다 — 한 순간의 숫자로는 모른다

80%를 넘긴 파티션이 있으면 지금 조치해야 합니다.

bash 브라우저에서 실행

# ③ 디스크 — 무엇이 어디에 붙어 있나
lsblk
echo "=== SSD 인가 HDD 인가 ==="
lsblk -d
echo "=== 얼마나 찼나 ==="
df -h

NUMA 노드가 1개면 메모리 배치를 신경 쓸 필요가 없습니다.

bash 브라우저에서 실행

# ④ 꽂혀 있는 카드들
lspci
echo "=== NUMA 구성 ==="
numactl --hardware

부품표를 파일로 남깁시다

실무에서는 이걸 스크립트 하나로 만들어 두고, 서버를 받을 때마다 돌립니다.

만든 파일은 나중에 nano 로 열어 메모를 덧붙일 수 있습니다.

bash 브라우저에서 실행

# 부품표를 한 파일로 모은다 (>> 로 이어 붙인다)
echo "# 서버 명세서  $(hostname)"                              >  /home/jit/spec.md
echo ""                                                        >> /home/jit/spec.md
echo "## CPU"                                                  >> /home/jit/spec.md
lscpu | grep -E 'Model name|^CPU\(s\)|Thread|Core\(s\)|Socket|L1d|L2|L3|NUMA node\(s\)' >> /home/jit/spec.md
echo ""                                                        >> /home/jit/spec.md
echo "## 메모리"                                               >> /home/jit/spec.md
free -h | head -2                                              >> /home/jit/spec.md
echo ""                                                        >> /home/jit/spec.md
echo "## 디스크"                                               >> /home/jit/spec.md
lsblk -d                                                       >> /home/jit/spec.md
echo ""                                                        >> /home/jit/spec.md
echo "## 커널"                                                 >> /home/jit/spec.md
uname -r                                                       >> /home/jit/spec.md

cat /home/jit/spec.md

스펙에서 바로 읽어 내야 할 세 가지 숫자

부품표를 만들었으면 이제 해석입니다. 관리자는 이 세 숫자를 머릿속에 넣어 둡니다.

스펙 숫자를 운영 결정으로 바꾸는 계산.

Python 브라우저에서 실행

# 이 서버의 스펙 (14강에서 확인한 값)
논리CPU   = 12
물리코어  = 6
메모리GiB = 16
L3_MiB    = 12

print("① 워커 수 출발점")
print(f"   gunicorn 권장 공식: (2 × 코어) + 1 = {2*물리코어+1}개")
print(f"   또는 논리 CPU 수    = {논리CPU}개")
print(f"   → 이 사이에서 시작해 실측으로 조정합니다 (17강)")
print()

print("② 워커 하나가 쓸 수 있는 메모리")
OS몫 = 1.0
여유 = 0.15
for 워커 in [4, 8, 13]:
    가능 = (메모리GiB * (1 - 여유) - OS몫) / 워커 * 1024
    print(f"   워커 {워커:>2}개 → 하나당 최대 {가능:>6.0f} MiB")
print()

print("③ 캐시 압박")
for 워커 in [4, 8, 13]:
    print(f"   워커 {워커:>2}개 → L3 를 {L3_MiB/워커:.1f} MiB 씩 나눠 쓴다")
print("   → 워커가 많아질수록 서로 캐시를 밀어냅니다 (8강)")

고등학생관리자가 서버를 받으면 하는 일, 요약

note 의 체크리스트를 순서와 이유로 정리합니다.

순서	할 일	왜
1	부품표 기록	나중 진단의 기준선
2	평상시 지표 기록	"높다" 를 판단하려면
3	부하 시험	한계를 미리 안다
4	모니터링 설치	사고 때 과거를 본다

2번 평상시 기록을 대부분 건너뛴다 — 그리고 후회한다

왜 평상시가 중요한가

사고가 났을 때 load 12 를 봤습니다. 높은 건가요?

평상시가	판단
0.5 였다면	24배 — 심각하다
10 이었다면	조금 오른 것 — 다른 데를 봐야

비교할 대상이 없으면 숫자는 의미가 없다

비유 — 체온

37.5도가 열인가요? 사람마다 평소 체온이 다릅니다.

평소 36.0도인 사람에겐 열이고 36.9도인 사람에겐 미미합니다.

평소를 알아야 이상을 안다

부하 시험을 미리 하는 이유

한계를 모르고 블랙프라이데이를 맞으면 실전에서 처음 한계를 만납니다.

한계는 안전할 때 확인해 두는 것

20강에서 그 시험을 직접 설계해 봅니다.

🤔 확인 문제

lscpu 결과에 CPU(s): 12, Thread(s) per core: 2, Core(s) per socket: 6, Socket(s): 1 이라고 나왔습니다. 진짜 물리 코어는 몇 개인가요?

🤔 확인 문제

메모리를 증설하려고 dmidecode -t memory 를 봤더니 8GB 모듈 2개가 꽂혀 있고 슬롯 2개가 비어 있습니다. 가장 좋은 선택은?