Свободна ли «кэшированная» память де-факто?

Question

Свободна ли «кэшированная» память де-факто?

Я воспользовался возможностью, чтобы улучшить свои навыки работы с bash, и придумал следующее:

#!/bin/bash

maxx=0
maxy=0

# find largest dimension
for file in *.jpg ; do
  dim=$(identify "$file" | awk '{ print $3 }')
  xdim=$(echo $dim | cut -f1 -dx)
  ydim=$(echo $dim | cut -f2 -dx)
  if [ $xdim -gt $maxx ] ; then
    maxx=$xdim
  fi
  if [ $ydim -gt $maxy ] ; then
    maxy=$ydim
  fi
done

mkdir bordered

# resize and store new images in new folder
for file in *.jpg ; do
  dim=$(identify "$file" | awk '{ print $3 }')
  xdim=$(echo $dim | cut -f1 -dx)
  ydim=$(echo $dim | cut -f2 -dx)

  xborder=$(( ($maxx - $xdim ) / 2 ))
  yborder=$(( ($maxy - $ydim ) / 2 ))

  convert "$file" -bordercolor black -border ${xborder}x${yborder} "bordered/$file"

done

Это должно помочь: сначала выполняется цикл по всем файлам (изменение в соответствии с вашими потребностями), чтобы найти наибольшую ширину и высоту, а затем цикл еще раз, чтобы добавить необходимые границы (измените часть -bordercolor black в соответствии с вашими потребностями). Новые файлы хранятся в папке с «рамкой».

10

linux memory cache meminfo

ilkkachu 10.02.2019, 12:03

Ссылка

2 ответа

1. Доступные детали памяти

Как сказано выше, tmpfs и другую Shmemпамять нельзя освобождать, только перемещать в своп. Cachedв /proc/meminfoможет ввести в заблуждение из-за включения этой сменной Shmemпамяти. Если у вас слишком много файлов в tmpfs, это может занимать много памяти :-). Shmemможет также включать некоторые распределения графической памяти , которые могут быть очень большими.

MemAvailableпреднамеренно не включает сменную память. Слишком большой обмен может привести к длительным задержкам. Возможно, вы даже выбрали запуск без пространства подкачки или разрешили только относительно ограниченное количество.

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

/*
 * Not all the page cache can be freed, otherwise the system will
 * start swapping. Assume at least half of the page cache, or the
 * low watermark worth of cache, needs to stay.
 */
pagecache = pages[LRU_ACTIVE_FILE] + pages[LRU_INACTIVE_FILE];
pagecache -= min(pagecache / 2, wmark_low);
available += pagecache;

Однако я обнаружил, что он корректно рассматривает Shmemкак "используемую" память. Я создал несколько файлов размером 1 ГБ в файле tmpfs. Каждое увеличение Shmemна 1 ГБ уменьшает MemAvailableна 1 ГБ. Таким образом, размер «списков файлов LRU» не включает общую память или любую другую память с возможностью замены. (Я заметил, что эти же счетчики страниц также используются в коде, вычисляющем «грязный лимит»).

Этот MemAvailableрасчет также предполагает, что вы хотите сохранить по крайней мере достаточно файлового кэша, чтобы соответствовать «низкому уровню» ядра. Или половину текущего кеша -, в зависимости от того, что меньше. (То же предположение делается и для восстанавливаемых плит ). «Нижний водяной знак» ядра можно настроить, но обычно он составляет около 2% оперативной памяти системы . Поэтому, если вам нужна только приблизительная оценка, вы можете игнорировать эту часть :-).

Когда вы работаете firefoxс примерно 100 МБ программного кода, отображенного в кэше страниц, вы обычно хотите сохранить эти 100 МБ в ОЗУ :-).В противном случае в лучшем случае вы будете страдать от задержек, в худшем — система будет тратить все свое время на метания между разными приложениями. Поэтому MemAvailableвыделяет для этого небольшой процент оперативной памяти. Это может быть недостаточно или может быть чрезмерно -щедрым. «Воздействие этих факторов будет варьироваться от системы к системе».

Для многих рабочих нагрузок ПК пункт о «много файлов» может не иметь значения. Несмотря на это, в настоящее время на моем ноутбуке (имеется 500 МБ восстанавливаемой памяти из 8 ГБ ОЗУ ). Это связано сext4_inode_cache(более чем 300 тыс. объектов ). Это произошло из-за того, что мне недавно пришлось сканировать всю файловую систему, чтобы найти то, что использует мое дисковое пространство :-). Я использовал команду df -x / | sort -n, но, например. Анализатор использования диска Gnome сделает то же самое.

2. [править] Память в группах управления

Так называемые -«контейнеры Linux» состоят из namespaces, cgroupsи различных других функций по вкусу :-). Они могут обеспечить достаточно убедительную среду для запуска чего-то почти похожего на полноценную систему Linux. Услуги хостинга могут создавать такие контейнеры и продавать их как «виртуальные серверы» :-).

Хостинг-серверы также могут создавать «виртуальные серверы» с использованием функций, которых нет в основной версии Linux. Контейнеры OpenVZ предшествуют -основным контрольным группам на два года и могут использовать «beancounters» для ограничения памяти. Таким образом, вы не сможете точно понять, как работают эти ограничения памяти, если вы только читаете документы или задаете вопросы об основном ядре Linux.cat /proc/user_beancountersпоказывает текущее использование и ограничения.vzubcпредставляет его в несколько более удобном формате. Главная страница на beancounters документирует имена строк.

Группы управления включают возможность устанавливать ограничения памяти для процессов внутри них. Если вы запустите свое приложение внутри такой контрольной группы, то не вся системная память будет доступна приложению :-). Итак, как мы можем увидеть доступную память в этом случае?

Интерфейс для этого отличается несколькими способами, в зависимости от того, используете ли вы cgroup -v1 или cgroup -v2 .

При установке на моем ноутбуке используется cgroup -v1. Я могу бежать cat /sys/fs/cgroup/memory/memory.stat. Файл показывает различные поля, включая total_rss, total_cache, total_shmem. shmem, включая tmpfs, учитывает ограничения памяти. Я думаю, вы можете рассматривать total_rssкак обратный эквивалент MemFree. А еще есть файл memory.kmem.usage_in_bytes, представляющий память ядра, включая slabs. (Я предполагаю, что memory.kmem.также включает memory.kmem.tcp.и любые будущие расширения, хотя это явно не задокументировано ). Отдельных счетчиков для просмотра восстанавливаемой slab памяти нет. В документе для cgroup -v1 говорится, что превышение лимита памяти не вызывает освобождение какой-либо плиты памяти. (В документе также содержится предупреждение о том, что он «безнадежно устарел», и вам следует проверить текущий исходный код ).

cgroup -v2 отличается. Я думаю, что cgroup корневого (верхнего -уровня )не поддерживает учет памяти. cgroup -v2 все еще имеет файл memory.stat. Все поля суммируются по дочерним контрольным группам, поэтому вам не нужно искать поля total_.... Есть поле file, что означает то же самое, что и cache. Досадно, что я не вижу общего поля, такого как rssвнутри memory.stat; Я думаю, вам придется добавить отдельные поля. Существуют отдельные статистические данные для восстанавливаемой и невосстановимой slab-памяти; Я думаю, что контрольная группа v2 предназначена для восстановления блоков, когда ей начинает не хватать памяти.

Контрольные группы Linux не виртуализируют автоматически/proc/meminfo(или любой другой файл в /proc), поэтому значения будут отображаться для всей машины. Это может запутать клиентов VPS. Однако можно использовать пространства имен для замены /proc/meminfoфайлом , сфальсифицированным специальным программным обеспечением контейнера . Насколько полезны поддельные значения, будет зависеть от того, что делает это конкретное программное обеспечение.

systemdсчитает, что cgroup -v1 нельзя безопасно делегировать, например. к контейнерам. Я заглянул внутрь контейнера systemd-nspawnв моей системе cgroup -v1. Я вижу контрольную группу, в которую он был помещен, и учет памяти. С другой стороны, содержащийся systemdне устанавливает обычные cgroups для -сервисов для учета ресурсов. Если бы учет памяти не был включен внутри этой контрольной группы, я предполагаю, что контейнер не сможет его включить.

Я предполагаю, что если вы находитесь внутри контейнера cgroup -v2, он будет выглядеть иначе, чем корень реальной системы cgroup -v2, и вы сможете увидеть учет памяти для его вершины -контрольная группа уровня. Или, если в контрольной группе, которую вы видите, не включен учет памяти, надеюсь, вам будет делегировано разрешение, чтобы вы могли включить учет памяти вsystemd(или эквивалентном ).

Mikko Rantalainen · Answer 2 · 30.08.2021, 06:54

В современных ядрах Linux и /proc/meminfoзначение Cachedвключает в себя все Shmem, а также все использование tmpfs, поэтому де-факто -определенно не бесплатно для программ, которые они могут использовать при необходимости. По моему опыту, Cached - Shmemдовольно хорошо соответствует фактически освобождаемой памяти. Обратите внимание, что ни один из Shmemне может быть освобожден без уничтожения процессов, но его можно поменять местами, если памяти становится мало.

Я бы рекомендовал проверить эти значения (вывод моего примера):

$ grep -E "^MemTotal|^Cached|^Committed_AS|^Shmem:|^MemAvailable|^MemFree" /proc/meminfo 
MemTotal:       32570668 kB
MemFree:         8245572 kB
MemAvailable:    7817776 kB
Cached:         11553648 kB
Shmem:          10604700 kB
Committed_AS:   36945628 kB

Также обратите внимание, что мой MemAvailableменьше, чем MemFree, потому что часть памяти оценивается как фрагментированная и не может быть напрямую использована с полной производительностью.

Другую оценку вашего действительно свободного Cachedможно найти следующим образом:

$ sudo slabtop -sc -o | head | grep "Total Size"
 Active / Total Size (% used)       : 548703.26K / 672516.95K (81.6%)

Обратите внимание, что в моем случае около 550 МБ активно используются, и их освобождение приведет к падению производительности системы.

TL;DR:Не смотрите на Freeили Cached, потому что эти имена вводят в заблуждение относительно их истинной цели, просто посмотрите на MemAvailable, это объем оперативной памяти, который вы можете позволить себе потратить больше, если это необходимо..

Свободна ли «кэшированная» память де-факто?

1. Доступные детали памяти

2. [править] Память в группах управления

Теги

Похожие вопросы