Điều tra hiệu năng bắt đầu bằng việc xác định tài nguyên nào đang bão hòa. CPU cao, memory pressure, I/O wait và disk full có triệu chứng gần giống nhau nhưng cách xử lý hoàn toàn khác.
Bài viết dùng một workload Python mô phỏng để thực hành process, signal, load, memory, swap, disk, inode, I/O và giới hạn tài nguyên.
Mục lục
Sản phẩm người đọc sẽ hoàn thành
Sau bài viết, người học hoàn thành một performance triage report và runbook xử lý ETL chậm hoặc bị kill. Project được tổ chức thành các thư mục src, config, logs, tests và evidence. README ghi rõ phiên bản Ubuntu, kiến trúc máy, user thực thi, cách chạy, cách kiểm thử và cách khôi phục.





Bộ dữ liệu hoặc workload thực hành là job Python đọc file lớn, sắp xếp dữ liệu và ghi Parquet trong thư mục lab. Trước khi bắt đầu, tạo snapshot hoặc bản sao dữ liệu, xác nhận còn đủ dung lượng và mở một terminal thứ hai để cứu hộ nếu phiên làm việc chính gặp lỗi. Những nguyên tắc này giúp bài tập gần với cách vận hành Linux trong doanh nghiệp.
Môi trường và quy ước an toàn
mkdir -p ~/linux-lab/{src,config,logs,tests,evidence}
cd ~/linux-lab
printf "started_at=%s\n" "$(date -Is)" | tee evidence/session.txt
uname -a | tee -a evidence/session.txt
cat /etc/os-release | tee -a evidence/session.txt
Bài thực hành dùng Ubuntu Server LTS trên máy ảo tối thiểu 2 vCPU, 4 GB RAM và 20 GB ổ đĩa. Không chạy trực tiếp trên máy production. Những lệnh có khả năng xóa dữ liệu, sửa quyền hoặc khởi động lại service phải được thử trên thư mục lab trước, đồng thời ghi lại trạng thái trước và sau.
1. Process tree và trạng thái
Process có parent, thread, state và command line. Trong bối cảnh ETL chạy chậm và đôi lúc bị hệ điều hành dừng giữa chừng, bước này không chỉ nhằm ghi nhớ câu lệnh mà còn giúp hiểu trạng thái của hệ thống trước khi thay đổi. Mọi thao tác đều cần có đầu vào, kết quả mong đợi và cách quay lại trạng thái an toàn nếu xảy ra lỗi.
Thực hành. Tìm job theo PID, xem tree và trạng thái. Chạy lệnh bằng tài khoản không có quyền root, quan sát mã thoát với echo $?, rồi lưu kết quả vào thư mục evidence/1. Không sao chép lệnh có sudo trước khi hiểu chính xác file, service hoặc quyền sẽ bị thay đổi.
pgrep -af python
ps -eo pid,ppid,state,etimes,%cpu,%mem,cmd --forest | head -30
pstree -ap $$
Kết quả cần thấy. Nhận diện PID đúng mà không dùng grep mơ hồ. Nếu đầu ra khác dự kiến, cần đọc thông báo lỗi từ trái sang phải, xác nhận đường dẫn tuyệt đối, quyền truy cập, biến môi trường và trạng thái tiến trình. Đây là thói quen quan trọng khi làm việc với server thật, nơi một lệnh chạy thành công chưa chắc tạo ra kết quả nghiệp vụ đúng.
Góc nhìn production. Gắn run ID vào command hoặc systemd unit để quan sát rõ. Với hiệu năng Linux, tiêu chí hoàn thành gồm khả năng chạy lại, log đủ để điều tra, quyền tối thiểu, cấu hình có phiên bản và bằng chứng kiểm thử. Một thao tác thủ công chỉ được chấp nhận khi có lý do, người phê duyệt và kế hoạch tự động hóa sau đó.
2. Signal và shutdown
TERM cho ứng dụng cơ hội cleanup, KILL thì không. Trong bối cảnh ETL chạy chậm và đôi lúc bị hệ điều hành dừng giữa chừng, bước này không chỉ nhằm ghi nhớ câu lệnh mà còn giúp hiểu trạng thái của hệ thống trước khi thay đổi. Mọi thao tác đều cần có đầu vào, kết quả mong đợi và cách quay lại trạng thái an toàn nếu xảy ra lỗi.
Thực hành. Gửi TERM cho sleep lab, chờ rồi chỉ KILL nếu timeout. Chạy lệnh bằng tài khoản không có quyền root, quan sát mã thoát với echo $?, rồi lưu kết quả vào thư mục evidence/2. Không sao chép lệnh có sudo trước khi hiểu chính xác file, service hoặc quyền sẽ bị thay đổi.
sleep 300 & pid=$!
kill -TERM "$pid"
for i in {1..5}; do kill -0 "$pid" 2>/dev/null || break; sleep 1; done
Kết quả cần thấy. Process dừng với TERM và không cần KILL. Nếu đầu ra khác dự kiến, cần đọc thông báo lỗi từ trái sang phải, xác nhận đường dẫn tuyệt đối, quyền truy cập, biến môi trường và trạng thái tiến trình. Đây là thói quen quan trọng khi làm việc với server thật, nơi một lệnh chạy thành công chưa chắc tạo ra kết quả nghiệp vụ đúng.
Góc nhìn production. Ứng dụng bắt signal, hoàn tất transaction và flush log trong grace period. Với hiệu năng Linux, tiêu chí hoàn thành gồm khả năng chạy lại, log đủ để điều tra, quyền tối thiểu, cấu hình có phiên bản và bằng chứng kiểm thử. Một thao tác thủ công chỉ được chấp nhận khi có lý do, người phê duyệt và kế hoạch tự động hóa sau đó.
3. Load average và CPU
Load gồm task chờ CPU hoặc I/O không ngắt được. Trong bối cảnh ETL chạy chậm và đôi lúc bị hệ điều hành dừng giữa chừng, bước này không chỉ nhằm ghi nhớ câu lệnh mà còn giúp hiểu trạng thái của hệ thống trước khi thay đổi. Mọi thao tác đều cần có đầu vào, kết quả mong đợi và cách quay lại trạng thái an toàn nếu xảy ra lỗi.
Thực hành. So load với số core, quan sát vmstat theo thời gian. Chạy lệnh bằng tài khoản không có quyền root, quan sát mã thoát với echo $?, rồi lưu kết quả vào thư mục evidence/3. Không sao chép lệnh có sudo trước khi hiểu chính xác file, service hoặc quyền sẽ bị thay đổi.
nproc
uptime
vmstat 1 5
ps -eo pid,psr,%cpu,cmd --sort=-%cpu | head
Kết quả cần thấy. Biết load trên mỗi core và user system idle iowait. Nếu đầu ra khác dự kiến, cần đọc thông báo lỗi từ trái sang phải, xác nhận đường dẫn tuyệt đối, quyền truy cập, biến môi trường và trạng thái tiến trình. Đây là thói quen quan trọng khi làm việc với server thật, nơi một lệnh chạy thành công chưa chắc tạo ra kết quả nghiệp vụ đúng.
Góc nhìn production. Alert dựa trên saturation kéo dài và latency của dịch vụ. Với hiệu năng Linux, tiêu chí hoàn thành gồm khả năng chạy lại, log đủ để điều tra, quyền tối thiểu, cấu hình có phiên bản và bằng chứng kiểm thử. Một thao tác thủ công chỉ được chấp nhận khi có lý do, người phê duyệt và kế hoạch tự động hóa sau đó.
4. Bộ nhớ available
Linux dùng RAM trống làm cache nên free thấp không tự động xấu. Trong bối cảnh ETL chạy chậm và đôi lúc bị hệ điều hành dừng giữa chừng, bước này không chỉ nhằm ghi nhớ câu lệnh mà còn giúp hiểu trạng thái của hệ thống trước khi thay đổi. Mọi thao tác đều cần có đầu vào, kết quả mong đợi và cách quay lại trạng thái an toàn nếu xảy ra lỗi.
Thực hành. Đọc free, meminfo và process RSS cao nhất. Chạy lệnh bằng tài khoản không có quyền root, quan sát mã thoát với echo $?, rồi lưu kết quả vào thư mục evidence/4. Không sao chép lệnh có sudo trước khi hiểu chính xác file, service hoặc quyền sẽ bị thay đổi.
free -h
grep -E "MemTotal|MemAvailable|Swap" /proc/meminfo
ps aux --sort=-rss | head
Kết quả cần thấy. Phân biệt available, cache và swap used. Nếu đầu ra khác dự kiến, cần đọc thông báo lỗi từ trái sang phải, xác nhận đường dẫn tuyệt đối, quyền truy cập, biến môi trường và trạng thái tiến trình. Đây là thói quen quan trọng khi làm việc với server thật, nơi một lệnh chạy thành công chưa chắc tạo ra kết quả nghiệp vụ đúng.
Góc nhìn production. Theo dõi working set và PSI thay vì chỉ free. Với hiệu năng Linux, tiêu chí hoàn thành gồm khả năng chạy lại, log đủ để điều tra, quyền tối thiểu, cấu hình có phiên bản và bằng chứng kiểm thử. Một thao tác thủ công chỉ được chấp nhận khi có lý do, người phê duyệt và kế hoạch tự động hóa sau đó.
5. OOM killer
Khi cạn memory kernel có thể chọn process để kill. Trong bối cảnh ETL chạy chậm và đôi lúc bị hệ điều hành dừng giữa chừng, bước này không chỉ nhằm ghi nhớ câu lệnh mà còn giúp hiểu trạng thái của hệ thống trước khi thay đổi. Mọi thao tác đều cần có đầu vào, kết quả mong đợi và cách quay lại trạng thái an toàn nếu xảy ra lỗi.
Thực hành. Tìm OOM event trong kernel log và ghi PID liên quan. Chạy lệnh bằng tài khoản không có quyền root, quan sát mã thoát với echo $?, rồi lưu kết quả vào thư mục evidence/5. Không sao chép lệnh có sudo trước khi hiểu chính xác file, service hoặc quyền sẽ bị thay đổi.
journalctl -k --since today --no-pager | grep -Ei "out of memory|killed process" | tail -20
Kết quả cần thấy. Có hoặc không có bằng chứng OOM rõ, không suy đoán từ process biến mất. Nếu đầu ra khác dự kiến, cần đọc thông báo lỗi từ trái sang phải, xác nhận đường dẫn tuyệt đối, quyền truy cập, biến môi trường và trạng thái tiến trình. Đây là thói quen quan trọng khi làm việc với server thật, nơi một lệnh chạy thành công chưa chắc tạo ra kết quả nghiệp vụ đúng.
Góc nhìn production. Thiết lập memory limit, request, retry và cảnh báo trước OOM. Với hiệu năng Linux, tiêu chí hoàn thành gồm khả năng chạy lại, log đủ để điều tra, quyền tối thiểu, cấu hình có phiên bản và bằng chứng kiểm thử. Một thao tác thủ công chỉ được chấp nhận khi có lý do, người phê duyệt và kế hoạch tự động hóa sau đó.
6. Disk capacity và inode
Filesystem có thể hết inode dù còn byte. Trong bối cảnh ETL chạy chậm và đôi lúc bị hệ điều hành dừng giữa chừng, bước này không chỉ nhằm ghi nhớ câu lệnh mà còn giúp hiểu trạng thái của hệ thống trước khi thay đổi. Mọi thao tác đều cần có đầu vào, kết quả mong đợi và cách quay lại trạng thái an toàn nếu xảy ra lỗi.
Thực hành. Đo dung lượng, inode và top directory trong phạm vi lab. Chạy lệnh bằng tài khoản không có quyền root, quan sát mã thoát với echo $?, rồi lưu kết quả vào thư mục evidence/6. Không sao chép lệnh có sudo trước khi hiểu chính xác file, service hoặc quyền sẽ bị thay đổi.
df -hT
df -ih
du -xhd1 ~/linux-lab | sort -h
Kết quả cần thấy. Xác định mount, dung lượng và inode bottleneck. Nếu đầu ra khác dự kiến, cần đọc thông báo lỗi từ trái sang phải, xác nhận đường dẫn tuyệt đối, quyền truy cập, biến môi trường và trạng thái tiến trình. Đây là thói quen quan trọng khi làm việc với server thật, nơi một lệnh chạy thành công chưa chắc tạo ra kết quả nghiệp vụ đúng.
Góc nhìn production. Data, log và temp có quota, retention và volume riêng khi cần. Với hiệu năng Linux, tiêu chí hoàn thành gồm khả năng chạy lại, log đủ để điều tra, quyền tối thiểu, cấu hình có phiên bản và bằng chứng kiểm thử. Một thao tác thủ công chỉ được chấp nhận khi có lý do, người phê duyệt và kế hoạch tự động hóa sau đó.
7. File đang mở
Xóa file log không giải phóng disk nếu process còn descriptor mở. Trong bối cảnh ETL chạy chậm và đôi lúc bị hệ điều hành dừng giữa chừng, bước này không chỉ nhằm ghi nhớ câu lệnh mà còn giúp hiểu trạng thái của hệ thống trước khi thay đổi. Mọi thao tác đều cần có đầu vào, kết quả mong đợi và cách quay lại trạng thái an toàn nếu xảy ra lỗi.
Thực hành. Tìm deleted-open file và descriptor của job lab. Chạy lệnh bằng tài khoản không có quyền root, quan sát mã thoát với echo $?, rồi lưu kết quả vào thư mục evidence/7. Không sao chép lệnh có sudo trước khi hiểu chính xác file, service hoặc quyền sẽ bị thay đổi.
lsof +L1 2>/dev/null | head
ls -l /proc/$$/fd | head
Kết quả cần thấy. Nhận diện file đã xóa nhưng còn được giữ. Nếu đầu ra khác dự kiến, cần đọc thông báo lỗi từ trái sang phải, xác nhận đường dẫn tuyệt đối, quyền truy cập, biến môi trường và trạng thái tiến trình. Đây là thói quen quan trọng khi làm việc với server thật, nơi một lệnh chạy thành công chưa chắc tạo ra kết quả nghiệp vụ đúng.
Góc nhìn production. Rotate bằng signal hoặc copytruncate chỉ khi ứng dụng hỗ trợ. Với hiệu năng Linux, tiêu chí hoàn thành gồm khả năng chạy lại, log đủ để điều tra, quyền tối thiểu, cấu hình có phiên bản và bằng chứng kiểm thử. Một thao tác thủ công chỉ được chấp nhận khi có lý do, người phê duyệt và kế hoạch tự động hóa sau đó.
8. I/O và latency
Throughput cao không đồng nghĩa latency tốt. Trong bối cảnh ETL chạy chậm và đôi lúc bị hệ điều hành dừng giữa chừng, bước này không chỉ nhằm ghi nhớ câu lệnh mà còn giúp hiểu trạng thái của hệ thống trước khi thay đổi. Mọi thao tác đều cần có đầu vào, kết quả mong đợi và cách quay lại trạng thái an toàn nếu xảy ra lỗi.
Thực hành. Dùng iostat nếu có và quan sát await utilization. Chạy lệnh bằng tài khoản không có quyền root, quan sát mã thoát với echo $?, rồi lưu kết quả vào thư mục evidence/8. Không sao chép lệnh có sudo trước khi hiểu chính xác file, service hoặc quyền sẽ bị thay đổi.
iostat -xz 1 5
vmstat 1 5
Kết quả cần thấy. Thiết bị bận, await và queue được đọc trong cùng thời gian workload. Nếu đầu ra khác dự kiến, cần đọc thông báo lỗi từ trái sang phải, xác nhận đường dẫn tuyệt đối, quyền truy cập, biến môi trường và trạng thái tiến trình. Đây là thói quen quan trọng khi làm việc với server thật, nơi một lệnh chạy thành công chưa chắc tạo ra kết quả nghiệp vụ đúng.
Góc nhìn production. Tách random/sequential, read/write và kiểm tra storage SLA. Với hiệu năng Linux, tiêu chí hoàn thành gồm khả năng chạy lại, log đủ để điều tra, quyền tối thiểu, cấu hình có phiên bản và bằng chứng kiểm thử. Một thao tác thủ công chỉ được chấp nhận khi có lý do, người phê duyệt và kế hoạch tự động hóa sau đó.
9. Nice và priority
Priority ảnh hưởng cạnh tranh CPU nhưng không sửa thuật toán chậm. Trong bối cảnh ETL chạy chậm và đôi lúc bị hệ điều hành dừng giữa chừng, bước này không chỉ nhằm ghi nhớ câu lệnh mà còn giúp hiểu trạng thái của hệ thống trước khi thay đổi. Mọi thao tác đều cần có đầu vào, kết quả mong đợi và cách quay lại trạng thái an toàn nếu xảy ra lỗi.
Thực hành. Chạy workload lab với nice và quan sát NI. Chạy lệnh bằng tài khoản không có quyền root, quan sát mã thoát với echo $?, rồi lưu kết quả vào thư mục evidence/9. Không sao chép lệnh có sudo trước khi hiểu chính xác file, service hoặc quyền sẽ bị thay đổi.
nice -n 10 sleep 60 &
ps -o pid,ni,cmd -p $!
renice 15 -p $!
Kết quả cần thấy. NI thay đổi đúng và process vẫn hoạt động. Nếu đầu ra khác dự kiến, cần đọc thông báo lỗi từ trái sang phải, xác nhận đường dẫn tuyệt đối, quyền truy cập, biến môi trường và trạng thái tiến trình. Đây là thói quen quan trọng khi làm việc với server thật, nơi một lệnh chạy thành công chưa chắc tạo ra kết quả nghiệp vụ đúng.
Góc nhìn production. Dùng systemd CPUWeight hoặc cgroup cho policy có thể quản trị. Với hiệu năng Linux, tiêu chí hoàn thành gồm khả năng chạy lại, log đủ để điều tra, quyền tối thiểu, cấu hình có phiên bản và bằng chứng kiểm thử. Một thao tác thủ công chỉ được chấp nhận khi có lý do, người phê duyệt và kế hoạch tự động hóa sau đó.
10. Resource limit
Limit ngăn một process dùng hết descriptor hoặc memory. Trong bối cảnh ETL chạy chậm và đôi lúc bị hệ điều hành dừng giữa chừng, bước này không chỉ nhằm ghi nhớ câu lệnh mà còn giúp hiểu trạng thái của hệ thống trước khi thay đổi. Mọi thao tác đều cần có đầu vào, kết quả mong đợi và cách quay lại trạng thái an toàn nếu xảy ra lỗi.
Thực hành. Xem ulimit và giới hạn service. Chạy lệnh bằng tài khoản không có quyền root, quan sát mã thoát với echo $?, rồi lưu kết quả vào thư mục evidence/10. Không sao chép lệnh có sudo trước khi hiểu chính xác file, service hoặc quyền sẽ bị thay đổi.
ulimit -a
systemctl show cron -p LimitNOFILE -p MemoryMax -p CPUQuota
Kết quả cần thấy. Biết limit shell và unit hiện tại. Nếu đầu ra khác dự kiến, cần đọc thông báo lỗi từ trái sang phải, xác nhận đường dẫn tuyệt đối, quyền truy cập, biến môi trường và trạng thái tiến trình. Đây là thói quen quan trọng khi làm việc với server thật, nơi một lệnh chạy thành công chưa chắc tạo ra kết quả nghiệp vụ đúng.
Góc nhìn production. Đặt limit dựa trên capacity test, không tăng vô hạn để che leak. Với hiệu năng Linux, tiêu chí hoàn thành gồm khả năng chạy lại, log đủ để điều tra, quyền tối thiểu, cấu hình có phiên bản và bằng chứng kiểm thử. Một thao tác thủ công chỉ được chấp nhận khi có lý do, người phê duyệt và kế hoạch tự động hóa sau đó.
Kiểm thử cuối bài
Kiểm thử gồm bốn lớp. Lớp chức năng xác nhận xác định đúng bottleneck, dừng job an toàn, đo trước sau và không làm ảnh hưởng process ngoài lab. Lớp dữ liệu đối chiếu số file, kích thước, checksum hoặc số bản ghi trước và sau. Lớp vận hành kiểm tra retry, log, thời gian chạy và mức sử dụng tài nguyên. Lớp bảo mật xác nhận service không chạy bằng root nếu không cần thiết và file nhạy cảm không mở quyền cho group hoặc other.
set -euo pipefail
test -d ~/linux-lab/logs
test -s ~/linux-lab/evidence/session.txt
find ~/linux-lab -type f -perm -0002 -print | tee evidence/world_writable.txt
df -h | tee evidence/disk_after.txt
free -h | tee evidence/memory_after.txt
Một bài lab chỉ đạt khi lệnh có thể chạy lại mà không tạo trạng thái hỏng, lỗi trả mã thoát khác 0, log có timestamp và người khác làm theo README có thể tái tạo kết quả. Nếu kiểm thử chỉ dựa trên việc “màn hình không báo lỗi”, sản phẩm chưa đủ tiêu chuẩn production.
Những lỗi thường gặp và cách xử lý
Lỗi thường gặp là kill -9 ngay lập tức, nhìn %CPU mà bỏ load và core count, coi free memory thấp là lỗi, quên inode, xóa log đang mở và tối ưu trước khi có baseline. Cách xử lý có hệ thống là tái hiện lỗi bằng đầu vào nhỏ, thu thập trạng thái bằng lệnh chỉ đọc, xác định lớp gây lỗi rồi mới thay đổi. Không sửa nhiều cấu hình cùng lúc vì sẽ mất khả năng xác định thay đổi nào thực sự giải quyết vấn đề.
Khi cần trợ giúp, cung cấp phiên bản hệ điều hành, câu lệnh đầy đủ đã che dữ liệu nhạy cảm, output, mã thoát, quyền của file liên quan và log trong đúng khoảng thời gian xảy ra lỗi. Mô tả tốt giúp rút ngắn thời gian điều tra và tránh các lời khuyên nguy hiểm như mở quyền 777 hoặc tắt firewall.
Đưa kỹ năng vào môi trường production
Monitoring cần CPU saturation, memory pressure, disk latency, inode, filesystem usage và OOM event. Capacity review dựa trên percentile và tăng trưởng, không chỉ trung bình.
Trước mỗi thay đổi, cần có ticket, phạm vi ảnh hưởng, cửa sổ triển khai, backup, tiêu chí thành công, tiêu chí rollback và người chịu trách nhiệm. Sau thay đổi, lưu evidence, cập nhật runbook và theo dõi ít nhất một chu kỳ workload. Linux ổn định không đến từ một câu lệnh thần kỳ mà từ quy trình có thể kiểm chứng.
Bài tập mở rộng
- Viết một script chỉ đọc để thu thập trạng thái liên quan đến chủ đề và xuất báo cáo có timestamp.
- Tạo một lỗi có kiểm soát trong máy ảo, ghi triệu chứng, giả thuyết, bằng chứng và cách khôi phục.
- Chuyển ba thao tác thủ công thành script có
set -euo pipefailvà kiểm tra đầu vào. - Viết runbook một trang để người khác thực hiện mà không cần hỏi lại tác giả.
- Đánh giá thay đổi cần thiết nếu workload tăng gấp 100 lần.
Tài liệu tham khảo
- Ubuntu Server Documentation.
- GNU Coreutils và Bash Reference Manual.
- Linux man-pages project.
- systemd và OpenSSH documentation, sử dụng theo nội dung từng bài.
Kết luận
Linux performance là quá trình đo, hình thành giả thuyết và kiểm chứng. Công cụ chỉ có giá trị khi gắn với timeline và workload cụ thể.
TechData.AI - Leading the Future.
Tham khảo các khoá học theo link: https://techdata.ai/techdata-ai-course/
Hoàng Minh.
