Bảng to gấp 10.000 lần (1k lên 10 triệu hàng) mà cây chỉ mục chỉ sâu thêm một tầng (2 lên 3), tìm một hàng vẫn đọc 6-7 trang. Tôi tưởng bảng gấp 100 lần thì tìm phải chậm hẳn — đo ra đường phẳng. Vì fanout ~360, chi phí tra cứu tăng theo log cơ số vài trăm, gần như đứng yên. Cỡ dữ liệu và chi phí tra cứu là hai thứ khác hẳn.
Ba tiến trình cùng mmap một file 90MB. Cộng RSS ba cái ra 270MB — gấp ba dung lượng thật, một con số bất khả. Cộng PSS ra 89MB, khớp RAM thật. Vì sao cộng cột RES trong top luôn thổi phồng bộ nhớ nhóm worker, và cột nào mới cộng đúng.
strace bẫy mỗi syscall bằng ptrace — 200.000 lời write từ 26 ms phồng thành 7144 ms, chậm 270 lần. Cột 'seconds' của strace -c báo write tốn 0,73 giây trong khi cả chương trình chỉ 26 ms: đó là thời gian dưới ptrace, không phải chi phí thật. Kính hiển vi để THẤY, không phải đồng hồ để đo.
Tìm một email trong bảng 1 triệu hàng: không index quét 7353 trang mất 14ms; có index đọc 4 trang mất 0,034ms — nhanh 400 lần, đọc ít 1800 lần. Nhưng tôi suýt khoe 'nhanh 1600 lần' vì đọc nhầm 'cost' như thời gian. Cost là ước lượng của planner, actual time mới là đồng hồ. Bài mở đầu sê-ri Cơ sở dữ liệu.
Busy-poll nhận ra dữ liệu nhanh gấp 9 lần đọc chặn (11µs so với 97µs) — nhưng nó đốt trọn 100% một lõi CPU trong khi đọc chặn ngủ ở 0%. 'Nhanh' vô nghĩa nếu chưa hỏi 'tốn gì'. O_NONBLOCK sinh ra để ghép với epoll, không phải để quay bận ngây thơ.
mmap 100GB trên máy 8GB thành công ở chế độ always (Committed_AS lên 101GB) — nhưng cùng lệnh đó trả NULL ở chế độ strict, nơi cả cấp phát 6GB cũng thất bại vì vượt CommitLimit ~5GB. malloc thành công hay không không phải thuộc tính của code bạn hay RAM máy, mà của một sysctl toàn hệ thống.