Máy dự phòng chỉ có giá trị nếu bạn chuyển sang được. Tôi giết một máy chính đang ghi dở, thăng cấp máy dự phòng, và đo mọi thứ — kể cả phần khó hơn nhiều: đưa máy cũ quay lại mà không tạo ra hai máy chính cùng nhận ghi.
Sau năm mươi ba phần đo từng cơ chế, phần này đo cách tìm ra chỗ nào đáng đo. Kết quả đầu tiên đã đủ giật mình: cách xếp hạng phổ biến nhất — theo thời gian mỗi lần — dẫn thẳng tới việc tối ưu nhầm truy vấn, bỏ qua đúng câu đang chiếm nhiều tài nguyên nhất.
pg_stat_statements trả lời 'truy vấn nào tốn nhất'. Các khung nhìn pg_stat_* trả lời câu khác: bảng nào, chỉ mục nào, bộ đệm đang làm gì. Tôi đo chúng nói gì, ba chỗ chúng im lặng — gồm một sự cố xoá sạch mọi bộ đếm — và một dự đoán của tôi bị bác bỏ.
Năm mươi lăm phần trước đo từng cơ chế riêng lẻ; phần này ghép lại thành một quy trình gỡ truy vấn chậm và chạy trên một sự cố dựng sẵn từ đầu tới cuối. Bất ngờ lớn nhất: chỉ mục bao phủ mà ai cũng nghĩ là nhanh nhất lại tệ thứ nhì, còn chỉ mục nhanh nhất cũng là chỉ mục nhỏ nhất.
Nâng cấp phiên bản lớn là việc mỗi năm làm một lần nên chẳng ai thuộc. Tôi chạy pg_upgrade thật từ PostgreSQL 16 lên 17, đo từng bước — và tìm ra thứ nó mang theo đầy đủ lẫn thứ nó lặng lẽ để lại, đủ khiến máy chủ vừa nâng xong chậm bất thường vài giờ đầu.
Kafka hay bị gọi là hàng đợi tin nhắn, và cái tên đó đẻ ra phần lớn hiểu nhầm. Tôi đo đặc tính thật sự định nghĩa nó: đọc không xoá tin, ba nhóm cùng đọc đủ. Và 493.421 tin mỗi giây không đến từ 'mỗi tin nhanh' — bỏ gộp lô thì mỗi tin nhanh gấp 34 lần mà thông lượng sụp đổ.