30% RAM là bộ đệm khác. Nó là gì?

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           501M        146M         19M        9.7M        335M        331M
Swap:          1.0G         85M        938M

$ free -w -h
              total        used        free      shared     buffers       cache   available
Mem:           501M        146M         19M        9.7M        155M        180M        331M
Swap:          1.0G         85M        938M

Làm thế nào tôi có thể mô tả hoặc giải thích "bộ đệm" trong đầu ra của free?

Tôi không có bất kỳ vấn đề (đã biết) nào với hệ thống này. Tôi chỉ ngạc nhiên và tò mò khi thấy rằng "bộ đệm" cao gần bằng "bộ đệm" (155M so với 180M). Tôi nghĩ rằng "bộ đệm" đại diện cho bộ đệm trang của nội dung tệp và có xu hướng là phần quan trọng nhất của "bộ đệm / bộ đệm". Tôi không rõ "bộ đệm" dùng để làm gì.

Ví dụ, tôi đã so sánh điều này với máy tính xách tay của tôi, có RAM nhiều hơn. Trên máy tính xách tay của tôi, con số "bộ đệm" là một thứ tự có độ lớn nhỏ hơn "bộ đệm" (200M so với 4G). Nếu tôi có một sự hiểu biết đúng đắn về "bộ đệm" là gì, thì tôi có thể bắt đầu hỏi tại sao bộ đệm có thể phát triển đến một tỷ lệ lớn hơn như vậy trên hệ thống nhỏ hơn.

man proc (Tôi bỏ qua định nghĩa vui nhộn lỗi thời của "lớn"):

Bộ đệm% lu

Lưu trữ tương đối tạm thời cho các khối đĩa thô không nên quá lớn (20MB hoặc hơn).

Đã lưu %%

Bộ nhớ cache trong bộ nhớ cho các tệp được đọc từ đĩa (bộ đệm trang). Không bao gồm SwapCached.

$ free -V
free from procps-ng 3.3.12
$ uname -r
4.9.0-6-marvell
$ systemd-detect-virt
none

$ cat /proc/meminfo
MemTotal:         513976 kB
MemFree:           20100 kB
MemAvailable:     339304 kB
Buffers:          159220 kB
Cached:           155536 kB
SwapCached:         2420 kB
Active:           215044 kB
Inactive:         216760 kB
Active(anon):      56556 kB
Inactive(anon):    73280 kB
Active(file):     158488 kB
Inactive(file):   143480 kB
Unevictable:       10760 kB
Mlocked:           10760 kB
HighTotal:             0 kB
HighFree:              0 kB
LowTotal:         513976 kB
LowFree:           20100 kB
SwapTotal:       1048572 kB
SwapFree:         960532 kB
Dirty:               240 kB
Writeback:             0 kB
AnonPages:        126912 kB
Mapped:            40312 kB
Shmem:              9916 kB
Slab:              37580 kB
SReclaimable:      29036 kB
SUnreclaim:         8544 kB
KernelStack:        1472 kB
PageTables:         3108 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     1305560 kB
Committed_AS:    1155244 kB
VmallocTotal:     507904 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB

$ sudo slabtop --once
 Active / Total Objects (% used)    : 186139 / 212611 (87.5%)
 Active / Total Slabs (% used)      : 9115 / 9115 (100.0%)
 Active / Total Caches (% used)     : 66 / 92 (71.7%)
 Active / Total Size (% used)       : 31838.34K / 35031.49K (90.9%)
 Minimum / Average / Maximum Object : 0.02K / 0.16K / 4096.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
 59968  57222   0%    0.06K    937       64      3748K buffer_head            
 29010  21923   0%    0.13K    967       30      3868K dentry                 
 24306  23842   0%    0.58K   4051        6     16204K ext4_inode_cache       
 22072  20576   0%    0.03K    178      124       712K kmalloc-32             
 10290   9756   0%    0.09K    245       42       980K kmalloc-96             
  9152   4582   0%    0.06K    143       64       572K kmalloc-node           
  9027   8914   0%    0.08K    177       51       708K kernfs_node_cache      
  7007   3830   0%    0.30K    539       13      2156K radix_tree_node        
  5952   4466   0%    0.03K     48      124       192K jbd2_revoke_record_s   
  5889   5870   0%    0.30K    453       13      1812K inode_cache            
  5705   4479   0%    0.02K     35      163       140K file_lock_ctx          
  3844   3464   0%    0.03K     31      124       124K anon_vma               
  3280   3032   0%    0.25K    205       16       820K kmalloc-256            
  2730   2720   0%    0.10K     70       39       280K btrfs_trans_handle     
  2025   1749   0%    0.16K     81       25       324K filp                   
  1952   1844   0%    0.12K     61       32       244K kmalloc-128            
  1826    532   0%    0.05K     22       83        88K trace_event_file       
  1392   1384   0%    0.33K    116       12       464K proc_inode_cache       
  1067   1050   0%    0.34K     97       11       388K shmem_inode_cache      
   987    768   0%    0.19K     47       21       188K kmalloc-192            
   848    757   0%    0.50K    106        8       424K kmalloc-512            
   450    448   0%    0.38K     45       10       180K ubifs_inode_slab       
   297    200   0%    0.04K      3       99        12K eventpoll_pwq          
   288    288 100%    1.00K     72        4       288K kmalloc-1024           
   288    288 100%    0.22K     16       18        64K mnt_cache              
   287    283   0%    1.05K     41        7       328K idr_layer_cache        
   240      8   0%    0.02K      1      240         4K fscrypt_info           

1. Sự khác biệt giữa "bộ đệm" và bộ đệm khác là gì?
2. Tại sao chúng ta thấy sự khác biệt này rất nổi bật? (Lý do lịch sử có thể)
3. Thế nào là Bufferssử dụng cho?
4. Tại sao chúng ta có thể mong đợi Bufferscụ thể là lớn hơn hoặc nhỏ hơn?

1. Sự khác biệt giữa "bộ đệm" và loại bộ đệm khác là gì?

Buffersbáo cáo số lượng bộ đệm trang được sử dụng cho các thiết bị khối. Nhân phải cố tình trừ số tiền này khỏi phần còn lại của bộ đệm trang khi báo cáo Cached.

Xem meminfo_proc_show () :

cached = global_node_page_state(NR_FILE_PAGES) -
         total_swapcache_pages() - i.bufferram;
...

show_val_kb(m, "MemTotal:       ", i.totalram);
show_val_kb(m, "MemFree:        ", i.freeram);
show_val_kb(m, "MemAvailable:   ", available);
show_val_kb(m, "Buffers:        ", i.bufferram);
show_val_kb(m, "Cached:         ", cached);

2. Tại sao chúng ta thấy sự khác biệt này rất nổi bật? (Lý do lịch sử có thể)

Bộ đệm trang hoạt động theo đơn vị kích thước trang MMU, thường là tối thiểu 4096 byte. Điều này rất cần thiết cho việc mmap()truy cập tệp được ánh xạ bộ nhớ. [1] [2] Nó được sử dụng để chia sẻ các trang của mã chương trình / thư viện được tải giữa các quy trình độc lập và cho phép tải các trang riêng lẻ theo yêu cầu. (Ngoài ra để dỡ trang khi có thứ gì đó cần dung lượng và chúng không được sử dụng gần đây).

[1] I / O được ánh xạ bộ nhớ - Hướng dẫn sử dụng Thư viện GNU C.
[2] mmap- Wikipedia.

UNIX ban đầu có "bộ đệm bộ đệm" của các khối đĩa và không có mmap (). Rõ ràng khi mmap () được thêm lần đầu tiên, họ chỉ đơn giản bắt vít bộ đệm trang trên đầu bộ đệm bộ đệm. Điều này là lộn xộn như nó âm thanh. Cuối cùng, hệ điều hành dựa trên UNIX đã thoát khỏi bộ đệm bộ đệm. Vì vậy, bây giờ tất cả các bộ đệm tập tin là trong đơn vị của các trang. Các trang được tra cứu theo (tệp, offset), không phải theo vị trí trên đĩa. Điều này được gọi là "bộ đệm bộ đệm hợp nhất", có lẽ vì mọi người đã quen thuộc hơn với "bộ đệm bộ đệm". [3]

[3] UBC: Hệ thống con I / O và bộ nhớ đệm hợp nhất hiệu quả cho NetBSD

"Một điều thú vị mà Linux bổ sung là các số khối thiết bị nơi một trang được lưu trữ trên đĩa được lưu vào bộ nhớ cache với trang dưới dạng danh sách các buffer_headcấu trúc. Khi một trang được sửa đổi sẽ được ghi lại vào đĩa, I / O yêu cầu có thể được gửi đến trình điều khiển thiết bị ngay lập tức mà không cần phải đọc bất kỳ khối gián tiếp nào để xác định nơi dữ liệu của trang sẽ được ghi. "[3]

Trong Linux 2.2 có một "bộ đệm bộ đệm" riêng được sử dụng để ghi, nhưng không phải để đọc. "Bộ đệm trang đã sử dụng bộ đệm bộ đệm để ghi lại dữ liệu của nó, cần một bản sao bổ sung của dữ liệu và nhân đôi yêu cầu bộ nhớ cho một số lần ghi" (?). [4] Chúng ta đừng quá lo lắng về các chi tiết, nhưng lịch sử này sẽ là một lý do tại sao Linux báo cáo Buffersviệc sử dụng riêng.

[4] Thay thế trang trong quản lý bộ nhớ Linux 2.4 , Rik van Riel.

Ngược lại, trong Linux 2.4 trở lên, bản sao bổ sung không tồn tại. "Hệ thống thực hiện đĩa IO trực tiếp đến và từ trang bộ đệm trang." [4] Linux 2.4 được phát hành năm 2001.

3. BuffersDùng để làm gì?

Các thiết bị chặn được coi là tệp và do đó có bộ đệm trang. Điều này được sử dụng "cho siêu dữ liệu hệ thống tập tin và bộ nhớ đệm của các thiết bị khối thô". [4] Nhưng trong các phiên bản hiện tại của Linux, các hệ thống tệp không sao chép nội dung tệp qua nó, do đó không có "bộ đệm kép".

Tôi nghĩ rằng Buffersmột phần của bộ đệm trang là bộ đệm bộ đệm Linux. Mặc dù một số nguồn có thể không đồng ý với thuật ngữ này.

Hệ thống tập tin sử dụng bao nhiêu bộ đệm, nếu có, phụ thuộc vào chi tiết của hệ thống tập tin cụ thể. Hệ thống trong câu hỏi sử dụng ext4. ext3 / ext4 sử dụng bộ đệm bộ đệm Linux cho tạp chí, cho nội dung thư mục và một số siêu dữ liệu khác.

Một số hệ thống tệp nhất định, bao gồm ext3, ext4 và ocfs2, sử dụng lớp jbd hoặc jbd2 để xử lý nhật ký khối vật lý của chúng và lớp này về cơ bản sử dụng bộ đệm bộ đệm.

- Bài viết qua email của Ted Tso , 2013

Trước phiên bản Linux kernel 2.4, Linux có bộ đệm trang và bộ đệm riêng. Kể từ 2.4, bộ đệm của trang và bộ đệm được thống nhất và Bufferslà các khối đĩa thô không được biểu thị trong bộ đệm của bộ đệm, tức là không phải dữ liệu tệp.

...

Tuy nhiên, bộ đệm bộ đệm vẫn còn, vì kernel vẫn cần thực hiện khối I / O về mặt khối chứ không phải trang. Vì hầu hết các khối đại diện cho dữ liệu tệp, hầu hết các bộ đệm bộ đệm được thể hiện bằng bộ đệm trang. Nhưng một lượng nhỏ dữ liệu khối không phải là tệp được hỗ trợ siêu dữ liệu và I / O của khối thô, ví dụ như, và do đó chỉ được đại diện bởi bộ đệm bộ đệm.

- Một cặp câu trả lời Quora của Robert Love , cập nhật lần cuối 2013.

Cả hai nhà văn đều là nhà phát triển Linux, người đã làm việc với quản lý bộ nhớ nhân Linux. Nguồn đầu tiên cụ thể hơn về chi tiết kỹ thuật. Nguồn thứ hai là một bản tóm tắt tổng quát hơn, có thể bị mâu thuẫn và lỗi thời trong một số chi tiết cụ thể.

Đúng là các hệ thống tập tin có thể thực hiện ghi siêu dữ liệu một phần trang, mặc dù bộ đệm được lập chỉ mục trong các trang. Ngay cả các quy trình người dùng cũng có thể thực hiện ghi một phần trang khi họ sử dụng write()(trái ngược với mmap()), ít nhất là trực tiếp đến một thiết bị khối. Điều này chỉ áp dụng để viết, không đọc. Khi bạn đọc qua bộ đệm trang, bộ đệm trang luôn đọc toàn bộ trang.

Linus thích nói rằng bộ đệm bộ đệm là không bắt buộc để thực hiện ghi kích thước khối và hệ thống tệp có thể thực hiện ghi siêu dữ liệu một phần trang ngay cả với bộ đệm trang được gắn vào tệp riêng của chúng thay vì thiết bị khối. Tôi chắc chắn anh ấy đã đúng khi nói rằng ext2 làm điều này. ext3 / ext4 với hệ thống nhật ký của nó thì không. Không rõ vấn đề gì dẫn đến thiết kế này. Những người mà anh ta đang ca ngợi đã mệt mỏi để giải thích.

ext4_readdir () đã không được thay đổi để đáp ứng lời nói của Linus. Tôi cũng không thấy cách tiếp cận mong muốn của anh ấy được sử dụng trong readdir () của các hệ thống tập tin khác. Tôi nghĩ XFS cũng sử dụng bộ đệm cache cho các thư mục. bcachefs hoàn toàn không sử dụng bộ đệm trang cho readdir (); nó sử dụng bộ nhớ cache riêng cho btrees. Tôi có thể thiếu một cái gì đó trong btrfs.

4. Tại sao chúng ta có thể mong đợi Bufferscụ thể là lớn hơn hoặc nhỏ hơn?

Trong trường hợp này, hóa ra kích thước tạp chí ext4 cho hệ thống tập tin của tôi là 128M. Vì vậy, điều này giải thích tại sao 1) bộ đệm bộ đệm của tôi có thể ổn định ở mức hơn 128M; 2) bộ đệm bộ đệm không chia tỷ lệ với dung lượng RAM lớn hơn trên máy tính xách tay của tôi.

Đối với một số nguyên nhân có thể khác, xem cột bộ đệm trong đầu ra từ miễn phí là gì? Lưu ý rằng "bộ đệm" được báo cáo bởi freethực sự là sự kết hợp của Buffersbộ nhớ bản có thể lấy lại được.

Để xác minh rằng ghi nhật ký sử dụng bộ đệm bộ đệm, tôi đã mô phỏng một hệ thống tệp trong RAM nhanh (tmpfs) và so sánh mức sử dụng bộ đệm tối đa cho các kích thước nhật ký khác nhau.

# dd if=/dev/zero of=/tmp/t bs=1M count=1000
...
# mkfs.ext4 /tmp/t -J size=256
...
# LANG=C dumpe2fs /tmp/t | grep '^Journal size'
dumpe2fs 1.43.5 (04-Aug-2017)
Journal size:             256M
# mount /tmp/t /mnt
# cd /mnt
# free -w -m
              total        used        free      shared     buffers       cache   available
Mem:           7855        2521        4321         285          66         947        5105
Swap:          7995           0        7995

# for i in $(seq 40000); do dd if=/dev/zero of=t bs=1k count=1 conv=sync status=none; sync t; sync -f t; done
# free -w -m
              total        used        free      shared     buffers       cache   available
Mem:           7855        2523        3872         551         237        1223        4835
Swap:          7995           0        7995

# dd if=/dev/zero of=/tmp/t bs=1M count=1000
...
# mkfs.ext4 /tmp/t -J size=16
...
# LANG=C dumpe2fs /tmp/t | grep '^Journal size'
dumpe2fs 1.43.5 (04-Aug-2017)
Journal size:             16M
# mount /tmp/t /mnt
# cd /mnt
# free -w -m
              total        used        free      shared     buffers       cache   available
Mem:           7855        2507        4337         285          66         943        5118
Swap:          7995           0        7995

# for i in $(seq 40000); do dd if=/dev/zero of=t bs=1k count=1 conv=sync status=none; sync t; sync -f t; done
# free -w -m
              total        used        free      shared     buffers       cache   available
Mem:           7855        2509        4290         315          77         977        5086
Swap:          7995           0        7995

Lịch sử của câu trả lời này: Làm thế nào tôi đến để xem tạp chí

Tôi đã tìm thấy email của Ted Tso trước tiên và bị thu hút bởi nó nhấn mạnh vào việc ghi bộ nhớ đệm. Tôi sẽ thấy ngạc nhiên nếu "bẩn", dữ liệu không được ghi có thể đạt tới 30% RAM trên hệ thống của tôi. sudo atopcho thấy trong khoảng thời gian 10 giây, hệ thống được đề cập chỉ ghi 1MB. Hệ thống tập tin liên quan sẽ có thể theo kịp hơn 100 lần tốc độ này. (Đó là trên ổ đĩa cứng USB2, thông lượng tối đa ~ 20MB / s).

Sử dụng blktrace ( btrace -w 10 /dev/sda) xác nhận rằng các IO đang được lưu trong bộ nhớ cache phải được ghi, vì hầu như không có dữ liệu nào được đọc. Ngoài ra, đó mysqldlà quá trình không gian người dùng duy nhất làm IO.

Tôi đã dừng dịch vụ chịu trách nhiệm cho việc ghi (icinga2 ghi vào mysql) và kiểm tra lại. Tôi thấy "bộ đệm" giảm xuống dưới 20 triệu - tôi không có lời giải thích nào cho điều đó - và ở lại đó. Khởi động lại nhà văn một lần nữa cho thấy "bộ đệm" tăng ~ 0,1M cho mỗi khoảng thời gian 10 giây. Tôi quan sát thấy nó duy trì tỷ lệ này một cách nhất quán, tăng trở lại 70M trở lên.

Chạy echo 3 | sudo tee /proc/sys/vm/drop_cacheslà đủ để hạ "bộ đệm" một lần nữa, xuống 4,5M. Điều này chứng tỏ rằng sự tích lũy bộ đệm của tôi là bộ đệm "sạch", mà Linux có thể bỏ ngay lập tức khi có yêu cầu. Hệ thống này không được tích lũy dữ liệu bất thành văn . ( drop_cacheskhông thực hiện bất kỳ thao tác ghi lại nào và do đó không thể bỏ các trang bẩn. Nếu bạn muốn chạy thử nghiệm làm sạch bộ đệm trước, bạn sẽ sử dụng synclệnh).

Toàn bộ thư mục mysql chỉ 150M. Bộ đệm tích lũy phải đại diện cho các khối siêu dữ liệu từ mysql ghi, nhưng tôi ngạc nhiên khi nghĩ rằng sẽ có rất nhiều khối siêu dữ liệu cho dữ liệu này.

Phiên bản của bạn freecó ý tưởng đúng. Theo mặc định, nó kết hợp bộ đệm và bộ đệm trong báo cáo của nó. Điều này là bởi vì về cơ bản chúng là cùng một thứ. Cả hai đều là máy tính ghi nhớ trong RAM (Nhanh hơn lưu trữ thứ cấp: Đĩa và SSD), những gì nó đã thấy khi đọc Đĩa và SSD.

Nếu hệ điều hành cảm thấy rằng bộ nhớ được sử dụng tốt hơn bởi một thứ khác thì nó có thể giải phóng nó. Do đó, đừng lo lắng về bộ đệm và bộ đệm.

Tuy nhiên, việc xem DVD có thể khiến bộ đệm tăng lên và loại bỏ nội dung bộ đệm / bộ đệm khác. Do đó, bạn có thể sử dụng nocache để chạy trình phát DVD ( nếu nó gây ra sự cố ).