Какую долю памяти использует ядро Linux от установленной ОЗУ?
Давайте возьмем посмотрите определение границы слова:
Существуют три различных позиции, которые квалифицируются как границы слова:
- Перед первым символом в строке, , если первый символ является символом слова .
- После последнего символа в строке, если последний символ является символом слова.
- Между двумя символами в строке, где один является символом слова, а другой не является символом слова.
Никакая граница слова не может совпадать между символом, не являющимся словом, и тире, потому что тире также не является символом слова.
Также с тех пор, как, например, косые черты также не являются символами слов, и , поскольку у вас нет пробелов в путях , вместо сопоставления \ w * я бы более чувствителен к сопоставлению [ ^] * . Однако , поскольку вы также хотите исключить часть совпадения, grep не подходит для работы, если вы не используете версию grep , которая поддерживает PCRE:
printenv LIBS | grep -Po '(^| )-L[^ ]*'
% printenv LIBS | grep -Po '(^| )-L\K/[^ ]*'
/usr/lib
/lib
/usr/lib64
/usr/local/tools/vtk-6.1.0/lib
/g/g92/miguel/petsc-3.6.2/miguel-opt/lib
/usr/local/tools/openmpi-intel-1.8.4/lib
/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64
/usr/lib/gcc/x86_64-redhat-linux/4.4.7
/g/g92/miguel/code/libmesh_2D/lib
Однако это полагается на пути, не содержащие пробелов, и полагаться на пути, не содержащие тире, также неправильно.
Как правило, нет безопасного способа проанализировать эту строку.
Я предлагаю сохранять пути в массив вручную.
Если подумать, я предполагаю, что потенциальные пробелы в пути будут экранированы, чтобы путь был интерпретирован правильно?
Если это так, это будет безопасно:
printenv LIBS | grep -Po '(^| )-L\K\/.*?(?=([^\\] |$))'
% export LIBS='-L/path\ with\ spaces -L/another\ path\ with\ spaces'
% printenv LIBS | grep -Po '(^| )-L\K\/.*?(?=([^\\] |$))'
/path\ with\ space
/another\ path\ with\ spaces
В довольно старой (2006 г.) статье обсуждаются некоторые накладные расходы ядра, которые масштабируются с размером памяти: http://halobates.de/memorywaste. pdf
Из него:
структура страницы (отслеживает распределение страниц): 1,37%
таблицы страниц: 0,5%
Между тем, моя тестовая машина на 16 ГБ показывает общие накладные расходы в размере 4,3 %
, поэтому около 2% все еще не учтены. Таким образом, вопрос до сих пор не получил полного ответа, и ответ основан на очень старом ядре. Но это самое близкое, что я подошел к ответу на вопрос.
Короткий ответ на ваш вопрос: столько, сколько возможно, как только он дает процессам то, что они могут использовать. Альтернативой является оставление памяти свободной, что является расточительством. Машина с 16 ГБ не может использовать 12 ГБ сегодня, чтобы завтра использовать 20 ГБ. Любая память, не используемая в эту секунду, - это потенциал для экономии ввода-вывода и других усилий, который навсегда потерян - вы не можете сохранить память на потом.
Если вы думаете: "Но мне нужна свободная память сейчас, чтобы я мог использовать ее позже", выбросьте эту чушь из головы. Вы можете использовать ее сейчас и использовать ее позже. Здесь нет никакого компромисса. На самом деле, если вы используете его сейчас, вы можете использовать его позже, просто ничего не делая. Если вы не используете его сейчас, вам придется потрудиться, чтобы использовать его позже. Таким образом, если вы используете его сейчас, это повышает вероятность того, что вы будете использовать его позже.
Похоже, у вас сложилось неверное представление, что память может использоваться только процессом или накладными расходами ядра. Это не так. В типичной системе подавляющее большинство физической памяти не свободно, не используется процессами и не потребляется накладными расходами ядра.
Например, предположим, что в вашей системе много свободной памяти, и вы запускаете top, а затем выходите из системы. У вашей системы есть два варианта. Она может сохранить программу top в оперативной памяти или отбросить содержащие ее страницы. Давайте рассмотрим оба варианта:
Если она освобождает оперативную память, это требует усилий. И что еще хуже, это усилие нужно отменить, чтобы использовать оперативную память. И если вы снова запустите top, программу придется загружать с диска, что очень медленно.
Если он сохранит страницы в оперативной памяти, и вы снова запустите top, ему не придется загружать проблему с диска. Это огромный выигрыш. И если память понадобится для какой-то другой цели, она может перейти непосредственно к этой цели, не прибегая к усилиям по использованию памяти и удалению ее из свободного пула.
Таким образом, страницы оперативной памяти будут оставаться в использовании, удерживая исполняемый файл. Это использование не связано ни с каким процессом, поскольку top не запущен. Но это не бесплатно, так как содержит данные, которые могут быть полезны. И это не накладные расходы - если память окажется полезнее для чего-то другого, ее содержимое можно просто выбросить, поскольку исполняемый файл может быть перенесен с диска, если потребуется.
И, на самом деле, в типичной системе при типичной нагрузке подавляющее большинство памяти содержит информацию, которая может пригодиться в будущем, но может быть отброшена, если память понадобится для какой-либо другой цели.
Если вы смотрите на /proc/meminfo, то число, на которое вам, вероятно, следует обратить внимание, это MemAvailable. Оно объединяет как свободную память, так и память, содержащую информацию, которая может быть тривиально отброшена, если потребуется больше свободной памяти.
Ответ зависит от того, сколько памяти доступно вашему серверу при запуске ядра. При использовании раздувания памяти это основано на максимуме, до которого он может раздуваться.
Для ядра Linux 4.15:
- При 4 ГБ ОЗУ резервируется 4,8%
- 8 ГБ оперативной памяти :3,2%
- 16 ГБ ОЗУ :2,3%
- 32 ГБ оперативной памяти :1,9%
- 64 ГБ ОЗУ :1,7%
So why is there so much more kernel memory on the 16gb machine?
Относительно нет. Предполагая, что ваше число было правильным, вы видите, что 8,6% зарезервировано для 512 МБ и всего 2,3% для 16 ГБ.
Почему эти пропорции выбраны в ядре, я не знаю -от руки, но вы можете увидеть разрыв -в dmesg:
[ 0.000000] Memory: 65920612K/67108324K available (12300K kernel code, 2473K rwdata, 4272K rodata, 2408K init, 2416K bss, 1187712K reserved, 0K cma-reserved)