Tưởng malloc trả non-NULL nghĩa là bạn thật sự có bộ nhớ đó? Tôi đo: malloc 48GB trên máy 8GB vẫn thành công (RSS chỉ ~1MB), RAM thật chỉ tốn lúc chạm — và chạm quá giới hạn thì OOM killer bắn chết tiến trình bằng SIGKILL (exit 137), không hề trả NULL cho bạn bắt.
Working-set 80MB trong 100MB RAM: 0 major fault, 900.000 MB/s. Đẩy lên 150MB (tràn 54MB ra swap): 9.000 major fault mỗi lần quét, còn 600 MB/s — chậm 1.500 lần. Swap không phải 'thêm RAM' mà là vùng tràn chậm gấp nghìn lần, và cái vực đó vô hình cho tới đúng ngưỡng working-set gặp RAM.
Truy vấn chọn lọc (1% hàng) dùng index nhanh 4,7 lần; nhưng trên cột boolean 50% hàng, planner bỏ index chọn seq scan. Tôi tưởng 'có index thì phải dùng index'. Index chỉ giúp khi truy vấn trả về ít hàng — và một index chết còn âm thầm làm chậm mọi lần ghi.
Bốn luồng bận báo %CPU = 400% — dùng 4 giây CPU trong 1 giây tường, nghe bất khả nhưng đúng: thời gian CPU cộng dồn qua các lõi. sleep dùng 0% CPU dù wall trôi 1 giây; I/O nặng sys 0,64 lớn hơn user 0,36. 'Mất bao lâu' là câu hỏi mơ hồ tới khi bạn hỏi 'wall hay CPU'.
VACUUM dọn 20000 dead tuple về 0 nhưng bảng vẫn đúng 712kB — nó đánh dấu chỗ trống để tái dùng chứ không trả đĩa. Tôi tưởng VACUUM hỏng vì nhìn kích thước file, hóa ra phải nhìn n_dead_tup. VACUUM FULL mới nén còn 8kB nhưng khóa bảng — hai lệnh gần tên mà khác hẳn tác động.
-O2 tưởng là trần tối ưu cho production? Tôi đo và thấy nó chỉ tối ưu trong PHẠM VI MỘT FILE — ranh giới file chặn nội tuyến xuyên hàm. Bật -flto phá ranh giới đó: hàm hot ở file khác được nội tuyến, lệnh gọi biến mất khỏi vòng nóng, nhanh 1,59 lần chỉ nhờ thêm một cờ.