Chốt ý nhanh

uptime
free -h
top
ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head

nproc
uptime

ps aux --sort=-%cpu | head -10
ps aux --sort=-%mem | head -10
pidof nginx
systemctl status nginx

kill PID
kill -15 PID
kill -9 PID

Kết bài

Sau bài này, anh nên có phản xạ tốt hơn khi gặp một máy chậm: nhìn load, CPU, RAM, process và xu hướng thay đổi thay vì chỉ chăm chăm restart. Đây là bước rất quan trọng để đi từ “người biết lệnh” sang “người biết đọc trạng thái hệ thống”. Bài tiếp theo sẽ mở rộng sang dung lượng lưu trữ, filesystem và các ca disk full rất hay gặp ngoài thực tế.

Phần thực hành mở rộng: quan sát process, CPU, RAM như khi đang xử lý sự cố

Người mới thường biết chạy top nhưng không biết nhìn gì. Phần này tập trung vào cách quan sát tài nguyên có mục tiêu.

Lab 1: Chụp nhanh trạng thái máy

uptime
free -h
vmstat 1 5
top -b -n 1 | head -30

Điều cần nhìn:

• load average có cao bất thường không
• RAM còn trống bao nhiêu, swap có dùng không
• process nào đang ăn CPU

Lab 2: Dùng ps để lọc đúng process

ps aux --sort=-%cpu | head -10
ps aux --sort=-%mem | head -10
pgrep -a ssh
pgrep -a cron

Thực tế vận hành thường cần những câu hỏi rất cụ thể: tiến trình nào ăn CPU nhất, ai đang chiếm RAM, service kia có process sống không.

Lab 3: Tạo tải CPU giả để quan sát

yes > /dev/null &
yes > /dev/null &
ps aux --sort=-%cpu | head -10
top -b -n 1 | head -20
killall yes

Lab này rất tốt vì anh sẽ thấy ngay process yes leo CPU. Sau đó dừng nó và quan sát hệ thống hạ tải.

Lab 4: Tạo tiêu thụ RAM để quan sát

Nếu có Python:

python3 - <<'PY'
a=['x'*1024*1024 for _ in range(200)]
input('Press Enter to exit...')
PY

Trong terminal khác chạy:

free -h
ps aux --sort=-%mem | head -10

Sau đó thoát chương trình và xem RAM được trả lại ra sao.

Lab 5: Giết process đúng cách

sleep 300 &
ps aux | grep '[s]leep 300'
kill PID

Nếu process không dừng, mới cân nhắc:

kill -9 PID

Người mới cần hiểu: kill -9 là biện pháp mạnh, không phải mặc định.

Lab 6: Liên hệ process với service

systemctl status ssh --no-pager
ps -ef | grep '[s]shd'

Mục tiêu là hiểu service manager và process thật liên quan với nhau như thế nào.

Tình huống thực tế

Một website chậm bất thường. Thay vì restart ngay, sysadmin nên kiểm tra:

1. load average
2. CPU đang bị process nào dùng
3. RAM và swap
4. số lượng process web/app/database
5. log lỗi gần thời điểm đó

Lỗi phổ biến

• Nhìn load average mà không hiểu ý nghĩa theo số CPU.
• Thấy RAM “used” cao rồi kết luận máy sắp hết RAM, dù phần lớn là cache.
• Dùng kill -9 quá sớm.
• Không phân biệt process thật với tiến trình grep chính mình.

Bài tập thêm

1. Tạo một process ăn CPU và một process ngủ lâu.
2. Dùng ps, top, pgrep để tìm chúng.
3. Ghi lại sự khác nhau giữa CPU-bound và idle process.
4. Viết một checklist 5 bước khi máy bị chậm.

Phần đào sâu thêm: đọc tài nguyên theo bối cảnh, không đọc số liệu rời rạc

CPU, RAM và process không nên được đọc tách rời. Khi máy chậm, anh phải ghép chúng lại thành một câu chuyện: tải tăng khi nào, process nào gây ra, RAM có bị thiếu thật không, swap có bị dùng không.

Lab bổ sung: so sánh snapshot và xu hướng

top -b -n 1 | head -20
vmstat 1 5
sar -u 1 5 2>/dev/null || true

top là ảnh chụp một thời điểm, còn vmstat/sar cho anh cảm giác về xu hướng trong vài giây liên tiếp. Đây là khác biệt rất quan trọng khi xử lý spike tải.

Gợi ý phân tích nhanh

• Load cao + CPU idle thấp: có thể đang thật sự bận CPU.
• RAM used cao nhưng available vẫn còn tốt: chưa chắc thiếu RAM.
• Swap tăng mạnh: có thể máy đang bị pressure bộ nhớ.
• Nhiều process giống nhau: có thể app spawn quá mức hoặc worker phình ra.

Bài tập thêm theo kiểu troubleshooting

1. Tạo tải CPU.
2. Ghi lại output của uptime, top, ps, vmstat.
3. Dừng tải.
4. So sánh trước và sau rồi tự mô tả chuyện gì đã xảy ra.

Phần thực hành nâng cao: đọc CPU, RAM và process theo tư duy production

Nếu phần trước giúp anh biết lệnh nào cần chạy, thì phần này giúp anh đọc được câu chuyện đằng sau các con số. Trong production, máy chậm không có nghĩa là cứ thấy CPU cao là restart. Một sysadmin tốt phải biết phân biệt CPU đang bận vì việc gì, RAM đang thiếu thật hay chỉ đang dùng cache, process nào là thủ phạm và process nào chỉ là nạn nhân.

Lab 7: Đọc load average đúng cách thay vì nhìn số rồi hoảng

uptime
nproc
cat /proc/loadavg

Hãy đối chiếu load average với số CPU logic của máy:

• Máy 1 vCPU mà load ~1 kéo dài là đã căng.
• Máy 4 vCPU mà load 1.5 chưa chắc là vấn đề.
• Load cao nhưng CPU không full có thể liên quan đến IO wait hoặc process chờ tài nguyên.

Bài tập: ghi lại load average 1, 5, 15 phút của máy ở thời điểm rảnh và thời điểm anh chủ động tạo tải. Sau đó tự giải thích vì sao các mốc này tăng/giảm khác nhau.

Lab 8: So sánh top, htop và ps để biết mỗi công cụ mạnh ở đâu

top
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -15
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head -15

Nếu máy có htop thì dùng thêm:

htop

• top hợp để xem biến động theo thời gian.
• ps hợp để chụp ảnh nhanh, lọc và redirect ra file.
• htop dễ nhìn hơn cho người mới, đặc biệt khi muốn kill process tương tác.

Hãy yêu cầu người học viết ra 3 điểm khác nhau giữa ba công cụ này. Mục tiêu là tránh học lệnh kiểu thuộc lòng nhưng không biết khi nào dùng cái nào.

Lab 9: Tạo CPU-bound và sleep process để học cách phân biệt

yes > /dev/null &
sleep 600 &
ps -eo pid,stat,cmd,%cpu,%mem --sort=-%cpu | head -10
ps -eo pid,stat,cmd,%cpu,%mem --sort=-%mem | head -10

Quan sát:

• process yes gần như ăn CPU liên tục
• process sleep tồn tại nhưng hầu như không dùng CPU
• trạng thái process trong cột STAT có thể khác nhau

Đây là lab rất quan trọng vì nó dạy người mới rằng “thấy process đang chạy” không có nghĩa “nó là nguyên nhân làm máy chậm”.

Lab 10: Đọc cây process để tìm cha con và nguồn gốc tiến trình

ps -ef --forest | head -40
pstree -p | head -40

Nếu một ứng dụng sinh ra nhiều worker hoặc child process, nhìn cây process sẽ dễ hiểu hơn nhiều so với danh sách phẳng. Khi debug production, anh thường cần biết:

• process nào spawn ra process nào
• worker có bị nhân quá nhiều không
• dịch vụ có còn parent process sống không

Lab 11: Dùng renice để giảm ưu tiên thay vì kill ngay

yes > /dev/null &
pgrep -a yes
sudo renice +10 PID
ps -o pid,ni,cmd -p PID
kill PID

Đây là tư duy rất thực chiến: không phải lúc nào process ngốn CPU cũng cần giết ngay. Nếu đó là tác vụ batch, backup hoặc job nền, giảm priority có thể giúp giữ máy usable trong khi vẫn cho tác vụ hoàn thành.

Lab 12: Nhìn RAM đúng theo góc nhìn Linux

free -h
cat /proc/meminfo | head -30
vmstat 1 5

Giải thích rõ cho người học:

• RAM “used” cao không tự động là xấu.
• Linux tận dụng RAM trống làm cache/buffer để tăng hiệu năng.
• Cần nhìn thêm available, swap và cảm nhận thực tế của hệ thống.
• Nếu swap tăng mạnh kèm máy chậm rõ, đó mới là dấu hiệu cần đào sâu.

Bài tập nhỏ: chụp output free -h trước và sau khi chạy một chương trình dùng RAM, rồi giải thích cột nào thay đổi và vì sao.

Lab 13: Tìm process ngốn RAM nhưng không vội kết luận

ps aux --sort=-%mem | head -15
pmap -x PID | tail -20
cat /proc/PID/status | egrep 'VmRSS|VmSize|Threads'

Người học nên hiểu sự khác nhau giữa:

• VmSize: vùng nhớ ảo process xin
• VmRSS: lượng RAM thật đang resident
• thread nhiều không đồng nghĩa chắc chắn lỗi, nhưng là dấu hiệu nên kiểm tra

Nếu chỉ nhìn một cột %MEM rồi kết luận “app leak RAM” thì rất dễ chẩn đoán sai.

Lab 14: Gắn process với service thực tế của web server hoặc database

systemctl status nginx --no-pager
systemctl status apache2 --no-pager
systemctl status mysql --no-pager
ps -ef | egrep 'nginx|apache2|httpd|mysqld' | grep -v grep

Tùy máy lab có dịch vụ nào thì dùng dịch vụ đó. Điểm quan trọng là kết nối được ba lớp:

1. service name trong systemd
2. main PID hoặc worker PID
3. mức dùng CPU/RAM thật của tiến trình

Đây là bước chuyển từ “biết lệnh Linux” sang “biết debug dịch vụ thật”.

Lab 15: Checklist điều tra khi máy chậm bất thường

Cho người học một checklist chuẩn để áp dụng nhiều lần:

1. Xác nhận triệu chứng: chậm toàn máy hay chỉ một dịch vụ?
2. Chụp nhanh: uptime, free -h, vmstat, top -b -n 1.
3. Xác định process top CPU/RAM bằng ps.
4. Đối chiếu process đó với service và log liên quan.
5. Chỉ sau khi hiểu tương đối mới quyết định restart, kill hay hạ ưu tiên.

Checklist này nghe đơn giản nhưng lại là khác biệt lớn giữa xử lý sự cố có phương pháp và thao tác theo cảm tính.

Tình huống thực tế 1: CPU cao do cron job, không phải do web app

Một website bị phản ánh chậm lúc 2 giờ sáng. Khi kiểm tra, anh thấy CPU tăng mạnh nhưng không phải nginx hay PHP-FPM đứng đầu, mà là một process nén backup do cron chạy. Nếu không đọc kỹ process list, anh rất dễ đổ oan cho ứng dụng web và restart nhầm thứ không liên quan.

Tình huống thực tế 2: RAM tưởng đầy nhưng thực ra Linux đang cache

Một người mới nhìn thấy free -h báo RAM used gần hết rồi kết luận phải nâng RAM ngay. Nhưng khi nhìn thêm cột available và swap, hệ thống vẫn ổn, không có dấu hiệu reclaim căng thẳng. Đây là ví dụ điển hình cho việc đọc sai số liệu vì chưa hiểu cách Linux dùng RAM.

Tình huống thực tế 3: kill -9 làm mất cơ hội điều tra

Một Java process tăng CPU bất thường. Người vận hành vội kill -9 ngay nên dập được triệu chứng, nhưng mất log ngữ cảnh và không kịp chụp stack/thread dump. Sự cố lặp lại hôm sau mà không ai biết gốc rễ. Bài học ở đây là: phản ứng nhanh chưa chắc là phản ứng tốt.

Lỗi phổ biến khi học phần này

• Đồng nhất load average với %CPU.
• Thấy RAM used cao là hoảng, không nhìn available và swap.
• Thấy process top CPU rồi kill ngay không chụp trạng thái trước.
• Không phân biệt process ứng dụng với worker/process nền do cron hoặc backup sinh ra.
• Chỉ nhớ lệnh nhưng không tự trả lời được “em đang muốn kiểm tra điều gì?”.

Bài tập thực hành cuối bài

1. Tạo một process CPU-bound bằng yes và một process idle bằng sleep.
2. Dùng top, ps và nếu có thì htop để tìm chúng.
3. Dùng renice với process CPU-bound rồi quan sát khác biệt.
4. Chụp output free -h trước/sau khi chạy một chương trình dùng RAM.
5. Viết runbook ngắn: “Nếu server chậm, em sẽ kiểm tra theo thứ tự nào và tại sao?”.

Kết bài

Nếu anh làm kỹ phần này, anh sẽ không còn nhìn process, CPU và RAM như ba mảnh rời rạc nữa. Anh sẽ bắt đầu đọc được “câu chuyện của hệ thống”: máy đang bận việc gì, bận do ai, có đáng lo hay không, và nên can thiệp ở mức nào. Đây là nền rất quan trọng trước khi đi sâu hơn vào monitoring, performance tuning và troubleshooting production thật.