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'.
Chạy thử là root, mở file cấm-mọi-quyền vẫn thành công — root bỏ qua mọi bit, kiểm bảo mật khi là root là kiểm không gì cả. Hạ xuống user thường mới ra EACCES. Và nhân kiểm quyền MỘT LẦN lúc open: chmod 000 không thu hồi được fd đang mở, chỉ chặn open mới.
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.
Ép malloc về một arena chỉ làm 8 luồng chậm từ 556 xuống 434 triệu op/s — tưởng arena vô dụng. Nhưng có một biến ẩn đang gánh thay nó: tắt luôn tcache thì thông lượng sập còn 23. Hai lớp chống tranh khóa, mỗi lớp che hiệu ứng của lớp kia. Đo thật.
A giữ SELECT FOR UPDATE trên một hàng: B ghi cùng hàng chờ 2 giây, nhưng ghi hàng khác hay đọc thuần không chờ mảy may. Tôi tưởng khóa chặn tất cả — hóa ra nó chỉ chặn người ghi cùng hàng, đọc luôn qua nhờ MVCC. Và khóa hai hàng ngược thứ tự thì deadlock, PostgreSQL tự hủy một bên.
Tạo một luồng nhanh gấp 3 lần tạo một tiến trình (15µs so với 46µs) vì luồng chia sẻ không gian địa chỉ thay vì sao chép. Nhưng chính sự chia sẻ đó khiến một luồng segfault giết cả tiến trình, trong khi tiến trình con crash không đụng tới cha. Rẻ đổi lấy mong manh; đắt đổi lấy cô lập.