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.
Đọc lạnh từ đĩa 93ms, đọc ấm từ cache 18ms — nhanh gấp 5 lần. Nhưng lần đầu tôi đo, hai lần bằng nhau: hóa ra ghi file bằng dd đã nạp sẵn nó vào page cache, nên 'lần đầu' của tôi vốn đã ấm. Muốn đo đọc lạnh phải drop_caches. Đo thật, và cột Cached là đèn báo.
Mỗi lượt một tiến trình chạy ~3 ms rồi bị đẩy ra, và con số đó cố định dù 2 hay 8 tiến trình tranh CPU. Nhưng lần đầu tôi không thấy chia lượt gì cả (quên ghim CPU), và thứ tôi đang đo hóa ra là EEVDF chứ không phải CFS như tên bài. Đo thật hai cú vấp về bộ lập lịch.
write() không fsync đạt ~984.000 ghi/giây, tôi suýt reo 'ghi đĩa nhanh khủng khiếp'. Nhưng đó là tốc độ page cache, dữ liệu chưa bền. Thêm fsync ép xuống đĩa: sụp còn ~2.578 ghi/giây (388us mỗi lần). Gộp một fsync cho cả lô cứu lại tốc độ mà vẫn bền. Đo thật.
Sau fork, con ghi 0% thì chiếm riêng 0MB, ghi 100% thì 400MB — bộ nhớ chia sẻ thật tới đúng lúc ghi. Nhưng RSS đứng yên 400MB ở mọi mức, làm tôi hoảng tưởng COW hỏng. Vì RSS đếm cả trang chung; thước đúng là Private_Dirty/Pss. Đây là gốc nỗi hoảng '50 worker ăn 20GB'. Đo thật bằng smaps.
Tôi dựng từng trạng thái R/S/D/Z/T rồi đọc /proc: một dd ghi đồng bộ nằm trong D (ngủ không-ngắt-được, kill -9 cũng phải chờ) tới 72% thời gian. Rồi liếc load average tưởng nó vọt lên, nhưng nó đứng im — vì là trung bình trượt 1/5/15 phút, phản ứng chậm. Đo thật.
Với khách mới, push né được một vòng khứ hồi (185 xuống 120ms) — đẹp. Nhưng với khách quay lại đã cache CSS, nó gửi lại nguyên 33 KB thừa để đổi vài mili giây, trong khi đường tuần tự chỉ tốn 72 byte nhờ 304. Vì đa số lưu lượng là khách quay lại, một ý tưởng đẹp lại thua trên thực tế. Đo thật.