출력에서 "버퍼"를 어떻게 설명하거나 설명합니까 free?
$ 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
이 시스템에는 (알려진) 문제가 없습니다. 나는 "버퍼"가 "캐시"(155M 대 180M)만큼 높다는 사실에 놀랐고 궁금합니다. "캐시"는 파일 내용의 페이지 캐싱을 의미하며 "캐시/버퍼"에서 가장 중요한 부분인 경향이 있다고 생각합니다. "버퍼"가 무엇인지 잘 모르겠습니다.
예를 들어 RAM이 더 많은 노트북과 비교했습니다. 내 노트북에서 "버퍼" 숫자는 "캐시"보다 훨씬 작습니다(200M 대 4G). "버퍼"가 무엇인지 이해하면 더 작은 시스템에서 버퍼가 그토록 큰 비율로 증가하는 이유를 조사할 수 있습니다.
man proc(저는 "big"에 대한 오래된 정의를 무시하고 있습니다) :
버퍼%lu
원시 디스크 블록의 상대적 임시 저장 공간은 너무 커지면 안 됩니다(20MB 정도).
캐시%lu
디스크에서 읽은 파일에 대한 메모리 내 캐시(페이지 캐시)입니다. SwapCached는 제외됩니다.
$ free -V
free from procps-ng 3.3.12
$ uname -r # the Linux kernel version
4.9.0-6-marvell
$ systemd-detect-virt # this is not inside a virtual machine
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
- "버퍼"와 다른 유형의 캐시의 차이점은 무엇입니까?
- 이러한 구별이 왜 그렇게 눈에 띄는가? 파일 내용 캐싱에 대해 이야기할 때 일부 사람들이 "버퍼 캐시"라고 말하는 이유는 무엇입니까?
- 그것은 무엇을
Buffers위해 사용됩니까? 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. 이러한 구별이 그토록 두드러지는 이유는 무엇입니까? 파일 내용 캐싱에 대해 이야기할 때 일부 사람들이 "버퍼 캐시"라고 말하는 이유는 무엇입니까?
페이지 캐시는 일반적으로 최소 4096바이트인 MMU 페이지 크기 단위로 작동합니다. 이는 mmap()메모리 매핑된 파일 액세스에 중요합니다. [1][2] 별도의 프로세스 간에 로드된 프로그램/라이브러리 코드 페이지를 공유하고 요청 시 개별 페이지를 로드할 수 있도록 설계되었습니다. (다른 콘텐츠에 공간이 필요하고 최근에 사용되지 않은 경우 페이지를 언로드하는 데에도 유용합니다.)
[1]메모리 매핑된 I/O- GNU C 라이브러리 매뉴얼.
[2]mmap- 위키피디아.
초기 UNIX에는 디스크 블록의 "버퍼 캐시"가 있었지만 mmap()은 없었습니다. 분명히 mmap()이 처음 추가되었을 때 페이지 캐시를 맨 위에 새 레이어로 추가했습니다. 혼란스럽게 들립니다. 결국 UNIX 기반 운영 체제는 별도의 버퍼 캐시에서 멀어졌습니다. 이제 모든 파일 캐시는 페이지를 기반으로 합니다. 페이지는 디스크의 위치가 아닌 (파일, 오프셋)을 기준으로 조회됩니다. 이것을 "통합 버퍼 캐시"라고 합니다. 아마도 사람들이 "버퍼 캐시"에 더 익숙하기 때문일 것입니다. [삼]
[삼]UBC: NetBSD를 위한 효율적인 통합 I/O 및 메모리 캐시 하위 시스템
("Linux에서 추가된 흥미로운 변경 사항은 페이지가 저장된 디스크의 장치 블록 번호가 구조 목록 형식으로 페이지와 함께 캐시된다는 것입니다 buffer_head. 수정된 페이지가 디스크에 다시 기록될 때 I /O 요청은 장치 드라이버에 즉시 전송될 수 있으며, 페이지 데이터가 기록되어야 하는 위치를 결정하기 위해 간접 블록을 읽을 필요가 없습니다."[3])
Linux 2.2에는 쓰기를 위한 별도의 "버퍼 캐시"가 있지만 읽기를 위한 것은 없습니다. "페이지 캐시는 버퍼 캐시를 사용하여 데이터를 다시 쓰기 때문에 추가 데이터 복사본이 필요하고 일부 쓰기 로드에 대한 메모리 요구 사항이 두 배로 늘어납니다." [4] 세부 사항에 대해 너무 걱정할 필요는 없지만 이러한 기록은 BuffersLinux가 사용량을 별도로 보고하는 이유 중 하나일 수 있습니다.
[4]Linux 2.4 메모리 관리의 페이지 교체, 릭 반 리엘.
반면 Linux 2.4 이상에서는 추가 복사본이 존재하지 않습니다. "시스템은 페이지 캐시 페이지 사이에서 직접 디스크 IO를 수행합니다." [4] Linux 2.4는 2001년에 출시되었습니다.
3. Buffers용도는 무엇입니까?
블록 장치는 파일로 취급되므로 페이지 캐시가 있습니다. 이는 "파일 시스템 메타데이터 및 원시 블록 장치 캐싱"에 사용됩니다. [4] 그러나 현재 버전의 Linux에서는 파일 시스템이 이를 통해 파일 내용을 복사하지 않으므로 "이중 캐시"가 없습니다.
Buffers페이지 캐시의 일부는 Linux 버퍼 캐시라고 생각합니다 . 일부 출처에서는 이 용어에 동의하지 않을 수 있습니다.
파일 시스템이 사용하는 버퍼 캐시의 양(있는 경우)은 파일 시스템 유형에 따라 다릅니다. 문제의 시스템은 ext4를 사용합니다. ext3/ext4는 Linux 버퍼 캐시를 사용하여 로그, 디렉터리 내용 및 기타 메타데이터를 저장합니다.
일부 파일 시스템(ext3, ext4, ocfs2 포함)은 jbd 또는 jbd2 계층을 사용하여 물리적 블록 로깅을 처리하며, 이 계층은 기본적으로 버퍼 캐시를 사용합니다.
-- 이메일로 기사 보내기통과테드 조, 2013
Linux 커널 버전 2.4 이전에는 Linux에 별도의 페이지 캐시와 버퍼 캐시가 있었습니다. 2.4부터는 페이지 캐시와 버퍼 캐시가 통합되어
Buffers페이지 캐시에 표현되지 않는 원시 디스크 블록, 즉 파일 데이터가 아니다....
그러나 커널은 여전히 페이지가 아닌 블록 단위로 블록 I/O를 수행해야 하기 때문에 버퍼 캐시가 여전히 존재합니다. 대부분의 블록은 파일 데이터를 나타내므로 대부분의 버퍼 캐시는 페이지 캐시로 표현됩니다. 그러나 소량의 블록 데이터에는 파일 지원(예: 메타데이터 및 원시 블록 I/O)이 없으므로 버퍼 캐시로만 표시됩니다.
--한 쌍의 Quora 답변통과로버트 러브, 2013년에 마지막으로 업데이트되었습니다.
두 저자 모두 Linux 개발자이며 Linux 커널 메모리 관리 작업을 해왔습니다. 첫 번째 소스는 기술적인 세부 사항을 더 자세히 설명합니다. 두 번째 소스는 일부 세부 사항에서 모순되고 구식일 수 있는 보다 일반적인 요약입니다.
실제로 파일 시스템은 캐시가 페이지 인덱싱된 경우에도 부분 페이지 메타데이터 쓰기를 수행할 수 있습니다. 사용자 프로세스도 사용 중에 부분 페이지 쓰기를 수행할 수 있습니다 write()( 와는 반대로 mmap()). 적어도 블록 장치에 직접 쓰기는 가능합니다. 이는 읽기가 아닌 쓰기에만 작동합니다. 페이지 캐시를 읽을 때 페이지 캐시는 항상 전체 페이지를 읽습니다.
리누스는 포효하는 것을 좋아합니다블록 크기 쓰기를 수행하는 데 버퍼 캐시가 필요하지 않으며, 파일 시스템은 페이지 캐시가 블록 장치가 아닌 자체 파일에 연결되어 있어도 부분 페이지 메타데이터 쓰기를 수행할 수 있습니다. 나는 그가 ext2가 이것을 할 수 있다고 말하는 것이 옳다고 확신합니다. ext3/ext4 및 해당 로깅 시스템의 경우에는 그렇지 않습니다. 이 디자인의 원인이 무엇인지는 확실하지 않습니다. 그가 소리 지르던 사람들은 설명하는 데 지쳤습니다.
ext4_readdir()은 Linus의 호언장담을 만족시키기 위해 변경되지 않았습니다. 나는 또한 그가 다른 파일 시스템의 readdir()에서 사용하기를 원하는 방법을 볼 수 없습니다. 내 생각에는 XFS도 디렉토리에 버퍼 캐시를 사용하는 것 같습니다. bachefs는 readdir()의 페이지 캐시를 전혀 사용하지 않으며 자체 btree 캐시를 사용합니다. btrfs에 대해 잘 모르겠습니다.
Buffers4. 우리가 특별히 더 크게 또는 더 작게 성장하기 를 원하는 이유는 무엇입니까 ?
이 경우에는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입니다.)
btrace -w 10 /dev/sda데이터가 거의 읽혀지지 않으므로 blktrace()를 사용하여 캐시 중인 IO가 쓰기여야 하는지 확인합니다. 이것은 또한 mysqld유일한사용자 공간프로세스가 IO를 수행합니다.
쓰기(icinga2가 mysql에 쓰기)를 담당하는 서비스를 중지하고 다시 확인했습니다. "버퍼"가 20M 아래로 떨어지는 것을 확인했습니다. 이에 대한 설명은 없습니다. 그대로 유지합니다. 기록기를 다시 시작하면 10초 간격으로 약 0.1M씩 증가하는 "버퍼"가 표시됩니다. 나는 그것이 최대 70M 이상까지 이 속도를 유지하는 것을 관찰했습니다.
echo 3 | sudo tee /proc/sys/vm/drop_caches"버퍼"를 다시 4.5M로 낮추는 것만으로도 충분했습니다 . 이는 내가 축적한 버퍼가 "깨끗한" 캐시이고 Linux가 필요할 때 즉시 삭제할 수 있다는 것을 증명합니다. 이 시스템은 누적되지 않습니다.씌어 있지 않은데이터. ( drop_caches쓰기 저장이 수행되지 않으므로 더티 페이지를 삭제할 수 없습니다. sync캐시를 먼저 정리하는 테스트를 실행하려는 경우 이 명령을 사용할 수 있습니다.)
전체 mysql 디렉토리는 150M에 불과합니다. 누적 버퍼는 mysql이 작성한 메타데이터 청크를 나타내야 하는데 데이터에 너무 많은 메타데이터 청크가 있다는 사실에 놀랐습니다.
답변2
귀하의 버전에는 free올바른 아이디어가 있습니다. 기본적으로 보고서에는 버퍼링과 캐싱이 결합되어 있습니다. 이는 기본적으로 동일하기 때문입니다. 이는 모두 컴퓨터가 RAM(보조 저장소: 디스크 및 SSD보다 빠름)에 기억하는 것, 즉 디스크와 SSD를 읽을 때 이미 본 것입니다.
운영 체제가 메모리를 다른 용도로 사용하는 것이 더 좋다고 판단하면 해당 메모리를 해제할 수 있습니다. 따라서 버퍼와 캐싱에 대해 걱정하지 마세요.
그러나 DVD를 시청하면 버퍼가 증가하여 다른 버퍼/캐시 콘텐츠가 제거될 수 있습니다. 따라서 nocache를 사용하여 DVD 플레이어(문제가 발생한다면).