2. 이 서버는 무엇인가 — OS와 하드웨어

인수인계 없이 서버를 받았을 때 10분 안에 정체를 파악하는 명령들

이 장에서 처음 나오는 말5개

커널Kernel

하드웨어와 프로그램 사이를 중개하는 운영체제의 핵심. "Ubuntu 24.04"는 배포판 버전이고 uname -r이 보여주는 6.8.0-xx가 커널 버전이다 — 둘은 따로 움직인다.

HWEHardware Enablement

LTS에 최신 커널·그래픽 드라이버를 얹어 주는 Ubuntu의 정책. 새 하드웨어를 지원하려고 포인트 릴리스(24.04.2 등)마다 커널을 올린다 — 같은 24.04인데 uname -r이 서로 다른 이유다.

DMI / SMBIOSDesktop Management Interface

메인보드 펌웨어가 담고 있는 하드웨어 정보표(제조사·모델·시리얼·메모리 슬롯). dmidecode가 이걸 읽는다 — root 권한이 필요하다.

NUMANon-Uniform Memory Access

CPU 소켓마다 가까운 메모리가 따로 있는 구조. 먼 쪽 메모리 접근이 느려서, 큰 서버에서는 성능 차이가 실제로 난다. lscpu의 NUMA 항목에 나온다.

SMARTSelf-Monitoring, Analysis and Reporting Technology

디스크가 스스로 기록하는 건강 상태(불량 섹터·수명·온도). smartctl로 읽는다 — 디스크가 죽기 전에 알 수 있는 거의 유일한 수단이다.

OS — 무슨 배포판, 무슨 커널

cat /etc/os-release        # 가장 확실. 모든 배포판에 있는 표준 파일
lsb_release -a             # 사람이 읽기 좋은 요약 (lsb-release 패키지)
hostnamectl                # OS + 커널 + 아키텍처 + 가상화 + 머신 ID를 한 화면에
uname -a                   # 커널 이름·버전·아키텍처
uname -r                   # 커널 버전만 (6.8.0-51-generic)

hostnamectl 한 방이면 대부분 끝난다 — 실무에서 가장 손이 많이 가는 명령이다.

 Static hostname: web-01
       Icon name: computer-vm
         Chassis: vm                      ← 가상 머신이다
      Machine ID: 3f2b…
Operating System: Ubuntu 24.04.3 LTS
          Kernel: Linux 6.8.0-51-generic
    Architecture: x86-64
 Virtualization: kvm                      ← 하이퍼바이저 종류

얼마나 오래 떠 있나 · 언제 재부팅했나

uptime -p                  # up 3 weeks, 2 days
uptime -s                  # 마지막 부팅 시각
who -b                     # 같은 정보 (부팅 시각)
last reboot | head         # 재부팅 이력 (11장)
cat /proc/cmdline          # 커널이 어떤 부팅 옵션으로 떴는지

함정

uptime이 짧으면 누군가 재부팅했거나 크래시가 났다는 뜻이다. 장애 조사에서 제일 먼저 봐야 할 값인데 자주 잊는다 — 원인은 journalctl -b -1 -e(직전 부팅의 마지막 로그)에서 찾는다(6장).

CPU

lscpu                      # 모델·코어·소켓·클럭·캐시·NUMA·취약점 완화 상태까지
nproc                      # 쓸 수 있는 논리 코어 수만 (스크립트용)
lscpu -e                   # 코어별 배치 표
cat /proc/cpuinfo | grep "model name" | uniq

lscpu에서 실제로 보는 값 넷 —

항목	의미
CPU(s)	논리 코어 수 = 소켓 × 코어 × 스레드. nproc과 같은 값
Thread(s) per core	2면 하이퍼스레딩. 물리 코어는 CPU(s)의 절반이다
Model name	실제 CPU 모델. 세대·클럭을 판단하는 근거
Flags / Vulnerability …	가상화 지원(vmx/svm), 투기 실행 취약점 완화 적용 여부

메모리

free -h                    # 총량 · 사용 · available · swap
free -h --si               # GB(1000) 단위로. 기본은 GiB(1024)
lsmem                      # 메모리 블록과 온라인 상태
sudo dmidecode -t memory   # 물리 슬롯별 용량·속도·제조사 (물리 서버에서만 의미)
cat /proc/meminfo          # 원본

free -h에서 available 하나만 본다.

               total        used        free      shared  buff/cache   available
Mem:            15Gi       4.2Gi       308Mi        68Mi        11Gi        11Gi

함정

free가 300Mi밖에 없다고 놀라는 것이 리눅스 입문의 통과의례다. 리눅스는 남는 메모리를 전부 디스크 캐시(buff/cache)로 쓴다 — 그리고 필요하면 즉시 내준다. 실제로 새 프로그램이 쓸 수 있는 양은 available 이다. free가 낮은 것은 정상이고, available이 낮은 것이 문제다.

디스크와 블록 장치

lsblk                                        # 트리로 한눈에
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL  # 필요한 열만
df -hT                                       # 마운트된 파일시스템의 사용량 + 타입
sudo nvme list                               # NVMe SSD 모델·용량·펌웨어
sudo smartctl -a /dev/sda | head -40         # 건강 상태 (smartmontools 패키지)
sudo smartctl -H /dev/nvme0                  # PASSED / FAILED 한 줄만

용량·마운트·정리는 3장에서 따로 다룬다. 여기서는 스펙 확인까지다.

네트워크 인터페이스와 주변 장치

ip -br link                # 인터페이스 목록 · 상태 · MAC (가장 빠른 확인)
sudo ethtool enp1s0        # 링크 속도(1000Mb/s) · 듀플렉스 · 케이블 연결 여부
sudo lshw -class network -short
lspci                      # PCI 장치 전체 (NIC · RAID 카드 · GPU)
lspci -nnk | grep -A3 Ethernet   # NIC과 그 드라이버
lsusb                      # USB 장치

ethtool의 Speed: 와 Link detected: yes 는 케이블/포트 문제를 1초에 가른다 — 네트워크 진단의 0층이다(8장).

물리인가 가상인가

systemd-detect-virt        # kvm · vmware · none(물리) · lxc · docker
sudo dmidecode -s system-manufacturer   # VMware, Inc. / Dell Inc. / QEMU …
sudo dmidecode -s system-product-name
sudo dmidecode -t system   # 시리얼 · 서비스 태그 (하드웨어 A/S에 필요)
cloud-id                   # 클라우드면 aws · azure · gce (cloud-init 설치 시)

물리 서버라면

dmidecode -t system의 시리얼(서비스 태그) 을 기록해 둔다 — 벤더 지원 요청에 필수다. smartctl로 디스크 수명, sudo dmidecode -t memory로 슬롯 여유(증설 가능 여부), ipmitool sensor 또는 iDRAC/iLO 웹으로 온도·팬·전원을 본다.

가상 머신이라면

물리 정보는 대부분 하이퍼바이저가 지어낸 값이라 의미가 없다. 대신 리소스가 언제든 바뀔 수 있다는 점이 중요하다 — 스펙을 문서에 적어두기보다 lscpu/free를 그때그때 다시 확인한다. dmesg | grep -i "virtio\|vmware"로 반가상화 드라이버가 제대로 올라왔는지는 볼 만하다.

한 번에 보기

sudo lshw -short           # 하드웨어 전체를 계층 표로 (lshw 패키지)
sudo hwinfo --short        # 비슷한 대안 (hwinfo 패키지)
fastfetch                  # OS + 스펙 요약을 예쁘게 (24.04부터 neofetch 대체)
sudo inxi -Fxz             # 한 화면 종합 리포트 (inxi 패키지)

인수인계용 스냅숏 한 장을 남길 때 유용하다 — { hostnamectl; lscpu; free -h; lsblk; ip -br a; } > /tmp/spec-$(hostname).txt

함정

컨테이너 안에서 친 lscpu·free는 호스트의 값을 보여준다. cgroup으로 CPU 0.5개·메모리 512Mi로 제한돼 있어도 그대로 안 나온다 — 컨테이너의 실제 한도는 /sys/fs/cgroup/memory.max, /sys/fs/cgroup/cpu.max에서 읽는다 (cgroup v2 기준, Ubuntu 24.04 기본).

핵심

hostnamectl → lscpu → free -h → lsblk → ip -br a → systemd-detect-virt. 이 여섯 개가 처음 보는 서버의 신원 조회다. 순서대로 치면 10분이 아니라 30초면 끝난다.

2장 요약

• OS·커널·가상화 여부는 hostnamectl 한 방 — /etc/os-release가 그 원본
• uptime이 짧으면 재부팅/크래시를 의심하고 journalctl -b -1을 본다
• free는 available만 본다 — free가 낮은 것은 캐시 때문이고 정상이다
• 물리 정보(모델·시리얼·메모리 슬롯)는 dmidecode, 디스크 건강은 smartctl — 둘 다 root
• 컨테이너 안의 lscpu·free는 호스트 값이다 — 한도는 cgroup 파일에서 읽는다

3. 디스크와 파일시스템용량이 어디로 갔는지 찾는 법, inode 만석, 지웠는데 안 줄어드는 파일, LVM 확장.