Thêm luồng vào một khóa chung làm thông lượng SỤP: 226 xuống 27 triệu ops/giây khi lên 2 luồng — mở rộng âm. Chia nhỏ khóa vẫn tụt sau 2 luồng vì chia sẻ giả (các biến chung dòng cache). Chỉ khi đệm mỗi luồng ra riêng một dòng cache mới scale gấp 6. 'Song song' cần độc lập cả về khóa lẫn dòng cache.
Atomic nhanh gấp 2,6 lần mutex ở một luồng (626 so với 239) — nhưng ở tám luồng atomic (25) còn thua mutex (40), và vòng CAS tự viết tụt xuống 7,5 triệu ops/giây với mười triệu lần thử lại. Lock-free không phải contention-free cũng không phải scalable; cách scale thật là giảm chia sẻ.
Tám luồng bận không ghim: nhân tự trải ra tám lõi khác nhau, 854.562 đơn vị công việc. Ghim hết vào một lõi tưởng 'kiểm soát tốt' nhưng chỉ được 165.906 — bằng 1/5, chín lõi ngồi không. Affinity tốt cho một luồng nóng nhưng phản tác dụng khi gom nhiều luồng song song.
'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ý.
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.