Bộ nhớ động của kernel là gì Bộ nhớ động như thế nào được báo cáo bởi smem?

Trong khi chẩn đoán các vấn đề về bộ nhớ thấp trong máy tính để bàn của tôi (chi tiết tại U & L ) tôi đã nhận thấy rằng "bộ nhớ động hạt nhân" không phải của tôi rất lớn :

# smem -twk
Area                           Used      Cache   Noncache 
firmware/hardware                 0          0          0 
kernel image                      0          0          0 
kernel dynamic memory          1.1G     369.3M     801.7M 
userspace memory               2.0G     133.3M       1.9G 
free memory                  734.1M     734.1M          0 
----------------------------------------------------------
                               3.9G       1.2G       2.7G

Trên hai hệ thống khác, tôi đã kiểm tra nó là 150MiB (cũng là máy tính để bàn, nhưng với 8GiB hoặc RAM) và 29MiB. Không nơi nào gần 20% máy tính để bàn của tôi.

Làm thế nào tôi có thể tìm ra những gì làm cho nó lớn như vậy?

BTW: Tôi đã kiểm tra smemcác nguồn, về cơ bản là có (memtotal - userpace - free - cache).

/proc/meminfo:

# mèo / Proc / meminfo 
MemTotal: 4051956 kB
MemFree: 508276 kB
Bộ đệm: 35 232 kB
Đã lưu: 651052 kB
Hoán đổi: 121380 kB
Hoạt động: 1358008 kB
Không hoạt động: 1351596 kB
Hoạt động (anon): 1184616 kB
Không hoạt động (anon): 886904 kB
Hoạt động (tệp): 173392 kB
Không hoạt động (tệp): 464692 kB
Không thể tưởng tượng: 8616 kB
Đã khóa: 8616 kB
Hoán đổi: 4051952 kB
Trao đổi miễn phí: 3815780 kB
Bẩn: 348 kB
Trả lại: 0 kB
AnonPages: 1971164 kB
Đã ánh xạ: 140108 kB
Shmem: 44656 kB
Tấm: 176564 kB
SReclaimable: 62080 kB
SUnreclaim: 114484 kB
Hạt nhân: 3352 kB
Trang: 43012 kB
NFS_Không ổn định: 0 kB
Bounce: 0 kB
WritBackTmp: 0 kB
Cam kết: 6077928 kB
Đã cam kết_AS: 3681164 kB
VmallocTotal: 34359738367 kB
VmallocSử dụng: 139780 kB
VmallocChunk: 34359570976 kB
Phần cứngCorrupted: 0 kB
AnonHugePages: 448512 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 2536128 kB
DirectMap2M: 1656832 kB

linux memory memory-leaks

— Hubert Kario
nguồn

Có lẽ bạn không nên tin tưởng smem, hãy xem câu hỏi này: unix.stackexchange.com/questions/59450/swap-usage-too-high Nếu bạn nhìn vào đầu ra của meminfo, nó nói rằng Shmem (bộ nhớ dùng chung) là khoảng 700 MB. Nếu bạn cung cấp meminfo đó cho smem, nó báo cáo bộ nhớ bộ đệm Kernel có hơn 700 MB, smem tính Shmem trong bộ nhớ kernel, trong khi đây là bộ nhớ không gian người dùng IMHO!

— Huygens

Câu trả lời:

Nhìn thấy một bài đăng khác của bạn, tôi đoán bạn đang sử dụng zram. Vì vậy, đó sẽ là giả định của tôi ở đây.

Tôi đã có kinh nghiệm để cài đặt zram và tiêu thụ rất nhiều bộ nhớ và tôi có cùng sản lượng smemso với bạn. smemkhông tính đến zramviệc đếm của nó , nó chỉ sử dụng /proc/meminfođể tính giá trị của nó, và nếu bạn nhìn và cố gắng hiểu mã, bạn sẽ thấy rằng chiếm dụng RAM zram cuối cùng được tính dưới cột noncache của bộ nhớ động hạt nhân hàng.

Điều tra thêm

Theo cảm nhận của tôi rằng zram đứng đằng sau hành vi này, tôi đã giải quyết một VM với thông số tương tự như máy của bạn: RAM 4 GB và trao đổi zram 2 GB, không có tệp hoán đổi.

Tôi đã tải VM với các ứng dụng nặng và có trạng thái sau:

huygens@ubuntu:~$ smem -wt -K ~/vmlinuz-3.2.0-38-generic.unpacked -R 4096M
Area                           Used      Cache   Noncache 
firmware/hardware            130717          0     130717 
kernel image                  13951          0      13951 
kernel dynamic memory       1063520     922172     141348 
userspace memory            2534684     257136    2277548 
free memory                  451432     451432          0 
----------------------------------------------------------
                            4194304    1630740    2563564 
huygens@ubuntu:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          3954       3528        426          0         79        858
-/+ buffers/cache:       2589       1365
Swap:         1977          0       1977

Như bạn có thể thấy freebáo cáo bộ nhớ cache 858 MB và đó cũng là những gì smemdường như báo cáo trong bộ nhớ động của bộ nhớ cache.

Sau đó, tôi nhấn mạnh thêm hệ thống bằng Trình duyệt Chromium. Lúc đầu, nó chỉ có 83 MB trao đổi được sử dụng. Nhưng sau đó, sau một vài tab được mở, công tắc hoán đổi nhanh chóng đến mức tối đa và tôi đã trải nghiệm OOM! zramthực sự là một khía cạnh nguy hiểm khi cấu hình sai (kích thước quá lớn) nó có thể nhanh chóng đánh trả bạn như một cơ chế giống như trebuchet.

Lúc đó tôi có kết quả như sau:

huygens@ubuntu:~$ smem -wt -K ~/vmlinuz-3.2.0-38-generic.unpacked -R 4096M
Area                           Used      Cache   Noncache 
firmware/hardware            130717          0     130717 
kernel image                  13951          0      13951 
kernel dynamic memory       1355344     124072    1231272 
userspace memory             961004      36456     924548 
free memory                 1733288    1733288          0 
----------------------------------------------------------
                            4194304    1893816    2300488 
huygens@ubuntu:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          3954       2256       1698          0          4        132
-/+ buffers/cache:       2118       1835
Swap:         1977       1750        227

Xem bộ nhớ động của kernel (bộ đệm cột và không bộ đệm) trông như thế nào? Đó là bởi vì trong trường hợp đầu tiên, hạt nhân có bộ nhớ "được lưu trong bộ nhớ cache" như được báo cáo bởi freenhưng sau đó nó có bộ nhớ hoán đổi zrammà smemkhông biết cách tính toán (kiểm tra mã nguồn smem, chiếm đóng zram không được báo cáo trong / Proc / meminfo , đây không phải là smemloại bộ nhớ đơn giản "tổng số mem" - "bộ nhớ được báo cáo bởi meminfo mà tôi biết là bộ đệm", điều mà nó không biết là trong tổng số bộ nhớ kernel được tính, nó đã thêm kích thước của trao đổi trong RAM!)

Khi tôi ở trạng thái này, tôi đã kích hoạt trao đổi đĩa cứng và tắt trao đổi zram và tôi đặt lại các thiết bị zram : echo 1 > /sys/block/zram0/reset.

Sau đó, bộ nhớ kernel noncache tan như tuyết vào mùa hè và trở về giá trị "bình thường".

Phần kết luận

smemkhông biết về zram(chưa) có thể vì nó vẫn đang dàn dựng và do đó không phải là một phần trong /proc/meminfođó báo cáo các tham số toàn cầu (như (trong) kích thước trang hoạt động, tổng bộ nhớ) và sau đó chỉ báo cáo về một vài tham số cụ thể. smemđã xác định một vài tham số cụ thể này là "bộ đệm", tổng hợp chúng và so sánh với tổng bộ nhớ. Do đó, zrambộ nhớ đã sử dụng được tính vào cột noncache .

Lưu ý: nhân tiện, trong kernel hiện đại, meminfocũng báo cáo bộ nhớ dùng chung. smemchưa tính đến điều đó, vì vậy ngay cả khi không có zramđầu ra smemlà xem xét đặc biệt cẩn thận. nếu bạn sử dụng ứng dụng sử dụng nhiều bộ nhớ dùng chung.

Tài liệu tham khảo được sử dụng:

— Huygens
nguồn

Việc hủy kích hoạt zramkhông giúp ích được gì

— Hubert Kario

Bạn có thể sử dụng slabtopnếu có sẵn và xem liệu bất kỳ hoạt động hạt nhân nào có thể chịu trách nhiệm cho việc sử dụng bộ nhớ? Tôi sẽ cố gắng đầu tư thêm vào ngày hôm nay sau đó chính xác là smeming smem và nếu nó có ý nghĩa gì cả!

— Huygens

Tôi đã thiết lập máy ảo với RAM 4 GB và chỉ trao đổi 2 GB bằng zram. Tôi đã mở một vài ứng dụng nặng: Firefox (nhiều tab có hình ảnh, trang facebook, v.v.), LibreOffice, Gimp với một vài bức ảnh 10MP. Đầu ra của smem là kernel 1 GB (bộ nhớ cache mọi thứ nhiều hơn hoặc ít hơn) và không gian người dùng 2,5 GB (nhiều hơn hoặc ít hơn mọi thứ không phải bộ đệm). Không có trao đổi tiêu thụ. Sau đó, tôi đã khởi chạy Chrome, mở một vài trang, tôi bắt đầu có một số trao đổi 83 MB, nhưng điều đó không thay đổi nhiều thứ cho smem. Tuy nhiên, tôi đã mở một số tab khác và bam! Tôi đã có một đầu ra tương tự như smem, xem câu trả lời cập nhật của tôi.

— Huygens

slabtopbáo cáo khoảng 200-300MiB bộ nhớ trong tổng số. Trong khi chạy các ứng dụng, tôi có thể tạo các báo cáo số tương tự trên máy khác của mình bằng cách chạy các ứng dụng, tắt các ứng dụng sẽ làm giảm bộ nhớ động của hạt nhân trên máy kia. Trên máy gặp sự cố, bộ nhớ động không phải hạt nhân không ngừng phát triển cho đến khi hệ thống không sử dụng được (khoảng một tuần thời gian hoạt động)

— Hubert Kario

@HubertKario Có thể zram chỉ là một phần thủ phạm, nhưng tôi có cảm giác như vậy khi hệ thống của bạn chồng chất quá nhiều "bộ nhớ" này mà bạn đang chăm sóc, thì zram có thể khiến vấn đề trở nên tồi tệ hơn :) Nhưng đừng hiểu lầm tôi , Tôi đang cố gắng giúp đỡ ở đây. Bạn đã thử chạy máy chủ của mình trong một tuần mà không có zram (nhưng trao đổi đĩa cứng 4 GB) chưa? Bạn có gặp vấn đề tương tự? Sớm hơn? Một lát sau? Như tôi đã nói với bạn, smemcó thể tính toán sai bộ nhớ kernel noncache, nó có thể không phải là tất cả kernel, nó có thể không phải là noncache. Tin tưởng ps, /proc/<pid>/và /proc/meminfo.

— Huygens

Không có vẻ xấu đối với tôi, rất nhiều bộ nhớ có thể lấy lại được xung quanh. Chính xác thì cái gì không hoạt động (không chỉ là "Ôi, kinh dị, hãy nhìn vào những con số <chương trình ngẫu nhiên> đưa ra!")? Các chương trình sụp đổ (OOM, hết bộ nhớ, xử lý khởi động)? Chương trình không bắt đầu? Hệ thống cảm thấy chậm chạp? Hoạt động liên tục của đĩa? Bất kỳ manh mối trong các bản ghi?

Linux sẽ lấp đầy tất cả bộ nhớ khả dụng, sẽ rẻ hơn nếu chỉ giữ mọi thứ xung quanh hơn là chủ động xóa nó và nó có thể được sử dụng lại sau. Một máy hoạt động (hoặc ngay sau khi khởi động) sẽ cho các số rất khác so với máy được sử dụng tích cực.

— vonbrand
nguồn

Hệ thống trở nên chậm chạp. Khi tôi đang chạy KMail (vì vậy Akonadi, Virtuoso), Opera, Amarok, Ktorrent và một số ứng dụng khác tôi còn lại với ít hơn 700MiB cho bộ đệm hệ thống tệp khi kernel chạy tới 1GiB đầy đủ, hầu như không tối ưu. Và điều này chỉ sau khi X đã chạy được một tuần. Đăng xuất và đăng nhập đơn giản đưa hệ thống trở lại hiệu suất tối ưu (với chính xác các ứng dụng đang chạy). Nhật ký đã dẫn tôi đến một lỗi liên quan đến trình điều khiển readon, tôi hiện đang kiểm tra nếu sự cố vẫn còn.

— Hubert Kario