Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
Bắt trọn một luồng TCP của đúng một lần HTTP GET: 10 gói, chỉ 2 chở dữ liệu, 8 gói còn lại là bắt tay + ACK + đóng. Và 'byte ma' của SYN/FIN suýt làm tôi đi tìm một lỗi không hề tồn tại. Đọc từng gói bằng tcpdump.
Hai vòng lặp làm đúng cùng số phép load và cộng, cùng O(n) — đếm phép thì tưởng cùng tốc độ. Nhưng đo ra duyệt ngẫu nhiên chậm 452 lần duyệt tuần tự trên mảng 256 MB. Chi phí thật không nằm ở phép cộng mà ở truy cập bộ nhớ: cache và prefetch. Big-O mù hoàn toàn trước điều đó. Tôi đo bằng C.
fork() không sao chép dữ liệu nhờ copy-on-write (fork 1GB 1,6ms so với memcpy 490ms, nhanh hơn 310 lần), nhưng nó vẫn tốn O(bộ nhớ) vì phải sao chép bảng trang ngay: 33us ở 1MB lên 1613us ở 1GB. Và trên đường đo, gcc -O2 lặng lẽ xóa mất phép memcpy cho ra 0 giây. Đo thật.
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.
Tưởng gọi một lời gọi hệ thống cũng như gọi một hàm thường? Tôi đo thử: vượt ranh giới user→kernel tốn 103ns so với hàm user 0,74ns (139 lần) — và vDSO không vượt ranh giới chỉ 13ns, chứng tỏ chính cú vượt ranh giới là chi phí, không phải việc nhân làm. Nên giảm chi phí = vượt ít lần hơn.
Tưởng ưu tiên cao thì luôn được chạy trước? Tôi dựng lại đúng bug Mars Pathfinder: luồng cao nhất bị chặn 468ms bởi một luồng trung bình — gián tiếp, qua một cái khóa. Bật priority inheritance, thời gian chờ tụt còn 128ms (giảm 73%).