RAM의 30 %는 "버퍼"입니다. 무엇입니까?

$ 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

출력에서 "버퍼"를 어떻게 설명하거나 설명 할 수 free있습니까?

이 시스템에 (알려진) 문제가 없습니다. "버퍼"가 "캐시"(155M 대 180M)만큼 높음을 알면 놀랍니다. "캐시"는 파일 내용의 페이지 캐시를 나타내며 "캐시 / 버퍼"의 가장 중요한 부분 인 경향이 있다고 생각했습니다. "버퍼"가 무엇인지 명확하지 않습니다.

예를 들어 이것을 RAM이 더 많은 랩톱과 비교했습니다. 내 노트북에서 "버퍼"수치는 "캐시"(200M 대 4G)보다 훨씬 작은 크기입니다. "버퍼"가 무엇인지 제대로 이해했다면 더 작은 시스템에서 버퍼가 왜 그렇게 큰 비율로 커질 수 있는지 물어볼 수있었습니다.

man proc (나는 엄청나게 구식 인 "큰"정의를 무시한다) :

버퍼 % lu

크지 않아야하는 원시 디스크 블록 (20MB 정도)을위한 상대적으로 임시 저장소.

캐시 된 % lu

디스크에서 읽은 파일에 대한 메모리 내 캐시 (페이지 캐시). 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. "버퍼"와 다른 캐시의 차이점은 무엇입니까?
2. 왜 우리는이 구별이 그렇게 두드러지게 보입니까? (가능한 역사적인 이유)
3. 무엇을 Buffers위해 사용됩니까?
4. 왜 우리 Buffers는 특히 더 크거나 작을 것으로 기대할 수 있습니까?

1. "버퍼"와 다른 유형의 캐시의 차이점은 무엇입니까?

Buffers블록 장치에 사용 된 페이지 캐시의 양을보고합니다. 커널은보고 할 때 나머지 페이지 캐시에서이 금액을 의도 적으로 빼야합니다 Cached.

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. 왜 우리는이 구별이 그렇게 두드러지게 보입니까? (가능한 역사적인 이유)

페이지 캐시는 MMU 페이지 크기 단위 (일반적으로 최소 4096 바이트)로 작동합니다. mmap()즉, 메모리 매핑 된 파일 액세스에 필수적입니다 . [1] [2] 독립 프로세스간에로드 된 프로그램 / 라이브러리 코드 페이지를 공유하고 필요에 따라 개별 페이지를로드 할 수 있습니다. (다른 공간이 필요하고 최근에 사용되지 않은 경우 페이지를 언로드하는 데 사용됩니다).

[1] 메모리 매핑 된 I / O -GNU C 라이브러리 매뉴얼.
[2] mmap-위키 백과.

초기 UNIX에는 디스크 블록의 "버퍼 캐시"가 있었고 mmap ()이 없었습니다. mmap ()이 처음 추가되었을 때, 그들은 단순히 페이지 캐시를 버퍼 캐시 위에 볼트로 고정했습니다. 소리가 지저분합니다. 결국, UNIX 기반 OS는 버퍼 캐시를 제거했습니다. 이제 모든 파일 캐시는 페이지 단위입니다. 페이지는 디스크의 위치가 아닌 (파일, 오프셋)으로 검색됩니다. 사람들이 "버퍼 캐시"에 더 익숙하기 때문에이를 "통합 버퍼 캐시"라고합니다. [3]

[3] UBC : NetBSD를위한 효율적인 통합 I / O 및 메모리 캐싱 하위 시스템

"리눅스가 추가 한 흥미로운 점은 페이지가 디스크에 저장된 장치 블록 번호가 buffer_head구조 목록의 형태로 페이지와 함께 캐시 된다는 것입니다. 수정 된 페이지를 디스크에 다시 기록 할 때 I / O 페이지의 데이터를 기록 할 위치를 결정하기 위해 간접 블록을 읽을 필요없이 요청을 즉시 장치 드라이버로 보낼 수 있습니다. "[3]

Linux 2.2에는 쓰기에는 사용 된 별도의 "버퍼 캐시"가 있지만 읽기에는 사용되지 않았습니다. "페이지 캐시는 데이터를 다시 쓰기 위해 버퍼 캐시를 사용했으며, 추가 데이터 사본이 필요하며 일부 쓰기로드에 대한 메모리 요구 사항이 두 배가되었습니다."(?). [4] 세부 사항에 대해 너무 걱정하지 마십시오.하지만이 역사는 Linux가 Buffers사용법을 별도로 보고하는 이유 중 하나 입니다.

[4] Linux 2.4 메모리 관리의 페이지 교체 , Rik van Riel.

반대로 Linux 2.4 이상에서는 추가 사본이 존재하지 않습니다. "시스템은 페이지 캐시 페이지와 직접 디스크 IO를 수행합니다."[4] Linux 2.4는 2001 년에 출시되었습니다.

3. 무엇을 Buffers위해 사용됩니까?

블록 장치는 파일로 취급되므로 페이지 캐시가 있습니다. "파일 시스템 메타 데이터 및 원시 블록 장치의 캐싱"에 사용됩니다. [4] 그러나 현재 Linux 버전에서는 파일 시스템이 파일 내용을 복사하지 않으므로 "이중 캐싱"이 없습니다.

Buffers페이지 캐시 의 일부는 Linux 버퍼 캐시 라고 생각 합니다. 일부 출처는이 용어에 동의하지 않을 수 있습니다.

파일 시스템이 사용하는 버퍼 캐시의 양은 특정 파일 시스템의 세부 사항에 따라 다릅니다. 문제의 시스템은 ext4를 사용합니다. ext3 / ext4는 저널, 디렉토리 내용 및 기타 메타 데이터에 Linux 버퍼 캐시를 사용합니다.

ext3, ext4 및 ocfs2를 포함한 특정 파일 시스템은 jbd 또는 jbd2 계층을 사용하여 물리적 블록 저널링을 처리하며이 계층은 기본적으로 버퍼 캐시를 사용합니다.

- 이메일 기사 에 의해 테드 TSO 2013

Linux 커널 버전 2.4 이전에는 Linux에 별도의 페이지 및 버퍼 캐시가있었습니다. 2.4 이후로, 페이지 및 버퍼 캐시는 통합 Buffers되어 있으며 페이지 캐시에 표시되지 않은 원시 디스크 블록, 즉 파일 데이터가 아닙니다.

...

그러나 커널은 여전히 ​​페이지가 아닌 블록 단위로 블록 I / O를 수행해야하기 때문에 버퍼 캐시는 남아 있습니다. 대부분의 블록은 파일 데이터를 나타내므로 대부분의 버퍼 캐시는 페이지 캐시로 표시됩니다. 그러나 소량의 블록 데이터는 파일 백업되지 않으며 (예 : 메타 데이터 및 원시 블록 I / O) 버퍼 캐시만으로 표시됩니다.

- Quora의 대답의 쌍 에 의해 로버트 사랑은 , 지난 2013 년 업데이트되었습니다.

두 작가 모두 Linux 커널 메모리 관리 작업을 수행 한 Linux 개발자입니다. 첫 번째 소스는 기술적 세부 사항에 대해 더 구체적입니다. 두 번째 출처는 좀 더 일반적인 요약으로 일부 내용에서는 모순되거나 구식 일 수 있습니다.

캐시가 페이지에서 색인화되어 있어도 파일 시스템이 부분 페이지 메타 데이터 쓰기를 수행 할 수 있습니다. 그들이 사용하는 경우에도 사용자 프로세스가 부분 페이지 쓰기를 수행 할 수있다 write()(반대로 mmap()) 적어도 직접 차단 장치. 이것은 읽기에만 적용되며 읽기에는 적용되지 않습니다. 페이지 캐시를 읽을 때 페이지 캐시는 항상 전체 페이지를 읽습니다.

Linus 는 블록 크기의 쓰기를 수행하기 위해 버퍼 캐시가 필요하지 않으며 파일 시스템이 블록 장치 대신 자체 파일에 페이지 캐시를 첨부 한 경우에도 부분 페이지 메타 데이터 쓰기를 수행 할 수 있음을 좋아했습니다 . 나는 그가 ext2가 이것을한다고 말할 권리가 있다고 확신합니다. 저널링 시스템이있는 ext3 / ext4는 지원하지 않습니다. 이 디자인의 원인이 무엇인지 명확하지 않습니다. 그가 뛰어 다니던 사람들은 설명에 질렸다.

ext4_readdir ()은 Linus의 rant를 만족시키기 위해 변경되지 않았습니다. 다른 파일 시스템의 readdir ()에서도 원하는 접근 방식이 사용되지 않습니다. XFS는 디렉토리에도 버퍼 캐시를 사용한다고 생각합니다. bcachefs는 readdir ()에 대해 페이지 캐시를 전혀 사용하지 않습니다. btree에 자체 캐시를 사용합니다. btrfs에 무언가가 누락되었을 수 있습니다.

4. 왜 우리 Buffers는 특히 더 크거나 작을 것으로 기대할 수 있습니까?

이 경우 내 파일 시스템 의 ext4 저널 크기 는 128M입니다. 이것이 왜 1) 버퍼 캐시가 128M 이상으로 안정화 될 수 있는지 설명합니다. 2) 버퍼 캐시는 랩탑의 RAM 용량에 비례하여 확장되지 않습니다.

다른 가능한 원인은 사용 가능한 출력의 버퍼 열이 무엇입니까?를 참조하십시오 . 보고 된 "버퍼" free는 실제로 Buffers슬래브 메모리 의 조합 이며 재생 가능한 것입니다.

저널 쓰기가 버퍼 캐시를 사용하는지 확인하기 위해 멋진 빠른 RAM (tmpfs)으로 파일 시스템을 시뮬레이션하고 다른 저널 크기에 대한 최대 버퍼 사용량을 비교했습니다.

# 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

이 답변의 역사 : 저널을 보러 온 방법

나는 Ted Tso의 이메일을 먼저 발견했고, 쓰기 캐싱을 강조한 것에 흥미를 느꼈다 . 기록 되지 않은 "더러운" 데이터가 내 시스템에서 RAM의 30 %에 도달 할 수 있다면 놀랍습니다 . sudo atop10 초 간격으로 문제의 시스템은 지속적으로 1MB 만 기록합니다. 관련된 파일 시스템은이 비율을 100 배 이상 유지할 수 있습니다. (USB2 하드 디스크 드라이브에 있으며 최대 처리량은 ~ 20MB / s입니다).

blktrace ( btrace -w 10 /dev/sda)를 사용하면 읽을 데이터가 거의 없으므로 캐시되는 IO가 쓰기 여야 함을 확인합니다. 또한 IO를 수행 mysqld하는 유일한 사용자 공간 프로세스입니다.

쓰기를 담당하는 서비스 (icinga2 mysql에 쓰기)를 중지하고 다시 확인했습니다. "버퍼"가 20M 미만으로 떨어지는 것을 보았습니다. 이에 대한 설명이 없습니다. 라이터를 다시 시작하면 "10 초 간격마다"버퍼 "가 ~ 0.1M 증가합니다. 나는 70M 이상으로 올라가서이 속도를 일정하게 유지하는 것을 관찰했다.

러닝 echo 3 | sudo tee /proc/sys/vm/drop_caches은 "버퍼"를 다시 4.5M로 낮추기에 충분했습니다. 이것은 내가 버퍼를 축적 한 것이 "깨끗한"캐시이며, 필요할 때 리눅스가 즉시 드롭 할 수 있음을 증명한다. 이 시스템은 기록되지 않은 데이터를 축적하지 않습니다 . ( drop_caches쓰기를 수행하지 않으므로 더티 페이지를 삭제할 수 없습니다. 먼저 캐시를 정리 한 테스트를 실행하려면 sync명령을 사용하십시오 ).

전체 mysql 디렉토리는 150M입니다. 누적 버퍼는 mysql 쓰기의 메타 데이터 블록을 나타내야하지만이 데이터에 대해 너무 많은 메타 데이터 블록이 있다고 생각하면 놀랐습니다.

귀하의 버전에 free맞는 아이디어가 있습니다. 기본적으로 보고서에 버퍼와 캐시를 결합합니다. 기본적으로 같은 것이기 때문입니다. 둘 다 RAM (메모리 및 보조 스토리지 빠른 속도 : 디스크 및 SSD)을 기억하는 컴퓨터이며 디스크 및 SSD를 읽을 때 이미 본 것입니다.

운영 체제에서 메모리를 다른 용도로 사용하는 것이 더 좋다고 생각되면 사용 가능한 메모리를 확보 할 수 있습니다. 따라서 버퍼와 캐시에 대해 걱정하지 마십시오.

그러나 DVD를 시청하면 버퍼가 올라가서 다른 버퍼 / 캐시 컨텐츠를 제거 할 수 있습니다. 따라서 nocache를 사용하여 DVD 플레이어를 실행할 수 있습니다 ( 문제가 발생한 경우 ).