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.
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.
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.
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.
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.
Định dùng perf đo cache-miss, nhưng mọi bộ đếm phần cứng trả ENOENT — máy ảo trên Apple Silicon không mở PMU cho guest. Bộ đếm phần mềm vẫn chạy vì nhân tự đếm. Không có counter thì suy hiệu ứng qua thời gian: truy cập ngẫu nhiên chậm 2,4 lần tuần tự. Một 'không đo được' trung thực hơn một con số bịa.
Cost một seq scan = 5406 trang × 1.0 + 1 triệu hàng × 0.01 = 15406.00, khớp EXPLAIN đến từng số lẻ. Tôi tưởng cost cố định theo dữ liệu; nhưng đổi random_page_cost là planner đổi kế hoạch dù dữ liệu y nguyên. Cost là đầu ra của một mô hình với tham số phần cứng, không phải mili giây, không phải bất biến.