Tưởng tối ưu đồng bộ là làm mỗi lần đồng bộ nhanh hơn, hoặc batch càng lớn càng tốt? Tôi đo: gộp lô để giảm SỐ LẦN đồng bộ đẩy throughput từ 32 triệu lên 64,6 tỉ ops/giây — 2000 lần; nhưng độ trễ mỗi item cũng tăng ~94 lần theo kích thước lô. Batch tối ưu là cân bằng, không phải cực đại.
Một lần truy cập bộ nhớ tốn thời gian như nhau? Đo ra: đuổi con trỏ qua vùng làm việc lớn dần, thời gian mỗi truy cập vẽ thành một bậc thang — 0,91 ns khi dữ liệu ở L1, nhảy lên 3,5 ns qua L2, rồi 46 ns, rồi 103 ns khi ra RAM: chênh 113 lần theo tầng cache. Và các ngưỡng nhảy chính là kích thước từng tầng cache của máy.
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ó.
Chỉ cache mới quyết định tốc độ truy cập bộ nhớ? Đo ra: cùng ~128KB dòng cache chạm y hệt nhau, nhưng dữ liệu trải rộng trên 1024 trang chậm gấp 15 lần so với gói gọn trong ~16 trang — 14 ns so với 0,9 ns. Thủ phạm là TLB: bộ nhớ đệm dịch địa chỉ ảo sang vật lý. Trải nhiều trang hơn TLB chứa được thì mỗi truy cập trả thêm một lần đi bảng trang.
Hash map được hứa O(1), nên tưởng mọi lần tra/chèn nhanh như nhau. Đo latency từng lần chèn: trung vị 42 ns, nhưng có một lần 9,8 mili giây khi bảng rehash cả 2 triệu phần tử — chậm hơn 233.000 lần. Tra cũng chậm dần theo load factor, và hàm băm xấu đẩy probe lên 5707. O(1) là trung bình khấu hao. Tôi đo bằng C.
'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ý.