App chạy ổn lúc đầu rồi bỗng crash sau vài giờ với 'Too many open files'? Gần như luôn là rò rỉ file descriptor — mở file/socket mà quên đóng. Bài này chạy thật: mô phỏng rò rỉ đến khi chạm ulimit và nhận Errno 24, so với bản dùng with (fd phẳng lì ở 4), và cách đếm fd qua /proc/pid/fd để phát hiện sớm.
Thấy VSZ của app là 2GB và hoảng? Đừng vội. VSZ là không gian địa chỉ ẢO đặt chỗ, còn RSS mới là RAM vật lý thật. Bài này chạy thật: mmap 500MB làm VSZ nhảy lên 513MB nhưng RSS vẫn 7MB (chưa chạm), rồi RSS tăng dần khi chạm vào — cấp phát lười. Đọc đúng cột trong ps/proc để không lo hão.
Chương trình chậm — nhưng chậm vì tính toán nặng, vì chờ I/O, hay vì gọi kernel quá nhiều? Ba con số của time trả lời ngay. Bài này đo thật: chương trình CPU-bound cho user≈real, sleep-bound cho real≫user+sys (đang chờ), syscall-heavy cho sys cao — cùng 'chậm' nhưng ba nguyên nhân và ba cách sửa khác nhau.
App treo, không log, không phản hồi — làm sao biết nó kẹt ở đâu? Nhiều runtime có 'cửa hậu' qua tín hiệu để tự in trạng thái. Bài này chạy thật: gửi SIGQUIT cho một chương trình Go bị treo, runtime in stack tất cả goroutine và chỉ đúng dòng code đang kẹt (chan receive ở hang.go:12); và SIGSEGV/panic tự in nơi crash.
Máy chậm hoặc nóng — tiến trình nào là thủ phạm? ps aux --sort xếp hạng ngay: sort theo %cpu tìm kẻ busy loop, sort theo %mem tìm kẻ ngốn RAM. Bài này chạy thật hai tiến trình (một ngốn CPU 99.5%, một giữ 257MB RAM) và tìm chúng; giải thích vì sao %CPU có thể vượt 100% trên đa lõi, và đọc đúng cột RSS.
Máy chậm mà CPU vẫn rảnh? Có thể một tiến trình đang quật đĩa. /proc/<pid>/io cho biết nó đọc/ghi bao nhiêu byte. Bài này chạy thật: một tiến trình ghi 200MB hiện write_bytes=200MB; nhưng đọc file trong page cache cho rchar=100MB mà read_bytes=0 — dữ liệu từ RAM, không chạm đĩa. Biết đọc cột nào để không bị đánh lừa.