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?

У мене немає жодної (відомої) проблеми з цією системою. Мене тільки дивує і цікаво бачити, що "буфери" майже такі ж високі, як "кеш-пам'ять" (155М проти 180М). Я вважав, що "кеш" представляє кеш сторінок вмісту файлів, і, як правило, є найбільш значущою частиною "кешу / буферів". Мені менш зрозуміло, що таке "буфери".

Наприклад, я порівняв це зі своїм ноутбуком, який має більше оперативної пам’яті. На моєму ноутбуці цифра "буферів" на порядок менша, ніж "кеш" (200 М проти 4 Г). Якби я добре зрозумів, що таке "буфери", то я міг би почати запитувати, чому буфери можуть зростати до такої більшої частки в меншій системі.

man proc (Я ігнорую весело застаріле визначення "великий"):

Буфери% лу

Відносно тимчасове сховище для необроблених блоків дисків, які не повинні бути надзвичайно великими (20 Мб або більше).

Зберігає% лу

Кеш пам'яті для файлів, що читаються з диска (кеш сторінки). Не включає SwapCched.

$ 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] Введення / виведення на карту пам'яті - Посібник з бібліотеки GNU C.
[2] mmap- Вікіпедія.

Ранній UNIX мав "буфер кеш" дискових блоків, і не мав mmap (). Мабуть, коли mmap () було вперше додано, вони просто закрутили кеш сторінки поверх кеш-пам'яті буфера. Це так само безладно, як це звучить. Врешті-решт ОС на базі UNIX позбулася кеш-пам'яті. Отже, зараз весь кеш файлів знаходиться в одиницях сторінок. Сторінки переглядаються (файл, зсув), а не місце на диску. Це називалося "уніфікованим буферним кешем", можливо, тому, що люди були більш знайомі з "буферним кешем". [3]

[3] UBC: ефективна уніфікована підсистема кешування вводу / виводу та пам'яті для NetBSD

"Один цікавий поворот, який додає Linux, - це те, що номери блоків пристроїв, де зберігається сторінка на диску, кешуються сторінкою у вигляді списку buffer_headструктур. Коли змінена сторінка повинна бути записана на диск, введення / виведення запити можуть бути відправлені драйверам пристрою відразу, не потрібно читати жодних непрямих блоків, щоб визначити, куди слід писати дані сторінки. "[3]

У Linux 2.2 був окремий "буфер кеш", який використовується для запису, але не для читання. "Кеш сторінок використовував кеш-пам'ять буфера, щоб записувати свої дані, потребуючи додаткової копії даних і подвоєння вимог до пам'яті для деяких завантажень запису" (?). [4] Не будемо надто переживати про деталі, але ця історія була б однією з причин, чому Linux звітує про Buffersвикористання окремо.

[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 для обробки фізичного блоку, і цей шар принципово використовує кеш-буфер.

- Надіслати статтю по Ted Цо , 2013

До ядра Linux версії 2.4 Linux мав окремі кеші сторінок і буферів. Починаючи з 2.4, кеш сторінки та буфера є уніфікованими і Buffersявляє собою необроблені дискові блоки, не представлені в кеші сторінки, тобто не файлові дані.

...

Однак буфер кешу залишається, оскільки ядро ​​все ще повинно виконувати блок введення / виводу з точки зору блоків, а не сторінок. Оскільки більшість блоків представляють файлові дані, більшість кеш-пам'яті буфера представлено кешем сторінки. Але невелика кількість даних блоку не захищена файлами - наприклад, метадані та необмежений блок вводу / виводу - і, таким чином, представлена ​​виключно кеш-буфером.

- Пара відповідей Quora по Роберте Любов'ю , останнє оновлення 2013.

Обидва автори є розробниками Linux, які працювали з управлінням пам’яттю ядра Linux. Перше джерело більш конкретно стосується технічних деталей. Друге джерело - це більш загальне резюме, яке може суперечити і застарівати в деяких специфіках.

Це правда, що файлові системи можуть виконувати записи метаданих на часткових сторінках, навіть якщо кеш індексується на сторінках. Навіть користувацькі процеси можуть виконувати записи на часткових сторінках, коли вони використовують write()(на відміну від них mmap()), принаймні безпосередньо на блоковому пристрої. Це стосується лише записів, а не читання. Коли ви читаєте кеш сторінки, кеш сторінки завжди зчитує повні сторінки.

Лінусу подобалося вимовляти, що кеш-пам'ять буфера не потрібна для запису розміру в блоці, і що файлові системи можуть робити записи метаданих на часткових сторінках навіть із кешем сторінок, прикріпленим до власних файлів замість блокового пристрою. Я впевнений, що він має право сказати, що ext2 робить це. ext3 / ext4 зі своєю системою перекладу немає. Менш зрозуміло, які саме проблеми були причиною цієї конструкції. Люди, на яких він їхав, втомилися пояснювати.

ext4_readdir () не змінено, щоб задовольнити рент Лінуса. Я не бачу його бажаного підходу, який використовується також у readdir () інших файлових систем. Я думаю, що XFS також використовує кеш-буфер для каталогів. bcachefs взагалі не використовує кеш сторінок для readdir (); він використовує власний кеш для btrees. Я, можливо, щось не вистачає в btrfs.

4. Чому, Buffersзокрема, ми можемо очікувати, що вони будуть більшими чи меншими?

У цьому випадку виявляється, що розмір журналу ext4 для моєї файлової системи становить 128М. Отже, це пояснює, чому 1) мій буфер кеш може стабілізуватися на трохи більше 128 М; 2) буфер кеш-пам'яті пропорційно не масштабується з більшою кількістю оперативної пам’яті на моєму ноутбуці.

Про деякі інші можливі причини див. Що таке стовпчики буферів у виході з вільного? Зауважте, що "буфери", про які повідомляється, freeнасправді є комбінацією Buffersта відновлюваної пам'яті плат.

Щоб перевірити, що для запису журналу використовується кеш-буфер, я імітував файлову систему в хорошій швидкій оперативній пам’яті (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

Історія цієї відповіді: Як я прийшов подивитися журнал

Я знайшов електронну пошту Теда Ца в першому, і був заінтригований , що він підкреслив запис кешування. Мені було б дивно, якби «брудні», неписані дані змогли досягти 30% оперативної пам’яті в моїй системі. sudo atopпоказує, що протягом 10-секундного інтервалу система, про яку йдеться, послідовно записує лише 1 МБ. Зацікавлена ​​файлова система могла б підтримувати швидкість, що перевищує 100 разів. (Це на жорсткому диску USB2, максимальна пропускна здатність ~ 20 МБ / с).

Використання blktrace ( btrace -w 10 /dev/sda) підтверджує, що IO, які кешуються, повинні бути записаними, оскільки дані майже не читаються. Також mysqldце єдиний процес користувальницького простору, який робить IO.

Я зупинив службу, відповідальну за записи (icinga2, що пише в mysql) і повторно перевірив. Я побачив, як "буфери" опускаються до 20М - я не маю пояснень для цього - і залишаюся там. Перезапуск автору знову показує "буфери", що збільшуються на ~ 0,1 М за кожен інтервал 10 секунд. Я спостерігав, як він постійно підтримує цю швидкість, піднімаючись до рівня 70 млн і вище.

Біг echo 3 | sudo tee /proc/sys/vm/drop_cachesбув достатній, щоб знову опустити "буфери", до 4,5М. Це доводить, що моє накопичення буферів є "чистим" кешем, який Linux може негайно скинути, коли потрібно. Ця система не акумулює неписані дані. ( drop_cachesне виконує жодного запису, а отже, не може видалити брудні сторінки. Якщо ви хочете запустити тест, який спочатку очистив кеш, ви скористаєтеся syncкомандою)

Весь каталог mysql - це лише 150 мільйонів. Буфери, що накопичують, повинні представляти блоки метаданих із запису mysql, але мене це здивувало, думаючи, що для цих даних буде так багато блоків метаданих.

Ваша версія freeмає правильну ідею. За замовчуванням він поєднує буфери та кеш у своєму звіті. Це тому, що вони в основному те саме. Вони обидва комп'ютера запам'ятовують в оперативній пам'яті (Швидше, що вторинне сховище: диски та SSD), що вже було помічено під час читання диска та SSD.

Якщо операційна система відчуває, що пам'ять краще використовувати щось інше, вона може її звільнити. Тому не турбуйтеся про буфер і кеш.

Однак перегляд DVD-файлу може призвести до підйому буфера та вилучення іншого вмісту буфера / кешу. Тому ви можете використовувати nocache для запуску програвача DVD ( якщо це спричиняє проблеми ).