'Too many open files' không phải hết RAM hay đầy đĩa — nó là RLIMIT_NOFILE, một giới hạn chính sách mỗi tiến trình. Tôi hạ giới hạn xuống 20, mở được đúng 17 fd rồi đụng EMFILE (errno 24) trong khi RAM còn dư gần 8GB. Một lỗi 'hết X' khi X còn thừa nghĩa là bạn đụng chính sách, không phải bức tường vật lý.
Chờ 900 fd với chỉ 1 cái sẵn sàng: select/poll tốn ~18.000 ns (O(N), quét hết), epoll_wait 125 ns (phẳng lì dù nghìn fd) — nhanh ~140 lần. Nhưng edge-triggered đọc thiếu thì epoll im lặng và kết nối treo, còn select không đại diện nổi fd ≥ 1024. Chọn đúng công cụ và dùng đúng hợp đồng của nó.
'Too many open files' (EMFILE, mỗi tiến trình) và '...in system' (ENFILE, toàn hệ thống) chỉ khác ba chữ, nhưng cần hai cách chữa khác hẳn. Tôi chạm cái thứ hai, phản xạ vá cái thứ nhất, gõ ulimit cả buổi không xong. Đo thật hai giới hạn fd và bài học đọc kỹ lỗi.
Page cache giữ file trong RAM để đọc lại tức thì (Cached 5,5GB, đọc 256MB ở ~36GB/s, 0 lỗi trang nặng). Nhưng trong container tôi không tạo nổi lần đọc 'nguội': overlayfs không có đĩa chậm thật bên dưới, FUSE thì bỏ qua page cache khách nên luôn chậm. Đo I/O trong container là đo tầng ảo hóa, không phải đĩa.
mmap trông như miễn phí vì không có syscall read — phép đo đầu cho nó nhanh gấp 8 lần. Nhưng getrusage tố cáo nó mới chạm 2176 trang chứ chưa đọc hết file. Cho cả hai cùng cộng 256MB: read() nhanh gấp 5 lần mmap (87 so với 430 ms). Benchmark chỉ có nghĩa khi hai bên làm đúng cùng một việc.
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.