Почему подкачка использования, когда существует более чем достаточно свободного пространства в RAM?

Это поведение может быть настроено путем устанавливания значения:

/proc/sys/vm/swappiness

Значение по умолчанию равняется 60. Установка ее к 0 средствам никогда не использовать подкачку, когда существует все еще оставленная RAM и 100, выгружает память как можно скорее.

Изменить значение временно (потерянный на перезагрузке):

sudo sysctl vm.swappiness=10

Для изменения значения постоянно отредактируйте файл:

/etc/sysctl.conf

как корень (например. sudo nano /etc/sysctl.conf) и измените или добавьте (если не там) строку:

vm.swappiness

к требуемому значению. Если этот файл не существует (например, в Дуге Linux), то попробуйте /etc/sysctl.d/99-sysctl.conf вместо этого.

Были некоторые дебаты по тому, хороша ли выгрузка с доступной свободной памятью или плоха, но справка Ubuntu действительно рекомендует значение 10 для Настольных систем. См. также это учебное руководство на Цифровом Океане для CentOS.

Linux начинает подкачивать, прежде чем RAM заполнена. Это сделано для улучшения производительности и скорости отклика:

• Производительность увеличена, потому что иногда RAM лучше используется для дискового кэша, чем сохранить память программ. Таким образом, лучше выгрузить программу, это было неактивно некоторое время и вместо этого сохраняет часто используемые файлы в кэше.

• Скорость отклика улучшена путем выгрузки страниц, когда система неактивна, скорее чем, когда память полна, и некоторая программа выполняет и запрашивает больше RAM выполнить задачу.

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

Наличие более доступной памяти

Как все сказал, да, подкачка поможет Вам избавиться от неиспользованной памяти, таким образом, она сможет помочь Вам имеющий больше памяти в наличии.

Спящий режим

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

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

Недостатки

Всего хорошего, который когда-то подкачал данные процесса, мог быть считан в подкачке даже после завершения работы, если подкачка не была зашифрована (конечно).

Используя зашифрованную подкачку со спящим режимом не работает out-of-the-box со всеми дистрибутивами. Необходимо использовать постоянный ключ шифрования (некоторые установки случайным образом генерируют ключ шифрования области подкачки при каждой начальной загрузке), и initrd/initramfs для активации зашифрованного тома перед возобновлением.

Много современных программ основано на чрезмерно увеличенных в размерах платформах, которые притягивают много спама, в котором Вы на самом деле не нуждаетесь для запущения программы. Выгрузка тех неиспользованных страниц освобождает RAM для кэша и программ, которые могут на самом деле использовать RAM.

Я говорю от болезненного личного опыта здесь.

В прошлом году я переключил один из своих веб-сайтов к многообещающей новой платформе веб-сервера, которая была создана сверху Firefox. Может звучать странным создать систему серверной стороны сверху сфокусированной клиентами программы как Firefox, но это обладало некоторыми огромными преимуществами. Firefox очень мощен, предлагает некоторые действительно впечатляющие внутренние услуги, и он уменьшает несоответствие импеданса между сервером и клиентом, чтобы иметь обе рабочих подобных платформы.

Но существует оборотная сторона: Firefox является большим. Действительно большой. Это было видом версии 1.x проекта, таким образом, они не нашли время для вещей как удаление поддержки GUI. [*] Моему сайту не было нужно ни одно из этого, но потому что технология VPS, которую мой используемый поставщик услуг хостинга не позволил области подкачки, которую код GUI и все другие части Firefox я не использовал, съела реальную RAM. Я закончил тем, что нуждался в минимуме RAM на 512 МБ только для выполнения сайта без него отказывающий из-за исчерпания памяти. Если мой VPS имел некоторую область подкачки, я, вероятно, возможно, обошелся планом на 256 МБ.

[*] Удаление кода GUI от платформы даже не могло быть желательным, так как одно из преимуществ этой платформы было высокочастотной веб-очисткой, потому что серверная платформа могла загрузить веб-страницы с другого сайта, и Вы могли управлять ими так же, как Вы будете на стороне клиента. Думайте мэшапы. Много такой вещи повредилось бы, если Вы не можете "представить" веб-страницу в некотором графическом контексте.

Между прочим, эта веб-платформа чрезвычайно мертва теперь, таким образом, нет никакого смысла называть-и-позорить она. Лучше всего просто принимать более широкий урок близко к сердцу: да, подкачка все еще полезна, даже если у Вас есть концерты свободной RAM.

От Подкачки Ubuntu F.A.Q., что Marcel, связанный с

Как основной минимум, настоятельно рекомендовано, что область подкачки должна быть равной на сумму физической памяти (RAM). Кроме того, рекомендуется, чтобы область подкачки была дважды суммой физической памяти (RAM) в зависимости от суммы жесткого диска

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

Я думаю, что "Gilles" уже упомянул то, что, в то время как у Вас может быть более чем достаточно RAM, подкачка может быть полезной во время определенных "недостатков", а также постоянно сохраняющий некоторые данные даже после завершений работы - или является мной неправильно в принятии этого? (так как RAM спугивают после перезагрузок) я имею 12 ГБ в наличии RAM в моей системе, и я также обдумал об этом вопросе прежде. Однажды, когда я отключил всю подкачку и только полагался на мою RAM, у меня были крайне трудные события при попытке отладить некоторую системную ошибку или катастрофический отказ, и т.д. после завершений работы системы. С тех пор я повторно включил раздел подкачки.

Это старый пост, однако я все же позволю себе изложить здесь свои мысли.

Начиная снизу, Linux сначала делит память на страницы (обычно по 4 КБ на страницу в системе x86_64). После этого создается виртуальная память, отображение которой выполняется с физической памятью с помощью MMU (Memory Management Unit).

Процессам выделяется память из области виртуальной памяти, поэтому обратите внимание: когда вы видите / proc / meminfo, вы увидите VMalloc * в качестве сведений о виртуальной памяти.

Допустим, у вас есть процесс, который запрашивает память (скажем, 300 МБ - веб-браузер). Для процесса будет выделено 300 МБ из виртуальной памяти, однако нет необходимости, чтобы она отображалась в памяти (которая отображается в физическую память). Существует концепция «Копировать при записи» для управления памятью, согласно которой, если ваши процессы действительно используют память, выделенную из виртуальной памяти (то есть они делают некоторую запись в память), только тогда она отображается в физическую память. Это помогает ядру эффективно работать должным образом в многопроцессорной среде.

Что такое кеш?

Большой объем памяти, используемый процессами, является совместно используемым.Допустим, библиотека glibc используется почти всеми процессами. В чем смысл хранения нескольких копий glibc в памяти, когда каждый процесс может обращаться к одной и той же области памяти и выполнять свою работу. Такие часто используемые ресурсы хранятся в кеше, чтобы при запросе процессов они могли ссылаться на одну и ту же ячейку памяти. Это помогает ускорить процессы , поскольку повторное и повторное чтение glibc (и т. Д.) С диска потребует много времени.

Вышесказанное относится, скажем, к разделяемым библиотекам, то же самое верно и для чтения файлов. Если вы впервые читаете большой файл (скажем, 100-200 МБ), это займет много времени. Однако, если вы попытаетесь повторить то же самое чтение еще раз, это будет быстрее. Данные были кэшированы в памяти, и повторное считывание производилось не для всех блоков.

Что такое буфер?

Что касается буфера, когда процесс выполняет файловый ввод-вывод, он полагается на буфер ядра для записи данных на диск. Процессы запрашивают ядро ​​для выполнения работы. Итак, от имени процесса ядро ​​записывает данные в свой «буфер» и сообщает процессу, что запись выполнена. В асинхронном режиме ядро ​​будет синхронизировать эти данные в буфере с диском. Таким образом, процессы полагаются на то, что ядро ​​выберет правильное время для синхронизации данных с диском, и процессы могут продолжить работу. Помните, что это обычный ввод-вывод, выполняемый обычными процессами. Однако специализированные процессы, которым необходимо подтвердить, что ввод-вывод действительно выполняется на диске, могут использовать другой механизм для выполнения ввода-вывода на диске. Некоторые из утилит с открытым исходным кодом - libaio.Кроме того, есть способы вызвать явную синхронизацию с FD, открытыми в контексте вашего процесса, чтобы вы заставляли ядро ​​ синхронизировать данные с диском для той записи, которую вы, возможно, сделали.

В чем же тогда заключаются ошибки страниц?

Рассмотрим пример, когда вы запускаете процесс (скажем, веб-браузер), размер двоичного файла которого составляет около 300 МБ. Однако полные 300 МБ двоичного файла веб-браузера не начинают работать мгновенно. Процесс продолжает переходить от функций к функциям в своем коде. Как было сказано ранее, виртуальная память будет потребляться 300 МБ , однако не вся память отображается на физическую (резидентная память RSS будет меньше, см. Верхний вывод). Когда выполнение кода достигает точки, для которой память фактически не отображается, возникает ошибка страницы . Ядро будет отображать эту память на физическую, связывать страницу памяти с вашим процессом. Такая ошибка страницы называется "Minor Page Faults". Точно так же, когда процесс выполняет файловый ввод-вывод, возникают серьезные ошибки страницы.

Когда и почему происходит Swap Out?

Ситуация 1:

В соответствии с приведенными выше подробностями, давайте рассмотрим сценарий, когда достаточный объем памяти становится отображаемым в память. И теперь запускается процесс , которому требуется память. Как обсуждалось выше, ядру потребуется выполнить некоторую привязку к памяти. Однако для отображения памяти недостаточно физической оперативной памяти . Теперь ядро ​​сначала заглянет в кеш, у него будут старые страницы памяти, которые не используются. Оно сбросит эти страницы в отдельный раздел (называемый SWAP), освободит некоторые страницы и отобразит освободили страницы для приходящего нового запроса. Поскольку запись на диск происходит намного медленнее, чем в твердотельном ОЗУ, этот процесс занимает много времени, и, следовательно, наблюдается замедление.

Ситуация 2:

Допустим, вы видите много свободной памяти, доступной в системе. Даже тогда вы видите, что происходит много подмен.Возможная проблема - фрагментация памяти. Рассмотрим процесс, которому от ядра требуется 50 МБ непрерывной памяти. (имейте в виду смежные). Очевидно, что ядро ​​произвольно выделило бы страниц для разных процессов и освободило бы некоторые из них. Однако, когда нам требуется непрерывная память, ей придется искать фрагмент , который удовлетворяет потребности процессов. Если он не может получить такую ​​память, ему придется выполнить подкачку некоторых старых страниц памяти, а затем выделить смежных. Даже в таких случаях SWAP произойдет. Начиная с версии ядра 2.6 и выше, такие проблемы фрагментации значительно уменьшились. Однако, если система работает в течение длительного времени, такие проблемы все равно могут возникнуть.

См. Этот пример ( вывод vmstat )

2016-10-29 03:55:32 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
2016-10-29 03:55:32  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
2016-10-30 03:56:04 19 23 2914752 4692144 3344908 12162628 1660    1  8803 12701 4336 37487 14  7 40 38  0
2016-10-30 03:56:34  3 20 2889296 4977580 3345316 12026752 2109    2  8445 14665 4656 36294 12  7 46 34  0
2016-10-30 03:57:04  1 11 3418868 4939716 3347804 11536356  586 4744  2547  9535 3086 24450  6  3 59 33  0  <<<-----
2016-10-30 03:57:34  3 19 3456252 5449884 3348400 11489728 3291 13371  6407 17957 2997 22556  6  4 66 24  0
2016-10-30 03:58:04  7  6 4194500 5663580 3349552 10857424 2407 12240  3824 14560 2295 18237  4  2 65 29  0
2016-10-30 03:58:34  2 16 4203036 5986864 3348908 10838492 4601 16639  7219 18808 2575 21563  6  4 60 31  0
2016-10-30 03:59:04  3 14 4205652 6059196 3348760 10821448 6624 1597  9431  4357 1750 20471  6  2 60 31  0
2016-10-30 03:59:34  2 24 4206968 6053160 3348876 10777216 5221 2067 10106  7377 1731 19161  3  3 62 32  0
2016-10-30 04:00:04  0 13 4205172 6005084 3348932 10785896 6236 1609 10330  6264 1739 20348  4  2 67 26  0
2016-10-30 04:00:34  4 11 4206420 5996396 3348976 10770220 6554 1253 10382  4896 1964 42981 10  5 58 27  0
2016-10-30 04:01:04  6  4 4177176 5878852 3348988 10825840 8682  765 10126  2716 1731 32949  8  4 69 19  0

@ 2016-10-30 03:57:04, мы видим, что все еще доступно достаточное количество свободной оперативной памяти. Однако даже тогда своп произошел. Мы проверили дерево процессов на этом этапе и не обнаружили ни одного процесса, который требовал бы такого большого количества памяти (больше, чем свободная память). Очевидным подозрением является описанная выше Ситуация 2. Мы проверили журналы buddyinfo и zoneinfo выше (используйте echo m> / proc / sysrq-trigger, чтобы проверить их, вывод попадает в системные журналы).

Для нашей нормальной системы сравнение информации о зоне происходит так. И графики для кеша / свободной / низкой памяти также упомянуты ниже

Глядя на информацию, становится ясно, что там - это фрагментация памяти в узле 0 и узле 1 нормально (узел - это машина на основе NUMA, следовательно, несколько узлов (см. numactl, чтобы проверить информацию для вашей системы)).

Фрагментация памяти также является причиной увеличения использования подкачки даже при наличии свободной памяти.

Рекомендация о том, что пространство подкачки должно в два раза превышать объем физической памяти (ОЗУ ), больше не обновляется https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-swapspace#tb-recommended-system-swap-space, но верна только для небольшого объема памяти в системе.