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.
App chạy lỗi mà log không nói gì? strace cho bạn thấy MỌI syscall chương trình gọi — mở file nào, đọc bao nhiêu byte, kết nối đi đâu. Bài này chạy thật: strace cat phơi bày openat/read/write, bắt file thiếu qua ENOENT, lọc chỉ syscall mạng, và gắn vào tiến trình đang chạy — công cụ debug mạnh nhất khi bạn không có mã nguồn hay log.
Muốn biết một tiến trình đang mở file nào, dùng bao nhiêu RAM thật, chạy từ binary nào — mà không làm nó chậm đi? Đọc /proc/<pid>. Bài này chạy thật: cmdline cho lệnh đầy đủ, status cho VmRSS (RAM thật), fd/ cho file descriptor đang mở, cwd/exe cho thư mục và binary, maps cho bản đồ bộ nhớ — hệ thống file ảo do kernel sinh ra.
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.