Container thấy 10 lõi nhưng cgroup chỉ cho dùng 2: 8 luồng bận chỉ đạt 4 giây-lõi thay vì 16, bị đóng băng 20/21 chu kỳ. nproc vẫn nói dối là 10. App 'chậm' dù host rảnh là bị throttle — chẩn đoán bằng cpu.stat chứ không bằng nproc/top, và đặt thread pool theo quota cgroup.
malloc(500MB) trong container 100MB trả về khác NULL — overcommit đồng ý ngay. Nhưng khi tôi chạm vào bộ nhớ đó, nhân giết tiến trình bằng SIGKILL không bắt được, exit 137, memory.events ghi oom_kill=1. malloc thành công không phải bằng chứng bạn có RAM; cái chết đột ngột lúc dùng mới là sự thật.
Working-set 80MB trong 100MB RAM: 0 major fault, 900.000 MB/s. Đẩy lên 150MB (tràn 54MB ra swap): 9.000 major fault mỗi lần quét, còn 600 MB/s — chậm 1.500 lần. Swap không phải 'thêm RAM' mà là vùng tràn chậm gấp nghìn lần, và cái vực đó vô hình cho tới đúng ngưỡng working-set gặp RAM.
mmap 100GB trên máy 8GB thành công ở chế độ always (Committed_AS lên 101GB) — nhưng cùng lệnh đó trả NULL ở chế độ strict, nơi cả cấp phát 6GB cũng thất bại vì vượt CommitLimit ~5GB. malloc thành công hay không không phải thuộc tính của code bạn hay RAM máy, mà của một sysctl toàn hệ thống.
Hai fd tới cùng một file: tạo bằng dup thì chung offset (đọc fd1 dời luôn fd2, fd2 đọc tiếp 'FGHIJ'), mở hai lần thì offset độc lập (fd2 đọc lại 'ABCDE' từ đầu). Cùng 'hai fd một file', hành vi ngược nhau — biến ẩn là cách chúng ra đời. Đo bằng /proc/fdinfo.
Chạy thử là root, mở file cấm-mọi-quyền vẫn thành công — root bỏ qua mọi bit, kiểm bảo mật khi là root là kiểm không gì cả. Hạ xuống user thường mới ra EACCES. Và nhân kiểm quyền MỘT LẦN lúc open: chmod 000 không thu hồi được fd đang mở, chỉ chặn open mới.