Chi phí một lời gọi hệ thống
close(-1) không làm gì cả và vẫn tốn 128 ns. Đó là sàn, và nó gấp 174 lần một lời gọi hàm.
Linux
Theo dõi riêng chuyên mục này 54 bài viết
Danh sách kiểm hiệu năng Linux
Chốt sê-ri 50 phần: mọi con số đáng nhớ, và bảy bài học về cách đo mà tôi học được bằng cách đo sai.
Máy ảo, container và chạy thẳng
Ảo hoá làm CPU chậm 1,05 lần và I/O chậm 11 lần. Và lần đo đầu tiên của tôi đổ lỗi nhầm cho ảo hoá.
Bốn sự cố khác hẳn nhau cùng cho ra một câu 'dịch vụ chậm' — nproc và loadavg không phân biệt nổi cái nào, còn một dòng cat thì chỉ đúng thủ phạm
Tôi dựng bốn hoàn cảnh khác nhau, tất cả đều biểu hiện thành 'hệ thống ì', rồi xem chỉ số nào tách được chúng. nproc trả 10 ở cả bốn, loadavg đo nhầm cả máy chủ; còn cpu.stat và PSI phân biệt tuyệt đối. Bonus: bị bóp CPU 0,3 nhân không chỉ chậm 6 lần mà còn tốn 1,81 lần CPU cho cùng một việc.
Cùng một lời gọi fsync, cùng một ổ đĩa: 750.000 IOPS trên RAM, 686 khi bắt nó thật sự bền — hơn một nghìn lần chênh nhau, và bạn chọn được mình đứng đâu
fsync là chỗ trả tiền cho lời hứa của write. Tôi đo nó trên bốn đích đến (tmpfs, ext4 tắt/bật rào chắn, overlay container) và thấy khoảng cách nghìn lần; rồi cho thấy một đòn bẩy trong tay ứng dụng — dồn ghi trước khi fsync — kéo thông lượng lên 79 lần. Đây là cùng cơ chế commit theo nhóm mà mọi cơ sở dữ liệu đều dùng.
Thêm 20 ms độ trễ mà không mất gói nào: 10.403 tụt còn 150 MB/s — rồi làm mất đúng 1% số gói, nó về 4 MB/s; mất gói không lấy đi 1% dữ liệu, nó đánh sập cửa sổ tắc nghẽn
Cùng máy, cùng phần mềm, chỉ đổi đường truyền bằng tc netem. Độ trễ một mình lấy đi 69 lần thông lượng vì TCP phải chờ ACK sau mỗi cửa sổ. Rồi mất một phần nghìn số gói làm mọi thứ chậm 40 lần — vì CUBIC cắt đôi cửa sổ mỗi lần mất gói và không kịp lớn lại. Câu 'chỉ mất có 1% thôi' trong báo cáo sự cố nguy hiểm hơn nó nghe.