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.
Tưởng seq_cst đắt hơn relaxed nhiều nên nên hạ xuống cho nhanh? Tôi đọc assembly và bấm giờ trên ARMv8: ba mức sinh lệnh khác nhau nhưng thời gian chênh ~1% vì ARM có sẵn ldar/stlr/ldaddal, không cần rào dmb nặng. Chọn ordering cho đúng ngữ nghĩa, không phải tốc độ — seq_cst mặc định gần như miễn phí.
Đọc tuần tự 6701 MB/s, ngẫu nhiên 295 MB/s. Tôi định giải thích bằng 'seek' — rồi nhớ ra đây là SSD, không có đầu đọc để seek. Tách biến: đọc tuần tự y hệt mà TẮT readahead thì sụp còn 134 MB/s, chậm 50 lần. Thủ phạm thật là readahead, không phải seek. Đo thật.
Hai luồng, mỗi luồng tăng bộ đếm riêng — độc lập hoàn toàn, phải chạy song song? Tôi đo thử: nếu hai bộ đếm nằm cùng một cache line, chúng chậm hơn 3,8–4,9 lần vì dòng cache ping-pong giữa hai lõi (false sharing). Tách sang cache line riêng (padding) là khắc phục. Không chia sẻ một byte dữ liệu nào vẫn bị phạt vì chung dòng.
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.
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.
Trên cột lệch 99% 'done', index đầy đủ 30 MB đánh cả những hàng chẳng ai tra; partial index chỉ 'active' còn 240 kB — nhỏ hơn 128 lần, ghi rẻ hơn 2 lần. Nhưng tạo xong rồi WHERE status=$1 vẫn seq scan cả bảng, vì planner không chứng minh được tham số khớp điều kiện index. Cách để index thật sự được dùng.