Quản Trị Process, Memory & Filesystem

Trong vận hành Production, 90% các sự cố nghiêm trọng (hệ thống chậm, máy chủ không phản hồi, container bị crash liên tục) đều bắt nguồn từ 3 thành phần: Tiến trình (Process), Bộ nhớ (Memory) hoặc Hệ thống tập tin (Filesystem).

Một kỹ sư tay ngang thường chỉ biết khởi động lại máy (reboot) hoặc tăng cấu hình RAM/CPU. Trong khi đó, một Chuyên gia SRE / Systems Engineer sẽ nhìn thấu bản chất của Kernel để xử lý tận gốc vấn đề trong vài phút.

🎯 Góc Nhìn Chuyên Gia (Mental Models)

• Process: Hiểu rõ các trạng thái "nguy hiểm" (D-state, Zombie), bản chất thật của Load Average và cách dùng tín hiệu Signals chuẩn xác.
• Memory: Giải mã vì sao free ít không có nghĩa là hết RAM, cơ chế Buffer/Cache, và cách sống sót trước OOM Killer.
• Filesystem: Bắt bệnh 2 lỗi kinh điển: Cháy Inode và File đã rm nhưng ổ cứng vẫn báo đầy 100%.

1. Quản Trị Tiến Trình (Process Management)

Mọi phần mềm chạy trên Linux đều là một tiến trình (Process), được định danh bằng một số nguyên duy nhất gọi là PID (Process ID).

1.1. Giải mã các trạng thái tiến trình (Process States)

Khi gõ lệnh ps aux hoặc top, cột STAT hiển thị trạng thái của tiến trình. Có 2 trạng thái mà bạn bắt buộc phải hiểu:

# Lọc nhanh các tiến trình đang ở trạng thái D (treo I/O) hoặc Z (Zombie)
ps aux | awk '$8 ~ /[DZ]/ {print $0}'

1.2. Load Average thực sự là gì?

❌ Hiểu lầm phổ biến: "Load Average 8.0 nghĩa là CPU đang quá tải 800%!"

Bản chất đúng: Load Average là số lượng tiến trình trung bình đang cạnh tranh tài nguyên trong 1, 5 và 15 phút. Nó bao gồm cả tiến trình đang cần CPU (trạng thái R) VÀ tiến trình đang đợi đĩa/phần cứng (trạng thái D).

• Quy tắc vàng: So sánh Load Average với số lượng CPU Cores (nproc):
  • Load Average < Số Cores: Hệ thống còn dư tài nguyên, mượt mà.
  • Load Average = Số Cores: Hệ thống vừa khít 100% công suất.
  • Load Average > Số Cores: Có tiến trình đang phải xếp hàng chờ đợi.
• Chẩn đoán nhanh:
  • Load cao + CPU % cao ➔ Thiếu CPU, ứng dụng tính toán nặng hoặc code lặp vô tận.
  • Load cao + CPU % thấp + %wa (iowait) cao ➔ Nghẽn cổ chai ở ổ cứng (Disk I/O bottleneck).

1.3. Nghệ thuật gửi tín hiệu (Signals)

Đừng lạm dụng kill -9 (SIGKILL) trong mọi tình huống. Hãy kết thúc tiến trình một cách chuyên nghiệp:

1. kill -15 <PID> (SIGTERM - Mặc định & Khuyến nghị): Lịch sự yêu cầu ứng dụng dừng lại. Ứng dụng sẽ kịp lưu file dở dang, đóng kết nối database rồi mới tắt an toàn (Graceful Shutdown).
2. kill -1 <PID> (SIGHUP): Yêu cầu ứng dụng nạp lại file cấu hình mà không làm gián đoạn dịch vụ (rất hay dùng cho Nginx, Prometheus).
3. kill -9 <PID> (SIGKILL - Phương án cuối cùng): Ép Kernel cưỡng chế tắt tiến trình ngay lập tức. Ứng dụng không kịp dọn dẹp, dễ gây hỏng dữ liệu (data corruption).

2. Quản Trị Bộ Nhớ (Memory Management)

2.1. Đọc lệnh free -h như một chuyên gia

               total        used        free      shared  buff/cache   available
Mem:            15Gi       3.2Gi       1.1Gi       120Mi        11Gi        11Gi
Swap:          2.0Gi          0B       2.0Gi

❌ Báo động giả: "Trời ơi, RAM 15GB mà free chỉ còn 1.1GB, máy chủ sắp sập rồi!"

Sự thật về Linux RAM:

• Linux có triết lý: "Unused RAM is wasted RAM" (RAM bỏ trống là RAM lãng phí).
• Nhân Linux sẽ tận dụng tối đa RAM nhàn rỗi để làm buff/cache (lưu đệm các file đọc từ đĩa). Nhờ đó, lần đọc tiếp theo sẽ lấy thẳng từ RAM với tốc độ nhanh gấp hàng trăm lần ổ đĩa.
• Khi ứng dụng cần thêm RAM, Kernel sẽ ngay lập tức giải phóng vùng buff/cache này để cấp cho ứng dụng mà không mất giọt mồ hôi nào.
• 🎯 Chỉ số duy nhất bạn cần quan tâm là available: Đây mới là lượng RAM thực tế có thể sử dụng ngay lập tức!

2.2. Sự thật về Swap & Tham số vm.swappiness

• Swap là gì? Là một phân vùng trên ổ cứng được dùng làm "van xả lũ" khi RAM vật lý bị căng thẳng.
• vm.swappiness (0 - 100): Không phải là "khi RAM còn X% thì bật Swap". Nó là tỷ lệ ưu tiên giữa việc thu hồi Page Cache (giải phóng file đệm) hay đẩy bộ nhớ ẩn danh của ứng dụng ra Swap.
  • Mặc định trên Ubuntu/Debian là 60 (quá nhạy cảm cho database/server).
  • Khuyến nghị cho Production Server: đặt về 10 hoặc 1.
  • Trên cụm Kubernetes Worker Nodes: Khuyến nghị tắt hoàn toàn Swap (swapoff -a) để Kubelet đo lường chính xác ngưỡng tài nguyên của Pod.

# Kiểm tra swappiness hiện tại
cat /proc/sys/vm/swappiness

# Đặt tạm thời về 10
sudo sysctl vm.swappiness=10

2.3. Sống sót trước OOM Killer (Out Of Memory)

Khi cả RAM và Swap đều cạn, Kernel bắt buộc phải kích hoạt OOM Killer để tiêu diệt một tiến trình cứu sống hệ điều hành.

• Tiến trình nào bị trảm trước? Kernel tính điểm tại /proc/<PID>/oom_score. Tiến trình nào ngốn nhiều RAM nhất sẽ có điểm cao nhất và bị chọn đầu tiên.
• Cách bảo vệ tiến trình sống còn (như SSH, Kubelet): Ta có thể can thiệp bằng cách giảm điểm phạt tại oom_score_adj (từ -1000 đến 1000). Giá trị -1000 nghĩa là không bao giờ bị OOM Kill.

# Bảo vệ tiến trình SSH không bao giờ bị OOM Killer tiêu diệt
echo -1000 | sudo tee /proc/$(pgrep -f sshd | head -1)/oom_score_adj

3. Quản Trị Hệ Thống Tệp (Filesystem)

3.1. Sự cố kinh điển 1: "Cháy Inode" (Đĩa còn trống nhưng báo đầy)

Bạn chạy lệnh ghi file và nhận thông báo lỗi: No space left on device. Nhưng khi gõ df -h, ổ đĩa vẫn còn trống tận 50GB!

Nguyên nhân: Hệ thống đã hết sạch Inode!

• Mỗi tập tin hoặc thư mục trên Linux bắt buộc phải chiếm một thẻ Inode để lưu metadata.
• Nếu ứng dụng (hoặc session PHP, email spam, micro-logs) tạo ra hàng triệu file rác siêu nhỏ (mỗi file vài byte), toàn bộ bảng Inode sẽ bị cạn kiệt trước khi ổ cứng kịp đầy dung lượng.

# Bước 1: Kiểm tra phần trăm Inode còn lại
df -i

# Bước 2: Tìm thư mục nào đang chứa nhiều file nhất để dọn dẹp
sudo find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n | tail -10

3.2. Sự cố kinh điển 2: File đã xóa (rm) nhưng ổ đĩa không nhả dung lượng

Bạn thấy file log phình to tới 80GB, bạn vội vàng chạy: sudo rm /var/log/app.log. Lạ lùng thay: file biến mất, nhưng gõ df -h dung lượng ổ cứng vẫn báo đầy 100%!

Bản chất:

• Lệnh rm thực chất chỉ là xóa con trỏ tên file (Unlink dentry).
• Nếu ứng dụng (như Java, Python, Nginx) vẫn đang mở file đó và chưa đóng File Descriptor, Kernel sẽ tiếp tục giữ vùng nhớ trên đĩa.

# Bước 1: Tìm các file đã xóa nhưng vẫn bị tiến trình giữ chặt (deleted)
sudo lsof | grep '(deleted)'

# Bước 2: Khắc phục mà không cần kill ứng dụng
# (Ghi đè file descriptor về rỗng để thu hồi dung lượng tức thì)
sudo truncate -s 0 /proc/<PID>/fd/<FD_NUMBER>

# Mẹo chuyên nghiệp: Lần sau muốn xóa trắng log lớn, đừng dùng 'rm', hãy dùng:
> /var/log/app.log

3.3. Tối ưu hiệu năng đĩa với cờ noatime

Mặc định, mỗi khi Linux đọc một file, nó sẽ ghi lại thời gian truy cập gần nhất (atime) xuống đĩa. Việc này biến một tác vụ ĐỌC thuần túy thành một tác vụ GHI đĩa ngầm!

Trên máy chủ Production chịu tải lớn (Web server, Cache server), thêm cờ noatime trong /etc/fstab sẽ loại bỏ thao tác ghi thừa thãi này, tăng tốc độ I/O lên từ 15% - 30%.

# Ví dụ cấu hình trong /etc/fstab:
UUID=xxxx-xxxx  /data  ext4  defaults,noatime  0  2

⚡ Bảng Tra Cứu Xử Lý Nhanh (Cheat Sheet)

Bài tiếp theo đề xuất: Đọc Hiểu Các Giá Trị Trong Htop – Phân tích trực quan 24 CPU cores, RAM meters, phân biệt VIRT/RES/SHR và cây tiến trình từ ảnh chụp thực tế.