OOM killer
Khi hết RAM, nhân giết ai? Không phải kẻ vừa xin làm tràn, mà KẺ TO NHẤT — một tiến trình ngoài cuộc đang ngồi yên. Đo thật bằng oom_score và dmesg.
#do-dac
495 bài viết
Trang lớn 2MB nhanh hơn trang 4KB 17% — nhưng lần đầu tôi đo ra bằng nhau, vì 'nền 4KB' âm thầm đã là 2MB
Truy cập ngẫu nhiên trên 1 GB: trang 4KB mất 138 ns/lần, trang lớn 2MB chỉ 114 ns — phần chênh là chi phí lỗi TLB. Nhưng lần đầu hai bản nhanh y hệt, vì THP=always khiến cái 'nền 4KB' của tôi thực ra là trang lớn. Xác minh điều kiện, đừng suy từ ý định. Đo thật.
Nạp lại một trang từ swap chậm hơn RAM 58 lần — trong khi mọi bộ đếm khăng khăng 'chẳng có gì xảy ra'
Đọc lại một trang vừa bị đẩy ra swap tốn ~704 ns, chậm hơn đọc RAM 58 lần. Nhưng bộ đếm ru_majflt và pswpin đều báo 0 — chúng nói sự kiện tôi định đo không tồn tại, trong khi VmSwap và đồng hồ nói ngược lại. Tin đồng hồ hơn bộ đếm. Đo thật bằng MADV_PAGEOUT.
Bộ nhớ chia sẻ đo ra 15 GB/s, checksum báo KHỚP — và cả hai đều đang nói dối tôi
Chuyển 1 GB giữa hai tiến trình: pipe 3,1 GB/s, bộ nhớ chia sẻ ring nhiều đệm 9,8 GB/s (~3×). Nhưng shm một đệm lại chậm hơn pipe, và bản bỏ đồng bộ cho 15 GB/s với checksum 'KHỚP' đã suýt lừa tôi viết kết luận sai — vì đo nhầm đại lượng và một phép kiểm vô dụng. Đo thật.
Pipe khai 64 KB, nhưng ghi lố 1 byte mỗi khối thì chỉ nhét được 44 KB — cách đo tự định hình con số
Pipe báo dung lượng 64 KB. Nhưng ghi khối 4097 byte (lố đúng 1 byte qua ranh giới trang) chỉ nhét được 44 KB trước khi write chặn — mất một phần ba. 'Dung lượng pipe' không phải một số duy nhất; chính cỡ khối ghi định hình nó. Và khi đầy, write chặn đúng tới khi bên đọc rút. Đo thật.
8 luồng tranh một khóa mà 99,86% số lần lock không hề chạm tới kernel — strace phơi bày điều tôi đoán sai
Khóa mutex khi không ai tranh chỉ tốn 5,4 ns, thuần userspace, không syscall. Tôi tưởng tranh chấp sẽ đắt gấp trăm lần vì syscall futex() — nhưng đo ra chỉ chậm ~4 lần, và strace cho thấy 99,86% số lần khóa vẫn không vào kernel. Cái đắt hóa ra không phải syscall. Đo thật.