1. Mục tiêu

Ở Lab 3, chúng ta đã biết cách tìm và quản lý process.

Trong thực tế, một trong những tình huống DevOps thường gặp là:

Server chậm
   ↓
CPU 100%?
RAM đầy?
Disk đầy?
Process nào gây ra?

Lab này tập trung vào CPU, Memory và Disk — những tài nguyên cơ bản nhất của một Linux server.

Sau lab này, bạn có thể:

• Kiểm tra CPU và Load Average.
• Kiểm tra RAM và Swap.
• Tìm process sử dụng nhiều CPU/RAM.
• Kiểm tra disk usage.
• Tìm directory/file chiếm nhiều dung lượng.
• Hiểu inode.
• Xử lý tình huống disk đầy.
• Biết cách debug server chậm.

---

2. Nhìn tổng quan tài nguyên Linux

Có thể hình dung một server như một chiếc máy:

                Linux Server
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
       CPU          RAM          Disk
        │            │            │
    Compute       Running        Data
    Process       Process        Logs

Ví dụ:

CPU 100% → Process đang tính toán quá nhiều

RAM 95% → Application đang sử dụng nhiều memory

Disk 100% → Không thể ghi thêm dữ liệu

Ba vấn đề này có thể khiến application hoạt động bất thường.

---

3. Kiểm tra CPU

Command cơ bản:

top

Bạn sẽ thấy:

%Cpu(s): 20.0 us, 5.0 sy, 75.0 id

Một số giá trị quan trọng:

us → User processes
sy → System processes
id → Idle

Nếu:

id = 90%

thì CPU đang khá rảnh.

Nếu:

id = 0%

thì CPU gần như đang bận hoàn toàn.

---

4. Load Average

Trong top bạn sẽ thấy:

load average: 0.50, 0.70, 0.80

Ba giá trị tương ứng:

1 phút
5 phút
15 phút

Load Average thể hiện mức độ công việc mà hệ thống đang phải xử lý/chờ xử lý.

Ví dụ máy có:

4 CPU

thì load:

2.0

thường chưa đáng lo.

Nhưng:

8.0

cho thấy hệ thống đang chịu tải đáng kể.

Lưu ý: Load Average không đơn giản đồng nghĩa với CPU %. Process có thể chờ I/O cũng làm load tăng. Khi debug, hãy xem cả CPU, memory và I/O thay vì chỉ nhìn một con số.

---

5. Tìm Process dùng nhiều CPU

Dùng:

top

Trong top, process sử dụng CPU cao sẽ nằm ở phía trên.

Hoặc:

ps aux --sort=-%cpu | head

Kết quả có thể giống:

USER     PID   %CPU   COMMAND
devops  1234  98.5   java -jar app.jar
devops  5678  20.1   node server.js

Bây giờ bạn biết:

PID 1234
   ↓
CPU 98.5%

Có thể kiểm tra chi tiết:

ps -fp 1234

---

6. Thực hành — Tạo CPU cao

Chạy:

yes > /dev/null

Mở terminal khác:

top

Bạn sẽ thấy CPU tăng cao.

Tìm process:

ps aux --sort=-%cpu | head

Dừng:

kill <PID>

Kiểm tra lại:

top

CPU sẽ giảm.

Tư duy troubleshooting

CPU cao
   ↓
  top
   ↓
Tìm process
   ↓
  PID
   ↓
ps -fp PID
   ↓
Xác định application

---

7. Kiểm tra Memory

Command:

free -h

Ví dụ:

              total   used   free
Mem:           7.7G    5.1G   800M
Swap:          2.0G    100M   1.9G

Các khái niệm:

total → Tổng RAM
used  → RAM đang sử dụng
free  → RAM chưa sử dụng
swap  → Bộ nhớ swap

Một lưu ý quan trọng

Linux thường dùng RAM trống để làm:

filesystem cache

Vì vậy:

RAM free thấp không nhất thiết có nghĩa server đang gặp vấn đề.

Hãy nhìn tổng thể available, swap và tình trạng application.

---

8. Tìm Process dùng nhiều RAM

ps aux --sort=-%mem | head

Ví dụ:

USER     PID   %MEM   COMMAND
devops  1234  35.2   java -jar app.jar

Kiểm tra:

ps -fp 1234

Nếu application liên tục tăng memory theo thời gian, có thể cần điều tra:

Memory leak
Large cache
Too many objects

Không nên kết luận chỉ từ một lần kiểm tra.

---

9. Swap

Swap là vùng disk được Linux sử dụng như bộ nhớ bổ sung khi RAM chịu áp lực.

Kiểm tra:

free -h

Ví dụ:

Swap: 2.0G  1.5G  500M

Nếu server thường xuyên sử dụng nhiều swap:

RAM pressure
      ↓
     Swap
      ↓
Disk I/O
      ↓
Application chậm

Kinh nghiệm thực tế: Swap không phải cách "tăng RAM miễn phí". Nó chậm hơn RAM rất nhiều.

---

10. Kiểm tra Disk

Đây là command cực kỳ quan trọng:

df -h

Ví dụ:

Filesystem   Size   Used   Avail   Use%
/dev/sda1     50G    48G      2G    96%

Điều đáng chú ý nhất:

Use%

Nếu:

95%+

thì nên bắt đầu điều tra.

Nếu:

100%

application có thể không ghi được file/log/database.

---

11. Tìm Directory chiếm nhiều Disk

Dùng:

du -sh /*

Tuy nhiên một số directory có thể không cho phép truy cập.

Thường hữu ích hơn:

sudo du -sh /var/*

Ví dụ:

2G   /var/cache
15G  /var/log
20G  /var/lib

Bây giờ biết:

/var/log

đang chiếm nhiều dung lượng.

Tiếp tục:

sudo du -sh /var/log/*

---

12. Tìm File Lớn

Ví dụ tìm file lớn hơn 1GB:

sudo find /var -type f -size +1G -ls

Hoặc tìm trong toàn bộ filesystem:

sudo find / -type f -size +1G -ls 2>/dev/null

Tip: Khi disk đầy, đừng vội xóa file. Trước tiên hãy xác định file nào, application nào tạo ra, và tại sao nó tăng liên tục.

---

13. Disk đầy vì Log

Đây là một scenario rất thực tế.

Ví dụ:

Application
    ↓
   Log
    ↓
/var/log/app.log
    ↓
  50 GB
    ↓
Disk 100%

Kiểm tra:

sudo du -sh /var/log/*

Xem file lớn:

sudo ls -lhS /var/log/

Có thể thấy:

app.log       20G
error.log     10G
system.log     5G

Đây là lúc cần điều tra:

Tại sao log tăng?
Có log rotation?
Application có log loop?
Có error xảy ra liên tục?

---

14. Log Rotation

Không nên để:

app.log
  ↓
1 GB
  ↓
10 GB
  ↓
50 GB
  ↓
Disk full

Linux thường sử dụng logrotate để quản lý log.

Kiểm tra:

ls /etc/logrotate.d/

Có thể có:

/etc/logrotate.d/nginx
/etc/logrotate.d/rsyslog

Ý tưởng:

app.log
   ↓
rotation
   ↓
app.log.1
app.log.2
app.log.3

Sau đó các log cũ có thể được nén hoặc xóa theo policy.

Kinh nghiệm thực tế: Với production server, log management phải được thiết kế từ đầu. Đừng chờ disk đầy mới xử lý.

---

15. Inode

Có một trường hợp khá thú vị:

df -h

vẫn còn nhiều GB nhưng application không tạo được file.

Nguyên nhân có thể là inode đã hết.

Kiểm tra:

df -i

Ví dụ:

Filesystem   Inodes   IUsed   IFree   IUse%
/dev/sda1    3.0M     3.0M       0    100%

Điều này có nghĩa:

Disk space còn
nhưng
số lượng file tối đa đã hết

Nguyên nhân thường gặp:

Rất nhiều file nhỏ
Temporary files
Cache
Application tạo file liên tục

Trick: Khi gặp lỗi "No space left on device", đừng chỉ chạy df -h. Hãy kiểm tra cả df -i.

---

16. Một tình huống đặc biệt: Xóa file nhưng Disk vẫn đầy

Ví dụ:

rm huge.log

Nhưng:

df -h

vẫn báo disk gần đầy.

Có thể application vẫn đang giữ file descriptor mở.

Kiểm tra:

sudo lsof +L1

Bạn có thể thấy:

java   1234   app.log (deleted)

Nghĩa là:

File đã bị xóa khỏi filesystem
        ↓
Process vẫn đang mở file
        ↓
Disk space chưa được giải phóng

Cách xử lý thường là restart process liên quan sau khi đánh giá ảnh hưởng.

Đây là một trick troubleshooting rất đáng nhớ khi xử lý disk đầy trên Linux.

---

17. Bài thực hành tổng hợp

Hãy tạo một directory:

mkdir -p ~/resource-lab
cd ~/resource-lab

Tạo một file lớn:

fallocate -l 500M bigfile.dat

Kiểm tra:

ls -lh

Kiểm tra disk:

df -h .

Kiểm tra directory:

du -sh .

Xóa file:

rm bigfile.dat

Kiểm tra lại.

---

18. Challenge — Server chậm

Hãy tưởng tượng bạn nhận được ticket:

"Production server rất chậm."

Không được restart server.

Hãy tự kiểm tra theo thứ tự:

Bước 1 — CPU

top

Bước 2 — Process CPU

ps aux --sort=-%cpu | head

Bước 3 — Memory

free -h

Bước 4 — Process Memory

ps aux --sort=-%mem | head

Bước 5 — Disk

df -h

Bước 6 — Directory lớn

sudo du -sh /var/*

Bước 7 — Inode

df -i

Sau đó hãy kết luận:

CPU problem?
Memory problem?
Disk problem?
Inode problem?
Hay application problem?

Đây chính là cách tiếp cận nên hình thành.

---

19. Troubleshooting Flow

Khi server có vấn đề:

          Server chậm
              │
       ┌──────┼──────┐
       ▼      ▼      ▼
      CPU    RAM    Disk
       │      │      │
      top   free     df
       │      │      │
      ps     ps     du
                     │
                  df -i
                     │
                 lsof +L1

Không nên ngay lập tức:

reboot

vì reboot có thể làm mất thông tin quan trọng để điều tra.

---

20. Một số command cần nhớ

Command	Mục đích
top	Monitor CPU/RAM/process
ps aux	Xem process
free -h	Kiểm tra RAM
df -h	Kiểm tra disk
df -i	Kiểm tra inode
du -sh	Kiểm tra dung lượng directory
find	Tìm file
lsof	Xem process đang mở file
uptime	Xem uptime + load average
vmstat	Theo dõi CPU/memory/system

---

21. Kinh nghiệm thực tế

1. Đừng chỉ nhìn CPU

Server chậm có thể do:

CPU
RAM
Disk I/O
Network
Database

CPU 20% không có nghĩa server chắc chắn khỏe.

---

2. free thấp chưa chắc là lỗi

Linux sử dụng RAM trống để cache.

Hãy quan tâm:

available
swap
application memory

hơn là chỉ nhìn free.

---

3. Disk 80% chưa chắc nguy hiểm, 100% thì rất nguy hiểm

Production nên có monitoring và alert trước khi:

Disk → 100%

Ví dụ:

Disk > 80%
     ↓
Warning

Disk > 90%
     ↓
Critical

Đây chính là tư duy Monitoring mà bạn sẽ áp dụng với Prometheus sau này.

---

4. Đừng xóa log một cách mù quáng

Thay vì:

rm -rf /var/log/*

hãy xác định:

File nào lớn?
Ai tạo?
Tại sao tăng?
Có logrotate chưa?
Có cần giữ log không?

---

5. Giữ nguyên hiện trường khi troubleshooting

Khi production gặp sự cố:

Không vội reboot
Không vội kill -9
Không vội rm
Không vội chmod 777

Trước tiên:

Observe
 ↓
Collect information
 ↓
Identify cause
 ↓
Fix
 ↓
Verify

---

22. Liên hệ với Kubernetes

Những kiến thức này sẽ xuất hiện lại trực tiếp trong Kubernetes.

Linux:

CPU
RAM
Disk
Process

Kubernetes:

Pod CPU
Pod Memory
Node CPU
Node Memory
Ephemeral Storage
Container Restart

Ví dụ Linux:

top

Kubernetes:

kubectl top pods
kubectl top nodes

Linux:

df -h

Kubernetes:

Node Disk
Container filesystem
Ephemeral Storage
Persistent Volume

Vì vậy, khi bạn học Kubernetes:

CPU, Memory, Disk không phải là những khái niệm mới — Kubernetes chỉ đưa chúng vào môi trường container và cluster.

---

23. Checklist

Sau Lab 4, bạn nên tự trả lời được:

✓ CPU utilization là gì?
✓ Load Average là gì?
✓ Làm sao tìm process dùng nhiều CPU?
✓ Làm sao kiểm tra RAM?
✓ Swap là gì?
✓ Làm sao tìm process dùng nhiều RAM?
✓ df và du khác nhau thế nào?
✓ Làm sao tìm directory lớn?
✓ Inode là gì?
✓ Làm sao kiểm tra inode?
✓ Vì sao xóa file nhưng disk vẫn đầy?
✓ lsof +L1 dùng để làm gì?
✓ Log rotation là gì?
✓ Khi server chậm nên kiểm tra gì trước?

Bài tập cuối Lab

Không sử dụng reboot, hãy tự tạo một scenario khiến:

CPU tăng cao

và một scenario khiến:

Disk tăng đáng kể

Sau đó thực hiện đầy đủ:

Detect
  ↓
Identify
  ↓
Investigate
  ↓
Fix
  ↓
Verify

Nếu bạn làm được quy trình này, bạn đã bắt đầu hình thành tư duy troubleshooting của một DevOps Engineer, thay vì chỉ biết các Linux command riêng lẻ.

Lab tiếp theo: Lab 5 — SSH & Remote Server Administration, nơi chúng ta sẽ chuyển từ việc quản lý Linux trên máy local sang đăng nhập và quản trị server từ xa, đồng thời chuẩn bị nền tảng trực tiếp cho Ansible.