Q

Quản trị viên

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.

2300 bài viết · Website
Linux 01/09/2026 7 phút

nice không làm gì cả cho tới khi tôi ghim hai tiến trình vào cùng một nhân — rồi tỉ lệ nhảy thành 98,7 trên 1,3; đây là điều kiện không tài liệu nào nhấn mạnh

CFS chia CPU đều 1/N như nó hứa. Nhưng nice 19 — mức ưu tiên thấp nhất — vẫn nhận đúng một nửa CPU, cho tới khi ép cả hai tiến trình vào cùng một nhân; lúc đó tỉ lệ khớp chính xác bảng trọng số của CFS. Lý do: nice là trọng số trong MỘT hàng đợi chạy, và hai tiến trình ở hai nhân khác nhau không có gì để cân. Trên máy nhiều nhân, nice chỉ có tác dụng khi số tiến trình vượt số nhân.

#hieu-nang#linux#zero-to-hero
29
Backend 01/09/2026 8 phút

Đường ống Redis 10.000 lệnh cho 47,9 lần thông lượng — nhưng đẩy lên 100.000 thì tụt còn một nửa; gộp lô có điểm ngọt, không phải càng lớn càng tốt

Phần 2 thấy đường ống cho hơn bốn mươi lần thông lượng trên một kết nối. Bài này tìm điểm dừng: đường ống 10.000 đạt 969.426 ops/s (47,9×), nhưng 100.000 chỉ còn 473.477 — một nửa, vì chi phí đệm ở hai phía vượt phần tiết kiệm round-trip. Bất ngờ hơn: MGET 100 khoá nhanh hơn đường ống 100 lệnh 45% dù cùng một lượt đi về, vì một lệnh phân tích một lần thay vì trăm lần. Và bộ đệm khách thường không có giới hạn (0 0 0).

#redis#hieu-nang#zero-to-hero
33
Linux 01/09/2026 8 phút

Cùng một giá trị giờ, cùng một nguồn: 13,59 ns khi qua vDSO, 154,77 ns khi gọi syscall thẳng — chênh 11 lần, và clock_getres nói dối 24.000 lần

Lấy giờ là thứ mọi log, mọi số liệu, mọi phép đo đều làm. Tôi đo chín cách và tìm ra chênh lệch 11 lần giữa hai cách gọi cùng một hàm (vDSO hay không), một biến thể COARSE rẻ 6 lần đổi lấy độ phân giải 1 ms, và một hàm — clock_getres — báo sai độ phân giải thật tới 24.000 lần. Kèm lỗi kinh điển: dùng REALTIME cho thời hạn.

#hieu-nang#linux#zero-to-hero
28
Linux 01/09/2026 7 phút

SCHED_BATCH nghe như 'chạy khi rảnh' nhưng không nhường CPU một chút nào — còn SCHED_IDLE hạ ưu tiên mạnh gấp bốn lần nice 19, và thời gian thực dừng đúng ở 95%

Bốn cách đổi ưu tiên tiến trình, đo trong đúng điều kiện chúng có tác dụng (hai tiến trình cùng một nhân). Kết quả lật vài trực giác: BATCH vẫn 50/50 vì nó không đụng trọng số, IDLE xuống 0,3% vì nằm ở lớp riêng, và tiến trình thời gian thực bị nhân cố ý chặn ở 95% — tấm lưới duy nhất ngăn một vòng lặp FIFO treo cứng cả máy.

#hieu-nang#linux#zero-to-hero
31
DevOps 01/09/2026 9 phút

PostgreSQL trong Kubernetes chạy 10.366 tps và khởi động lại trong 0,3 giây — nhưng cordon đúng một node là pod Pending vĩnh viễn, vì dữ liệu không đi theo được

Dựng PostgreSQL bằng StatefulSet, đo phần chạy tốt rồi đo đúng chỗ nó gãy. Phần tốt: 10.366 tps, dừng sạch trong 13 ms, khởi động lại 0,3 giây, giữ nguyên định danh và volume. Phần không sửa được bằng YAML: PersistentVolume ghim vào một node, cordon node đó là pod Pending mãi mãi vì dữ liệu nằm trên đĩa node đó. Kubernetes dựng lại pod giỏi, nhưng chỉ ở nơi có dữ liệu — và nó không biết cái nào là bản chính.

#kubernetes#devops#postgresql#zero-to-hero
29
Backend 01/09/2026 9 phút

Ghi giá trị mới thẳng vào cache lệch với cơ sở dữ liệu 103 trên 120 lần — còn 'xoá cache trước khi cập nhật', cái nghe an toàn nhất, để lại dữ liệu cũ nằm đó vĩnh viễn

Bộ đệm chỉ có ích khi nó đúng. Đo bốn cách giữ nó khớp với cơ sở dữ liệu khi có 8 luồng vừa đọc vừa ghi: ghi đè giá trị mới lệch 103/120 lần (tệ nhất, lại trực giác nhất); xoá-trước-cập-nhật nhìn hoàn hảo cho tới khi thêm người đọc song song thì để lại dữ liệu cũ VĨNH VIỄN; chỉ 'xoá sau khi cập nhật' cho lệch tạm thời tự khỏi. Bài toán thật không phải 'làm sao luôn khớp' mà 'lệch bao lâu thì chấp nhận được'.

#redis#postgresql#zero-to-hero
34