Почему большинство людей рекомендуют уменьшить swappiness до 10-20?

Я видел на нескольких сайтах, которые рекомендуют уменьшить swappiness до 10-20 для лучшей производительности.

• http://community.linuxmint.com/tutorial/view/998
• https://sites.google.com/site/easylinuxtipsproject/bugs
• http://www.howtogeek.com/115797/6-ways-to-speed-up-ubuntu/
• http://www.upubuntu.com/2012/06/11-tips-to-speed-up-computers-running.html

Это миф или нет? Это общее правило? У меня есть ноутбук с 4 ГБ оперативной памяти и жестким диском на 128 ГБ, какое значение вы порекомендуете для моей замены?

Благодарю.

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

В целом настройки по умолчанию обеспечивают хорошую общую производительность и стабильность. Я бы рекомендовал оставить его по умолчанию. У Linux есть и другие способы улучшить управление памятью, чтобы решить некоторые крайние случаи, но в целом управление перестановкой не является хорошим обходным путем - отрегулируйте его в одном направлении, и вы можете исправить одну проблему и создать другие проблемы. Если это вообще возможно, простая установка дополнительной физической ОЗУ (и оставление подкачки в покое) затмевает все остальные меры.

Как Linux использует оперативную память

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

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

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

Как Linux использует своп

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

Это перераспределение не сделано в соответствии с определенным ограничением, хотя. Вы не достигаете определенного процента распределения, после которого Linux начинает меняться. Имеет «нечеткий» алгоритм. Принимается во внимание множество вещей, которые лучше всего можно описать как «насколько сильно давление для выделения памяти». Если существует большое «давление» для выделения новой памяти, то это увеличит шансы, что некоторые из них будут заменены, чтобы освободить место. Если будет меньше «давления», это уменьшит эти шансы.

Ваша система имеет настройку «swappiness», которая помогает вам настроить, как рассчитывается это «давление». Это часто ложно представляется как «процент оперативной памяти», но это не так, это просто значение, которое используется как часть формулы. Значения от 40 до 60 являются рекомендованными нормальными значениями, 60 в настоящее время являются значениями по умолчанию.

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

Что происходит, когда система перегружена и сильно перегружена?

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

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

А как насчет настольных систем? Разве они не требуют другого подхода?

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

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

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

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

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

Можно ли в любом случае отключить своп в системе с большим количеством оперативной памяти?

Если у вас гораздо больше ОЗУ, чем вам может понадобиться для приложений, то вам редко потребуется подкачка. Отключение свопа, вероятно, не будет иметь значения в большинстве случаев. Но если у вас достаточно оперативной памяти, то если оставить подкачку включенной, штраф не будет, потому что система не поменяется, когда это не нужно.

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

Но как обменяться может ускорить мою систему? Разве обмен не замедляет вещи?

Передача данных из ОЗУ в раздел подкачки является медленной операцией, но она выполняется только тогда, когда ядро ​​почти уверено, что общая выгода от сохранения разумного размера кэша перевесит это.

Когда данные в свопе, когда они выходят снова?

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

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

Существуют ли случаи, когда уместно сокращение перестановки?

Да. Если вы используете сервер, выделенный для одного конкретного серверного приложения, который не использует системный кеш. Некоторые серверы баз данных, такие как сервер Oracle, MySQL / MariaDB рекомендуют в некоторых случаях уменьшить перестановку до 1-10, поскольку эти механизмы баз данных используют свое собственное кэширование.

Обратите внимание, что это верно только в том случае, если ваша система предназначена для этой единственной задачи, а в случае MySQL / MariaDB - только если вы используете только InnoDB или XtraDB, а не MyISAM или Aria и т. Д.

На обычном рабочем столе у ​​вас есть 4-5 активных задач, которые занимают 50-60% памяти. Если вы установите swappiness на 60, то будет заменено около 1 / 4-1 / 3 страниц задач ACTIVE. Это означает, что для каждого изменения задачи, для каждой новой вкладки, которую вы открывали, для каждого выполнения JS будет происходить процесс обмена.

Решение состоит в том, чтобы установить swappiness на 10. По практическим наблюдениям, это приводит к тому, что система отказывается от дискового кэша ввода-вывода (который практически не играет роли на рабочем столе, поскольку кэш-память чтения / записи практически не используется вообще. Если только вы постоянно не копируете LARGE файлы) вместо того, чтобы что-то вставлять в своп. На практике это означает, что система откажется менять местами страницы, вместо этого сокращая кэш-память, если только она не достигнет 90% используемой памяти. А это, в свою очередь, означает беспроблемное, быстрое и удобное использование рабочего стола.

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

Однако на настольных компьютерах эта точная настройка приводит к замене блоков памяти РЕАЛЬНЫХ приложений, которые почти постоянно изменяют или получают доступ к этим данным.

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

Рабочий стол на самом деле не заботится о дисках, потому что рабочий стол редко читает и записывает в кеширование повторяющиеся большие порции данных. Обрезка на диске io для того, чтобы просто предотвратить как можно большую перестановку, гораздо более выгодна для настольных компьютеров, чем 30% оперативной памяти, зарезервированной для дискового кэша, с 30% оперативной памяти (заполненной блоками, принадлежащими активно используемым приложениям).

Просто запустите htop, откройте браузер, GIMP, LibreOffice - загрузите несколько документов и просматривайте их в течение нескольких часов. Это действительно так просто.

Если вы запускаете Java-сервер в своей системе Linux, вам действительно следует подумать о том, чтобы значительно уменьшить объем подкачки по сравнению со значением по умолчанию, равным 60. Таким образом, 20 действительно хорошее начало. Подкачка является убийцей для процесса сбора мусора, потому что каждый раз при сборе необходимо затрагивать большие части памяти процесса. Операционная система не имеет средств для обнаружения таких процессов и правильного их решения. Рекомендуется избегать перестановки настолько, насколько это возможно, для продуктивных серверов приложений.

Я бы предложил провести несколько экспериментов, пока системный монитор открыт, чтобы точно определить, насколько загружена ваша машина. Я также использую 4 ГБ памяти и твердотельный накопитель 128 ГБ, поэтому изменил значение перестановки на 10, что не только улучшило производительность под нагрузкой, но и под нагрузкой. в качестве бонуса также увеличится срок службы накопителя SSD, поскольку он пострадает меньше записей.

Для простого видеоурока о том, как это сделать с подробным объяснением, смотрите видео YouTube ниже

http://youtu.be/i6WihsFKJ7Q

Я хочу добавить некоторые соображения от инженера Big Data Performance, чтобы дать другим больше знаний о технологии 2017 года.

По моему личному опыту, хотя я обычно отключал подкачку, чтобы гарантировать, что мои системы работают на максимальной скорости, на моей рабочей станции для решения конкретной проблемы я обнаружил, что перестановка 1 и 10 приводит к зависанию (навсегда) и длительным паузам. Перестановка 80 для этого конкретного приложения приводит к гораздо лучшей производительности и более коротким паузам, чем по умолчанию (60). Обратите внимание, что у меня было 8 ГБ ОЗУ и 4x 256 ГБ подкачки, подкрепленные 1 HDD. Обычно я бы указывал точные статистические данные, которые можно увидеть в моих тестах и ​​полных технических характеристиках оборудования, но я еще этого не сделал, и это недавний бюджетный рабочий стол, который здесь не важен.

В моей прежней компании причина, по которой мы не включили перестановку на серверах Spark с узлами [от 500 ГБ до 4 ТБ] x [10-100], заключается в том, что мы рассматривали низкую производительность как признак изменения структуры конвейера данных и структур данных в более эффективную манера. Мы также не хотели сравнивать жесткие диски и твердотельные накопители. Кроме того, для замены такого большого объема ОЗУ потребуется 10-30 дисков на узел с параллельной записью, чтобы минимизировать время доступа к диску.

Сегодня, 20 лет назад и 20 лет в будущем, все еще будет оставаться тот факт, что некоторые проблемы слишком велики для оперативной памяти. С бесконечным временем и деньгами мы можем купить / арендовать больше оборудования или перепроектировать любой процесс, чтобы получить производительность до желаемого уровня. Обмен - это просто взлом, чтобы позволить нам игнорировать реальную проблему (у нас недостаточно оперативной памяти и мы не хотим тратить больше денег).

Для тех, кто думает, что более высокая перестановка - плохой совет, вот небольшая перспектива. В прошлом у HD было всего несколько килобайт кеша, если таковые имеются. Интерфейс был IDE / Parallel ATA. Шина процессора также была намного медленнее, наряду с оперативной памятью и многими другими вещами. Короче говоря, системы были очень медленными (по сравнению с сегодняшним днем) во всех отношениях. Пару лет назад жесткие диски использовали SATA3. Сегодня они используют протокол NVMe, который имеет значительные улучшения задержки. HD имеют много МБ кеша. И самое интересное - это когда вы используете современный SSD (гораздо более стабильный для чтения / записи и безупречную работу) с NVMe или PCIe в качестве хранилища подкачки. Это лучший компромисс между стоимостью и производительностью. Пожалуйста, не пытайтесь делать это с дешевыми или старыми твердотельными накопителями.

Своп + SSD-накопители! С высокопроизводительным энергозависимым хранилищем я бы настоятельно рекомендовал поэкспериментировать с высокой величиной перестановки. Это в основном зависит от шаблонов доступа к памяти (случайный доступ ко всей памяти по сравнению с редким доступом к большинству), использования памяти, если пропускная способность диска уже заполнена, и фактической стоимости перегрузки.

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