Autovacuum chạy khi dead tuple vượt threshold cộng scale_factor nhân số dòng sống. Đo thật: scale_factor mặc định 0.2 khiến bảng 100 triệu dòng phải tích 20 triệu dead tuple mới chạy — bloat khổng lồ. Cách chỉnh per-table và theo dõi qua pg_stat_user_tables. PostgreSQL 16.
Cache hit ratio 99% được coi là chỉ số sức khỏe, nhưng nó đánh lừa theo ba cách. Đo thật: một truy vấn self-join có hit ratio 100% (không chạm đĩa) vẫn mất 1,4 giây vì nhân 25 triệu dòng. Ratio đo dữ liệu đến từ đâu, không đo truy vấn tốt hay xấu — công cụ đúng là EXPLAIN BUFFERS. PostgreSQL 16.
200.000 dòng log 30,75 MB vào Loki còn 5,40 MB trên đĩa (nén 5,69 lần), chỉ mục vỏn vẹn 0,42%. Đó là toàn bộ triết lý Loki gói trong một con số: trả tiền chỉ mục cho 15 luồng, không cho 30 MB văn bản. Nhưng thư mục WAL 32 MB suýt làm tôi kết luận Loki phình 1,22 lần thay vì nén 5,69 lần.
Tôi đẩy cùng một tệp log vào Loki và Elasticsearch rồi đo từng con số: ES trả lời nhanh gấp 13 lần, Loki tốn ít hơn 3 lần và nạp nhanh hơn. Nhưng phát hiện đắt nhất là mapping động mặc định của ES phí 29,5% dung lượng, nạp chậm 1,8 lần, lọc chậm 3,5 lần — cho y hệt kết quả. Đây là đánh đổi 'chỉ mục mọi thứ hay không' hiện ra bằng megabyte.
Thu thập một dòng log tốn 1,73 µs — đắt gấp ba lần chính việc ghi ra dòng đó. Và Vector ăn RAM gấp 10 lần Fluent Bit.
Tôi cho một tiến trình ghi 300.000 dòng đánh số rồi chạy logrotate ở giữa. copytruncate làm mất 4.317 dòng, im lặng tuyệt đối; đổi tên file thì không mất dòng nào nhưng cả luồng log chảy vào chỗ không ai đọc. Hai cách xoay vòng, hai kiểu hỏng, không cái nào kêu lên.