RAM miễn phí biến mất - Rò rỉ bộ nhớ?

Trên hệ thống khởi động mới, freebáo cáo khoảng 1,5G RAM đã sử dụng (RAM 8G hoàn toàn, Ubuntu 12.04 với máy tính để bàn lightdm và plasma, một cửa sổ konsole bắt đầu). Có các ứng dụng đang chạy tôi sử dụng, nó vẫn tiêu thụ không quá 2G. Tuy nhiên, khi hệ thống hoạt động được vài ngày, ngày càng nhiều RAM miễn phí của tôi biến mất - mà không hiển thị trong danh sách các ứng dụng đã sử dụng: trong khi smem --pie=namebáo cáo sử dụng ít hơn 20% (và có sẵn 80%), mọi thứ khác nói khác nhau free -mví dụ báo cáo về ngày 7:

             total       used       free     shared    buffers     cached
Mem:          7459       7013        446          0        178        997
-/+ buffers/cache:       5836       1623
Swap:         9536        296       9240

(vì vậy bạn có thể thấy, đó không phải là bộ đệm hoặc bộ đệm). Hôm nay, điều này cuối cùng đã kết thúc với việc hệ thống bị sập hoàn toàn: trình quản lý windows đã biến mất, các ứng dụng "treo lơ lửng" (không khung) - và một cửa sổ bật lên thông báo cho tôi về "quá nhiều tệp đang mở". Báo cáo nhật ký hệ thống:

kernel: [856738.020829] VFS: file-max limit 752838 reached

Vì vậy, tôi đã đóng những ứng dụng mà tôi có thể đóng và giết X bằng cách sử dụng Ctrl-Alt-backspace. X đã cố gắng trở lại sau đó với failafeX, nhưng không thể làm như vậy vì nó không thể phát hiện ra cấu hình của nó nữa. Vì vậy, tôi đã chuyển sang một bảng điều khiển bằng Ctrl-Alt-F2, nắm bắt tất cả thông tin tôi có thể nghĩ đến (vmstat, miễn phí, smem proc/meminfo, lsof, ps aux) và cuối cùng được khởi động lại. X lại xuất hiện với failafeX; lần này tôi bảo nó "phục hồi từ cấu hình đã sao lưu", sau đó chuyển sang giao diện điều khiển và sử dụng thành công startxđể đưa ra môi trường đồ họa.

Tôi không có manh mối thực sự về nguyên nhân gây ra vấn đề này - mặc dù nó phải làm với chính X hoặc với một số quy trình người dùng chạy trên X - như sau khi giết X, free -mđầu ra trông như thế này:

             total       used       free     shared    buffers     cached
Mem:          7459       2677       4781          0         62        419
-/+ buffers/cache:       2195       5263
Swap:         9536         59       9477

(~ 3,5 GB được giải phóng) - để so sánh với đầu ra sau khi bắt đầu mới:

             total       used       free     shared    buffers     cached
Mem:          7459       1483       5975          0         63        730
-/+ buffers/cache:        689       6769
Swap:         9536          0       9536

Hai đầu ra hữu ích hơn được cung cấp bởi memstat -u. Một thời gian ngắn trước khi gặp sự cố:

User     Count     Swap      USS      PSS      RSS
mail         1        0      200      207      616
whoopsie     1      764      740      817     2300
colord       1     3200      836      894     2156
root        62    70404   352996   382260   569920
izzy        80   177508  1465416  1519266  1851840

Sau khi giết X:

User     Count     Swap      USS      PSS      RSS
mail         1        0      184      188      356
izzy         1     1400      708      739     1080
whoopsie     1      848      668      826     1772
colord       1     3204      804      888     1728
root        62    54876   131708   149950   267860

Và sau khi khởi động lại, quay lại X:

User     Count     Swap      USS      PSS      RSS
mail         1        0      212      217      628
whoopsie     1        0     1536     1880     5096
colord       1        0     3740     4217     7936
root        54        0   148668   180911   345132
izzy        47        0   370928   437562   915056

Chỉnh sửa: Chỉ cần thêm hai biểu đồ từ hệ thống giám sát của tôi. Thú vị để xem: mọi lúc khi có "bước nhảy" trong mức tiêu thụ bộ nhớ, CPU cũng đạt đỉnh. Chỉ cần tìm thấy điều này ngay bây giờ - và nó nhắc tôi về một chỉ báo khác chỉ vào chính X: Thường khi quay trở lại máy của tôi và mở khóa màn hình, tôi đã tìm thấy một cái gì đó làm việc nặng trên CPU của mình. Kiểm tra với top, nó luôn luôn là /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch -background none.

Vì vậy, sau lời giải thích dài này, cuối cùng câu hỏi của tôi:

1. Điều gì có thể là nguyên nhân có thể?
2. Làm thế nào tôi có thể xác định tốt hơn các quy trình / ứng dụng liên quan?
3. Những bước nào có thể được thực hiện để tránh hành vi này - không khởi động lại máy trong tất cả X ngày?

Tôi đã chạy 8.04 (Hardy) khoảng 5 năm trên máy cũ của mình, chưa bao giờ gặp phải lỗi như vậy (luôn luôn hơn 100 ngày thời gian hoạt động, trước khi khởi động lại ví dụ như cập nhật kernel). Đây là một máy hoàn toàn mới với bản cài đặt mới 12.04 . Trong trường hợp có vấn đề, một số thông số kỹ thuật:

AMD A4-3400 APU với Đồ họa HD Radeon (tm), sử dụng trình điều khiển ati / radeon mã nguồn mở (vì vậy không cài đặt fglrx), RAM 8GB, WDC WD1002FAEX-0 hdd (1TB), bo mạch chính Asus F1A75-V Evo. Ubuntu 12.04 64-bit với KDE4 / Plasma. Các ứng dụng thường mở ít nhiều vĩnh viễn bao gồm Evolution, Firefox, konsole (với Midnight Commander chạy bên trong, khoảng 4 tab) và LibreOffice - cộng với thỉnh thoảng Calibre, Gimp và Moneyplex (phần mềm ngân hàng tôi đã sử dụng gần 20 năm nay, trong một phiên bản đã làm tốt trên Hardy).

Chỉnh sửa: Hôm nay tôi tìm thấy một trong những "kẻ ác": máy tính để bàn plasma KDE4s. Sử dụng bộ nhớ là một lần nữa lên đến 5GB, khi tôi đã làm một killall plasma-desktop && plasma-desktop. Điều này giải phóng RAM 1,3 GB! psnói:

                             RSS    SIZE   VSZ
plasma usage before restart  120988 526472 1300816
plasma usage after restart   92352  495972 1263632

Vậy những chiếc 1.3GB đó đã ở đâu? Sự khác biệt giữa các giá trị đó, nếu được thêm vào, lên tới 96MB - không phải 1,3 GB.

Và đây chỉ có thể là một phần, vì vẫn còn 3,7 GB đang được sử dụng (nên dưới 2 GB). Tôi đã theo dõi điều này trong 6 ngày qua bằng cách sử dụng một số công cụ: bộ nhớ đã sử dụng (không nói về bộ đệm và bộ đệm) tăng chậm nhưng đều đặn. Ngay cả khi tôi không ở bàn làm việc để chạy bất cứ thứ gì ...

Để theo dõi các quy trình với các tệp đang mở, tôi hiện đang sử dụng 1 lớp lót sau (tôi thích shell và đặc biệt là bash) để có được top 5:

echo "$(for pid in $(ls -a /proc|egrep '^([0-9])*$'|sort -n 2>/dev/null); do \
if [ -e /proc/$pid/fd ]; then FHC=$(ls -l /proc/$pid/fd|wc -l); \
if [ $FHC -gt 0 ]; then PNAME="$(cat /proc/$pid/comm)"; \
echo "$FHC files opened by $pid ($PNAME)"; fi; fi; done)"|sort -r -n|head -n5

Lệnh ở đây trong 4 dòng để dễ đọc hơn. Chưa có gì nhiều từ đó - ngoại trừ việc Skype không thích kết nối Internet bị hỏng. Mỗi lần ngắt kết nối làm tăng nhẹ các tệp đang mở của nó, nhưng không có gì đáng kể. Mặt khác, có vẻ như plasma cũng chịu trách nhiệm cho điều đó:

Xem thả tập tin xử lý ở cuối? Đó là khởi động lại plasma.

1. Số lượng lớn các tệp đang mở là một đầu mối tốt cho thấy có gì đó không ổn. Tôi đoán sẽ là một số daemon hệ thống KDE.

2. Mở một giao diện điều khiển và chạy "đầu". Sau đó, sử dụng <và> để thay đổi cột sắp xếp thành VIRT hoặc RES và xem chương trình nào đang sử dụng nhiều bộ nhớ nhất. Rò rỉ bộ nhớ sẽ hiển thị dưới dạng sử dụng bộ nhớ ảo bị thổi phồng ồ ạt, vì một khi con trỏ đến bộ nhớ bị rò rỉ sẽ không được sử dụng và sẽ bị tráo đổi. Cũng chạy "lsof" và tìm kiếm một quy trình có nhiều tệp đang mở, vì đây dường như thực sự là một rò rỉ mô tả tệp.

3. Theo dõi chương trình và báo cáo lỗi.

Tôi nghĩ rằng đó là hành vi hệ thống bình thường. Nhiều khả năng mọi thứ đều ổn.

Bạn có thể đọc bài báo tuyệt vời này (linux ăn ram của tôi) để hiểu, cách linux quản lý ram của bạn và tại sao không cần phải lo lắng:

http://www.linuxHRyram.com/