Bốn luồng cùng tăng một biến chung 8 triệu lần, đo ra 2.144.770 — mất 73% mà không một lỗi nào báo. Thêm mutex thì đúng nhưng chậm 87 lần. __thread cho mỗi luồng bản riêng: vừa đúng vừa nhanh, truy cập gần ngang biến thường. Bản nhanh nhất lại là bản sai — 'nhanh' mà chưa 'đúng' là con số nguy hiểm nhất.
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.