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ín hiệu khứ hồi 17µs, tôi suýt kết 'chậm gấp 14 lần pipe'. Nhưng đo pipe cùng điều kiện cũng 16µs — biến ẩn là ghim lõi khác nhau, không phải tín hiệu. Kèm bẫy gộp tín hiệu: gửi SIGUSR1 100 lần chỉ nhận 1, còn tín hiệu thời gian thực xếp hàng đủ 100.
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.
Đo thời gian trôi qua bằng giờ tường, tôi nhận về -1,000 giây — một khoảng thời gian âm, đoạn code chạy xong trước khi bắt đầu. Vì giờ tường nhảy lùi khi bị chỉnh (NTP, admin). Đo thời lượng phải dùng đồng hồ đơn điệu — CLOCK_MONOTONIC cho +0,000032s đúng đắn ngay cùng lúc đó.
Chạm 64MB bộ nhớ mới tôi tưởng gây 16.384 lỗi trang; getrusage ra 32 — vì trang lớn trong suốt (THP) 2MB, một lỗi lo trọn 2MB. Tắt THP ra đúng 16.384 (lệch 512 lần). Và đọc file đã nằm trong cache gần như không gây lỗi trang nặng nào. Kích thước trang và page cache là biến ẩn — phải đo, đừng nhẩm.
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.
Trực giác nói 'cha chết thì con chết theo'. Tôi dựng cây tiến trình thật rồi bắn SIGKILL vào đúng PID cha: nó chết ngay, ba worker chẳng suy suyển. Vì tín hiệu không lan theo quan hệ cha–con. Muốn hạ cả cụm phải nhắm nhóm — kill(-pgid) một phát hạ tất. Đo thật trong container.