RSS, VSZ — một tiến trình thật sự chiếm bao nhiêu RAM

TL;DR: VSZ đếm toàn bộ không gian địa chỉ ảo mà tiến trình đã đăng ký, kể cả phần chưa hề chạm vào, nên nó gần như vô dụng khi hỏi "tốn bao nhiêu RAM". RSS đếm số trang đang thật sự nằm trong RAM, sát hơn nhiều nhưng có một khiếm khuyết chí mạng: trang dùng chung được tính đủ cho mọi tiến trình dùng nó, nên cộng RSS toàn máy thì ra con số lớn hơn cả RAM vật lý mà máy vẫn chạy êm. PSS sửa đúng chỗ đó bằng cách chia trang chia sẻ theo số bên dùng, và là chỉ số duy nhất trong ba cái này cộng lại được.

Một máy 16 GB RAM. Bạn chạy ps aux, cộng cột RSS của mọi tiến trình lại, và ra 31 GB. Máy không swap, không chậm, không có gì bất thường trong dmesg.

Không có phép màu nào ở đây, cũng chẳng phải công cụ báo sai. Chỉ là phép cộng đó không có nghĩa, và vì sao nó không có nghĩa là toàn bộ nội dung bài này.

1. Analogy — chung cư và bức tường chung

Một toà chung cư 1.000 m². Hỏi mười hộ "căn của bạn rộng bao nhiêu", ai cũng tính cả bức tường ngăn với hàng xóm, cả cầu thang, cả hành lang. Cộng mười câu trả lời lại thì ra 1.400 m², to hơn cả toà nhà.

Không ai nói dối. Bức tường giữa hai căn có thật, và nó phục vụ cả hai. Cái sai nằm ở phép cộng: bạn vừa cộng mỗi bức tường hai lần.

Muốn con số cộng được thì phải đổi cách khai: tường chung giữa hai hộ thì mỗi hộ khai một nửa. Đó đúng là điều PSS làm với những trang bộ nhớ được nhiều tiến trình dùng chung.

2. VSZ và RSS đo hai thứ gì khác nhau?

Nguồn thật nằm ở file status trong thư mục /proc của tiến trình, và nó chi tiết hơn hẳn cột trong ps:

grep -E 'VmSize|VmPeak|VmRSS|VmHWM|RssAnon|RssFile|RssShmem' /proc/self/status
# VmPeak:   2724316 kB
# VmSize:   2724316 kB
# VmHWM:      52140 kB
# VmRSS:      51884 kB
# RssAnon:    18232 kB
# RssFile:    33652 kB
# RssShmem:       0 kB

Đọc cặp đầu tiên là thấy ngay khoảng cách: VmSize (chính là VSZ) 2,7 GB, còn VmRSS (chính là RSS) 51 MB. Tiến trình này đăng ký một không gian địa chỉ khổng lồ nhưng chỉ đụng vào một phần nhỏ xíu của nó.

VSZ đếm mọi vùng đã ánh xạ vào không gian địa chỉ ảo, bất kể trang đó có nằm trong RAM hay không, thậm chí bất kể nó đã từng được chạm tới hay chưa. Một JVM đặt -Xmx8g đăng ký trước cả vùng heap ngay lúc khởi động; một thư viện mmap một file 4 GB cũng cộng luôn 4 GB vào VSZ dù chưa đọc byte nào. Vì thế VSZ trả lời câu hỏi "tiến trình này có quyền chạm tới bao nhiêu địa chỉ", chứ không trả lời "nó đang tốn bao nhiêu RAM".

RSS đếm số trang thật sự đang nằm trong RAM vật lý tại thời điểm đo. Đây mới là chỉ số đáng nhìn — nhưng nó vẫn chưa phải câu trả lời, vì lý do ở mục sau.

Hai trường VmPeak và VmHWM ghi lại đỉnh của VSZ và RSS trong suốt đời tiến trình. Một service giờ chỉ chiếm 400 MB nhưng VmHWM là 6 GB thì bạn vừa bắt được dấu vết của cú phình mà không ai kịp nhìn thấy lúc nó xảy ra.

Ba dòng RssAnon, RssFile, RssShmem chia RSS theo nguồn gốc, và cách chia này quay lại rất quan trọng ở bài 05:

Đây là lý do hai tiến trình cùng RSS 2 GB có thể gây hai hậu quả hoàn toàn khác nhau lúc máy cạn RAM: cái nào toàn RssFile thì kernel dọn nhẹ nhàng, cái nào toàn RssAnon thì không có đường lùi.

3. Vì sao tổng RSS lớn hơn RAM thật?

Vì một trang vật lý có thể nằm trong RSS của nhiều tiến trình cùng lúc, và mỗi tiến trình đều tính đủ nó.

Ba nguồn gây chồng lấn, xếp theo mức phổ biến:

Thứ nhất là thư viện dùng chung. Toàn máy chỉ có một bản libc trong RAM, nhưng mọi tiến trình đều ánh xạ nó vào không gian của mình và đều tính phần đang cư trú vào RSS của mình. Hai trăm tiến trình dùng chung một thư viện 100 MB thì phép cộng ra 20 GB cho thứ chiếm đúng 100 MB.

Thứ hai là fork với copy-on-write. Ngay sau fork, tiến trình con chia sẻ toàn bộ trang với cha; kernel chỉ nhân bản một trang khi có bên ghi vào nó. Một tiến trình 8 GB fork ra bốn tiến trình con thì ps báo 40 GB, còn RAM thật sự tốn thêm gần bằng không cho tới lúc có ai ghi.

Thứ ba là file được ánh xạ: trang page cache của một file đang được nhiều tiến trình mmap cũng vào RSS của từng bên.

4. PSS — chỉ số duy nhất cộng lại được

Kernel bày sẵn cách đếm không trùng, trong smaps: mỗi vùng ánh xạ được kê riêng, và trang chia sẻ được chia theo tỉ lệ số tiến trình đang dùng. Một trang 4 KB được 4 tiến trình dùng chung thì mỗi bên nhận đúng 1 KB vào PSS của mình.

# Tong PSS cua mot tien trinh, tinh bang MB
awk '/^Pss:/ { total += $2 } END { print total/1024, "MB" }' /proc/self/smaps

Cùng file đó còn tách phần riêng ra khỏi phần chung: Private_Clean là trang chỉ mình tiến trình này dùng và giống hệt bản trên đĩa, Private_Dirty là trang chỉ mình nó dùng và đã bị sửa. Cặp này trả lời trực tiếp câu hỏi thực dụng nhất khi máy hết RAM: giết tiến trình đó thì thu lại được bao nhiêu? Đáp án là phần riêng của nó, chứ không phải RSS, vì trang chia sẻ vẫn còn bên khác dùng nên không đi đâu cả.

Cạnh smaps còn có một file tổng hợp sẵn để script giám sát khỏi phải cộng tay từng vùng.

Ba chỉ số, ba câu hỏi khác nhau:

5. Pitfall của riêng concept này

❌ Nhầm 1 — cộng RSS toàn máy rồi hoảng.

✅ Phép cộng đó đếm trùng mọi trang chia sẻ. Muốn cộng thì cộng PSS. Còn muốn biết máy có sắp hết RAM không thì nhìn dung lượng khả dụng và mức swap, chứ không nhìn tổng của một cột.

❌ Nhầm 2 — dùng VSZ để đặt hạn mức bộ nhớ.

✅ VSZ phồng lên vì đủ thứ không tốn RAM: vùng đăng ký trước, file ánh xạ, arena của trình cấp phát. Đặt trần theo VSZ thì hoặc bạn giết oan một tiến trình khoẻ mạnh, hoặc bạn đặt một con số to tới mức chẳng chặn được gì.

❌ Nhầm 3 — thấy RSS của tiến trình con bằng RSS của cha rồi kết luận bộ nhớ nhân đôi sau fork.

✅ Ngay sau fork thì hai bên dùng chung gần như toàn bộ trang nhờ copy-on-write. RAM thật chỉ tăng dần theo lượng trang bị ghi vào. Muốn thấy con số thật thì nhìn PSS của hai tiến trình.

❌ Nhầm 4 — coi RSS thấp là bằng chứng không rò rỉ bộ nhớ.

✅ Rò rỉ có thể nằm ở phần đã bị đẩy sang swap, hoặc ở bộ nhớ ngoài heap mà công cụ theo dõi heap không thấy. So VmHWM với RSS hiện tại, và nhìn xu hướng thay vì một lần đo.

6. 📚 Đào sâu (tuỳ chọn)

Đọc smaps của một tiến trình đang chạy trên máy bạn là bài tập bổ ích bất ngờ: tỉ lệ giữa phần riêng với phần chung thường lệch xa dự đoán.

7. Liên hệ các bài khác

• top, htop và load average — ba cột VIRT, RES, SHR trong cùng màn hình đó là ba chỉ số bài này vừa mổ.
• cgroups — trần tài nguyên — trần bộ nhớ của container đếm theo cách khác hẳn RSS, và đó là lý do container bị giết trong khi top trông vẫn ổn.
• OOM kill và ulimit — dòng log OOM in ra anon-rss với file-rss riêng; chia được hai loại đó thì đọc được vì sao đúng tiến trình ấy bị chọn.
• mmap và copy-on-write — cơ chế tạo ra chuyện chồng lấn mà bài này đang đếm hậu quả.

8. Tóm tắt

• Khoảng cách giữa VmSize và VmRSS trong file status thường là vài chục lần, và nó không phải dấu hiệu bất thường.
• VmHWM giữ lại đỉnh RSS sau khi cú phình đã qua — thứ đáng xem đầu tiên khi khám nghiệm một sự cố bộ nhớ.
• Chia RSS thành RssAnon với RssFile cho biết kernel còn đường lùi hay không: trang có file nền bỏ đi được, trang ẩn danh thì không.
• Trang chia sẻ khiến RSS không cộng được; PSS chia chúng theo số bên dùng nên tổng PSS mới có nghĩa.
• Câu hỏi "giết tiến trình này thu lại bao nhiêu RAM" trả lời bằng phần riêng, không bằng RSS.

9. Tự kiểm tra

Bài tiếp theo: Đo I/O bằng iostat — và vì sao %util nói dối