LINUX.ORG.RU

Последние Debian'ы и кэш в RAM


0

3

Последние Debian'ы начали при старте что-то кэшировать в RAM под полторы сотни Мб. Это точно кэш, а не память процессов или ядра. В ряде других мэйнстримовых дистрибутивов, включая CentOS, тоже, по ходу, что-то кэшируется при старте. В Slackware такого нет.

Это что вообще такое? Что происходит? Это как-то связано с внедрением в дистрибутивы systemd? А кэшируется оно даже при такой карте процессов, когда никаких компонентов systemd в системе нет вообще:

init─┬─acpid
     ├─dbus-daemon
     ├─dbus-launch
     ├─getty
     ├─ifup───sh───dhclient
     ├─irqbalance
     ├─rsyslogd─┬─{in:imklog}
     │          ├─{in:imuxsock}
     │          └─{rs:main Q:Reg}
     ├─udevd
     ├─xdm─┬─Xorg
     │     └─xdm───fvwm─┬─FvwmAuto
     │                  ├─ssh-agent
     │                  └─xclock
     └─xterm───bash───screen───screen─┬─bash───su───bash
                                      ├─bash───pstree
                                      └─4*[bash]

★★★★★
Ответ на: комментарий от menangen

top, smem,... и т.д., повторяю, показывают, что ни один процесс столько не жрёт, а по данным free это, по ходу, именно кэш:

# free
             total       used       free     shared    buffers     cached
Mem:       8177556     313344    7864212        560      18184     139400
-/+ buffers/cache:     155760    8021796
Swap:      4000180          0    4000180
Здесь столбец cached, по ходу, прибавляется к столбцу used. Другой вариант с другим ядром (конфиг взят из Slackware):
# free
             total       used       free     shared    buffers     cached
Mem:       8150012     273988    7876024        640      18528     117304
-/+ buffers/cache:     138156    8011856
Swap:      4000180          0    4000180
А вот это с тем же dbus'ом, но в Slackware:
# free
              total        used        free      shared  buff/cache   available
Mem:        8139924      108884     7573732        1012      457308     7657488
Swap:       4000180           0     4000180
init-+-acpid
     |-agetty
     |-at-spi-bus-laun-+-dbus-daemon
     |                 |-{dconf worker}
     |                 |-{gdbus}
     |                 `-{gmain}
     |-at-spi2-registr-+-{gdbus}
     |                 `-{gmain}
     |-atd
     |-cgmanager
     |-console-kit-dae-+-{gdbus}
     |                 |-{gmain}
     |                 |-{vt_thread_start}
     |                 `-{writer_thread_s}
     |-2*[dbus-daemon]
     |-dbus-launch
     |-dhcpcd
     |-gconfd-2
     |-gvfsd-+-{gdbus}
     |       `-{gmain}
     |-gvfsd-fuse-+-{gdbus}
     |            |-{gmain}
     |            |-{gvfs-fuse-sub}
     |            `-2*[{gvfsd-fuse}]
     |-klogd
     |-polkitd-+-{gdbus}
     |         |-{gmain}
     |         |-{polkitd}
     |         `-{runaway-killer-}
     |-screen---bash---bash---pstree
     |-syslogd
     |-udevd
     |-xdm-+-Xorg
     |     `-xdm---fvwm-+-FvwmAuto
     |                  `-xclock
     `-xterm---bash---screen

saahriktu ★★★★★
() автор топика
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Память, занятная кэшированными данными, библиотеками, бинарниками, прочим, в случае необходимости высвобождается.

Об этом не нужно беспокоиться. Если хочешь принудительно сбросить кэш, то в /proc есть ключ /proc/sys/vm/drop_caches. Хотя повторюсь смысла в этом нет.

kostik87 ★★★★★
()
Ответ на: комментарий от kostik87

Но, в Slackware-то даже при большем кол-ве процессов столбец used в 3 раза меньше. Поэтому для начала хотелось бы просто знать что именно происходит. Или это оптический обман от разных версий free?

32-х битный Debian на машине с 2 Гб RAM, кстати, ничего не кэширует. А 64-х битный на машине с 8 Гб RAM кэширует.

saahriktu ★★★★★
() автор топика
Последнее исправление: saahriktu (всего исправлений: 2)
Ответ на: комментарий от saahriktu

Но, в Slackware-то даже при большем кол-ве процессов столбец used в 3 раза меньше

Потому, что опции сборки пакетов у всех разные, разные версии компиляторов и опции оптимизации, есть, к примеру, оптимизации по скорости работы и оптимизации по размеру бинарников.

32-х битный Debian на машине с 2 Гб RAM, кстати, ничего не кэширует. А 64-х битный на машине с 8 Гб RAM кэширует.

Скорее всего, есть какой-то критерий по которому определяется кэшировать или нет данные, в зависимости от размера оперативной памяти.

Но я повторяю, cached - это не занятая память, она высвобождается, если системе потребуется оперативная память.

К примеру ты запускал какое-то приложение, оно подтянуло некоторые библиотеки, вот эти библиотеки в памяти и закэшированы, при запуске другого или этого же приложения, которому нужны эти библиотеки они не будут повторно считываться с диска, а будут доступны из кэша в оперативной памяти. Если системе будет не доставать свободной оперативной памяти, то кэш будет сброшен.

Так что повторяю, на cached можно внимания не обращать.

kostik87 ★★★★★
()
Ответ на: комментарий от anonymous

Возможно, но tmpfs занимает ровно столько места сколько занимают на ней файлы, даже если tmpfs -o size=2Gb, а занять 5Mb файлами, то выделено в памяти будет 5Мб.

Хотя, я думаю с вами поспорю, drop_caches не сбросит «кэш» tmpfs, так что, возможно, всё же tmpfs будет в used.

Если знаете подтверждение где будет учитывать tmpfs, то скиньте пожалуйста.

UPD:
Проверил, вы правы.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 1)

А ну-ка сделай free -m (гляди на buff/cache), потом что-то вроде c=`find`;for i in $c;do cat $i > /dev/null;done затем снова free -m и скажи нам, что у тебя стало с buff/cache

vblats
()
Ответ на: комментарий от h578b1bde

Я это знаю. Просто хотел понять что именно кэшируется. Вопрос в первую очередь именно про это.

Надо же понимать что происходит на машине.

saahriktu ★★★★★
() автор топика
Последнее исправление: saahriktu (всего исправлений: 1)

В какой-то из версий procps между 3.3.9 и 3.3.12 поменяли способ расчёта занятой памяти, отсюда и расхождения. Наткнулся на это при переходе на Debian 9. Вероятно там вывод будет аналогичен slackware.

Т. е. всё как кешировалось, так и кешируется, просто теперь free не считает память занятой.

NeOlip ★★
()
Последнее исправление: NeOlip (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.