사용중인 리눅스 서버 뜯어보기 (Ubuntu 22.04 LTS)

러닝앱 프로젝트에서

GCP로 마이그레이션되기 전 개발 서버로 사용된 우리 노트북을 한번 뜯어보자. (몇달째 방치된...)

ssh로 서버에 접속하여 아래 명령어를 통해 사양을 파악해보았다.

 

OS 정보

uname -a
lsb_release -a
cat /etc/os-release

 

디스크

df -h
lsblk

 

메모리/디스크

free -h
top

 

 

출력을 살펴보자.

 

---

 

OS

Ubuntu 22.04.2 LTS (Jammy) ->  (LTS: 장기 지원 우분투 서버)
Linux 5.15.0-164-generic  ->  (커널 버전 (장애·드라이버·보안 관련)
x86_64 (아키텍쳐)

 

디스크

/dev/mapper/ubuntu--vg-ubuntu--lv 98G 35G 58G 38% /   ->  사용률 38%
(루트 파티션은 LVM으로 구성)

 

여기서 루트 파티션(/)이란?

우선 파티션은 디스크를 논리적으로 나눈 영역이다.

 

의미

• 리눅스 파일시스템의 최상위
• 서버가 부팅되고 동작하는 기본 토대
• / 가 꽉 차면
  • 로그인 안 됨
  • 서비스 기동 실패
  • 로그 기록 불가→ 장애

그래서 운영자는 항상 / 사용률을 본다고 한다.

 

---

 

다음으로 메모리

Mem: 15Gi
total used: 2.2Gi
available: 12Gi

 

핵심은 available?

• Linux는 메모리를 캐시로 적극 사용
• used 보고 “메모리 부족” 판단하면 안되고, available 기준으로 판단

왜일까? Linux는 메모리를 놀리면 손해라고 본다.

 

Linux의 기본 철학은 "메모리를 비워두는 건 낭비" 다.

 

컴퓨터를 사용하다 보면 디스크에서 파일을 읽는 작업이 매우 자주 일어난다.

디스크는 메모리보다 훨씬 느리기 때문에, Linux는 한 번 읽은 데이터를 메모리에 보관해둔다.

나중에 같은 데이터가 필요하면 느린 디스크 대신 빠른 메모리에서 바로 가져다 쓸 수 있도록.

 

메모리 사용 전략

남는 메모리가 있으면 Linux는 이걸 캐시 용도로 채운다. 그래서 메모리 사용률이 80~90%로 높게 나오는 게 정상이다.

이건 문제가 아니라 오히려 시스템이 똑똑하게 작동하고 있다는 뜻!

프로그램이 메모리를 더 필요로 하면? Linux는 캐시로 쓰던 메모리를 즉시 비워서 준다.

캐시는 "있으면 좋고 없어도 괜찮은" 데이터니까.

 

그래서:

• 메모리가 꽉 차 보이는 게 정상
• 캐시 = 언제든 버릴 수 있는 메모리

메모리 상태 판단 기준

• used: 현재 사용 중인 메모리 (캐시 포함) → 높아도 정상
• free: 완전히 비어있는 메모리 → 보통 매우 적음
• available: 지금 당장 쓸 수 있는 메모리 → 이게 핵심!

available에는 완전히 비어있는 메모리뿐 아니라 필요하면 바로 회수할 수 있는 캐시도 포함된다.

그래서 이 값이 충분하면 시스템은 문제없이 돌아간다.

 

고 한다... 아니 몰랐네 이걸

---

 

 

프로세스 & 서비스

 

 

다음으로 프로세스 & 서비스 관련을 보자.

운영 서버에서 가장 먼저 확인해야 하는 것은 ‘어떤 프로세스가 리소스를 잡아먹고 있는가’ 이다.

아래 명령어를 통해 현황을 확인해본다.

ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head
systemctl list-units --type=service --state=running

 

CPU 기준 상위 프로세스 출력을 보면 아래와 같다.

/usr/bin/cadvisor
java -jar ngrinder-controller
docker-driver
loki
mongod
prometheus
redis
node_exporter

 

출력으로 알 수 있는 것 

• Docker 기반 서버
  • dockerd, containerd, cadvisor
• 모니터링 스택
  • prometheus, loki, grafana, node_exporter
• 데이터 계층
  • mongod, redis
• 메인 애플리케이션
  • java -jar ngrinder-controller

이 서버는:

모니터링 + 테스트 컨트롤러 + 컨테이너 호스트 임을 알 수 있다! (와!)

 

---

 

 

다음으로는 메모리 기준 상위 프로세스다. 출력을 보면 아래와 같다.

 

java (RSS ~600~700MB)
grafana
mongod
loki

• Java,DB, 모니터링 도구들이 메모리를 많이 사용하고 있음을 알 수 있다.

systemctl 결과 해석

docker.service           running
containerd.service    running
ssh.service                 running
rsyslog.service          running

 

Docker 기반 서버이며,
nGrinder Controller(Java)를 중심으로
Prometheus / Loki / Grafana 모니터링 스택과
MongoDB, Redis가 함께 동작 중

 

이렇게 정리할 수 있겠다...!

 

 

다음으로는 이 서버 어떤 네트워크 설정을 통해 온프레미스 서버로 활용할 수 있었는지에 대해 정리해보겠다.

(VPN, Docker, CI/CD)