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

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

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

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

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

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

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

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

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

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

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

http://youtu.be/i6WihsFKJ7Q

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

Я хочу добавить некоторую перспективу от инженера по работе с большими данными, чтобы дать другим больше информации о технологиях 2017.

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

Вернувшись к моей прежней компании, причина, по которой мы не разрешали swappiness на серверах Spark с узлами [500GB to 4TB] x [10-100], заключалась в том, что мы увидели слабую производительность в качестве знака для перепроектирования конвейера данных и структуры данных более эффективным образом. Мы также не хотели тестировать HDD / SSD. Кроме того, для замены большого количества оперативной памяти потребуется 10-30 дисков на узел с параллельной записью, чтобы минимизировать время доступа к диску.

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

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

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