Чому більшість людей рекомендують зменшити скупость до 10-20?


65

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

Це міф чи ні? Це загальне правило? У мене ноутбук з 4 ГБ оперативної пам’яті та 128 ГБ жорстким SSD, яке значення ви рекомендуєте для моєї простоти?

Дякую.


5
На цих веб-сайтах, які ви перераховуєте, не пояснюється, чому вони рекомендують змінити типовий режим. Відповіді тут набагато кращі для цього хитрого вибору складного питання.
nealmcb

Відповіді:


88

Тому що більшість вважає, що заміна = погана, і якщо ви не зменшите свопп, система буде міняти місцями, коли цього насправді не потрібно. Жодне з них не є правдою. Люди пов'язують обмін із часом, коли їхня система забуває - однак, це в основному відбувається обмін, тому що система забивається, а не навпаки. Коли система обміняється, вона вже врахувала вартість продуктивності до свого рішення про обмін, і вирішила, що не робити цього буде мати більшу загальну пеню в продуктивності або стабільності системи.

В цілому налаштування за замовчуванням призводять до хорошої загальної продуктивності та стабільності. Я рекомендую залишити його за замовчуванням. Є додаткові шляхи для Linux, щоб покращити управління пам’яттю для вирішення деяких кращих випадків, але за великим рахунком контроль заміщення не є хорошим вирішенням - налаштуйте його в одному напрямку, і ви можете виправити одну проблему та створити інші проблеми. Якщо це взагалі можливо, просто встановлення більшої кількості фізичної оперативної пам’яті (і залишення простоти в спокої) затьмарює всі інші засоби захисту.

Як Linux використовує оперативну пам’ять

Будь-яка ОЗУ, яка не використовується додатками, може використовуватися як "кеш". Кеш важливий для швидкої, плавної роботи системи, що прискорює читання та запис на диск.

Якщо ваші додатки збільшать обсяг пам’яті до того часу, в якому вони використовують майже всю вашу оперативну пам’ять, ваш кеш скоротиться, і в середньому операції з диском уповільниться в результаті. Зараз недостатньо лише десятків мегабайт або менше для кешу.

Якщо додатки ще більше збільшують обсяг пам’яті - якщо припустити, що у вас немає місця для заміни - у вас не тільки не буде місця для кешу, але ви зрештою втрачаєте пам’ять, і вашій системі доведеться вбивати запущені процеси. Процеси вбивства гірші, ніж уповільнення, оскільки вони дають вам нестабільну, непередбачувану систему.

Як Linux використовує своп

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

Це перерозподіл не проводиться відповідно до певного обмеження. Ви не досягаєте певного відсотка розподілу, після якого Linux починає мінятися. Він має "нечіткий" алгоритм. Це враховує багато речей, які найкраще можна охарактеризувати «скільки тиску існує для розподілу пам’яті». Якщо є багато «тиску» для виділення нової пам’яті, то це збільшить шанси на те, що деякі будуть помінятися, щоб звільнити більше місця. Якщо "тиск" буде меншим, то це знизить ці шанси.

У вашій системі встановлено функцію "простоти", яка допоможе вам налаштувати, як обчислюється цей "тиск". Він часто помилково представлений як "відсоток оперативної пам'яті", але це не так, це просто значення, яке використовується як частина формули. Значення приблизно від 40 до 60 є рекомендованими здоровими значеннями, 60 зараз є типовими.

Дозволяти вашій системі поміняти місцями, коли це потрібно, - це дуже гарна річ, навіть якщо у вас багато оперативної пам’яті. Дозволяючи вашій системі поміняти місцями, якщо це потребує душевного спокою, що якщо ви коли-небудь стикаєтесь із ситуацією з низькою пам’яттю навіть тимчасово (під час короткого процесу, що використовує багато пам’яті), у вашої системи є другий шанс зберегти все, що працює. Якщо ви підете так далеко, щоб повністю відключити заміну, то ви ризикуєте вбити процеси через те, що не зможете виділити пам'ять.

Що відбувається, коли система замикається та сильно змінюється?

Заміна - це повільна і дорога операція, тому система уникає цього, якщо не розрахує, що компроміс у кеш-пам'яті буде компенсувати її в цілому, або якщо це потрібно, щоб уникнути процесів вбивства.

Багато часу люди будуть дивитись на свою систему, яка сильно обмолочує диск і використовує багато місця для обміну і звинувачує в цьому. Це неправильний підхід. Якщо заміна коли-небудь досягає цієї крайності, це означає, що заміна - це спроба вашої системи вирішити проблеми з низькою пам’яттю, а не причиною проблеми, і що без заміни вашого запущеного процесу просто випадково загине.

Що з настільними системами? Чи не вимагають вони іншого підходу?

Користувачі настільної системи дійсно очікують, що система "почує себе чуйною" у відповідь на ініційовані користувачем дії, такі як відкриття програми, який є типом дій, який іноді може викликати заміну через збільшення необхідної пам'яті.

Один із способів, який деякі люди намагаються налаштувати, це зменшити параметр zamppiness, що може підвищити толерантність системи до додатків, використовуючи пам'ять і втрачаючи мало місця в кеші.

Однак це лише зміщення воріт. Перша програма тепер може завантажуватися без операції swap, але вона залишить меншою слабкість для наступного завантаження. Ця ж заміна може статися пізніше, коли ви наступного разу відкриєте програму. Тим часом продуктивність системи знижується в цілому через зменшений розмір кешу. Таким чином, будь-яку вигоду від налаштування зменшеної затишності може бути важко виміряти, зменшуючи затримку заміни на деякі моменти, але викликаючи інші повільні показники в інший час. Трохи зменшити свобідність, можливо, виправдано, якщо ви знаєте, що ви робите, але зменшення його до 10% може залишити систему толерантною до дуже малих розмірів кешу і залишити систему більш підданою заміні за короткий час.

Повністю слід уникати відключення swap, оскільки ви втрачаєте додатковий захист від умов пам'яті, які можуть спричинити збій або загибель процесів.

На сьогоднішній день найбільш ефективним засобом є встановлення більшої кількості оперативної пам’яті, якщо ви можете собі це дозволити.

Чи можна відключити заміну в системі, яка має багато оперативної пам’яті?

Якщо у вас набагато більше оперативної пам’яті, ніж ви, швидше за все, знадобиться для додатків, вам рідко знадобиться своп. Відключення swap, ймовірно, не змінить більшість часу. Але якщо у вас є багато оперативної пам’яті, за умови активації swap також не буде штрафу, оскільки система не заміняється, коли цього не потрібно.

Єдиними ситуаціями, в яких це змінило б, було б малоймовірна ситуація, коли система втрачає пам'ять, і, отже, кеш-система перешкоджає, і саме в такому типі ситуацій, де ви б хотіли найбільше обмінятися. Таким чином, ви можете спокійно залишити своп у звичайних налаштуваннях для додаткового спокою, без негативного впливу, коли у вас буде багато пам’яті.

Але як своп може пришвидшити мою систему? Чи не міняє повільні речі?

Акт передачі даних з оперативної пам’яті на своп - це повільна операція, але вона приймається лише тоді, коли ядро ​​впевнене, що загальна вигода в результаті збереження розумного розміру кешу перевершить це.

Коли дані перебувають у свопі, коли вони знову з’являються?

Будь-яка частина пам’яті повернеться із заміни, як тільки вона буде використана - прочитана або написана на. Однак, як правило, пам'ять, до якої поміняється, - це пам'ять, до якої не було доступно протягом тривалого часу, і, як очікується, вона не буде потрібна незабаром.

Передача даних із свопу - це забирає багато часу, як і їх розміщення. Ваше ядро ​​не видалить дані з нього, якщо цього не потрібно. Хоча дані знаходяться в обміні і не використовуються, це залишає більше пам'яті для інших речей, які використовуються, і більше системного кешу.

Чи існують випадки, коли зменшення свобідності доцільно?

Так. Якщо ви використовуєте сервер, призначений для одного конкретного серверного додатку, який не має вигоди від кеш-системи. Деякі сервери баз даних, такі як сервер Oracle, MySQL / MariaDB, рекомендують в деяких випадках зменшувати простоту до 1 до 10, оскільки ці двигуни бази даних використовують власне кешування.

Зауважте, що це справедливо лише в тому випадку, якщо ваша система присвячена цьому одному завданню, а у випадку MySQL / MariaDB лише якщо ви використовуєте суто InnoDB або XtraDB, а не MyISAM чи Aria тощо.


Дякуємо за ваш ретельний опис. Я думаю, що в моєму випадку (4 ГБ оперативної пам’яті та 128 ГБ жорсткого SSD) та при моєму використанні (розробка Java EE та декілька ОС у життєвій коробці) підмінність = 20 підходить. Що ти думаєш?
Саїд Зарінфам

Я думаю, що за замовчуванням 60, на мій погляд, було б найкращим.
thomasrutter

4
@BlancaHiggins Ви читали публікацію, яку ви прокоментували? Ваш коментар, схоже, не описує, що насправді робить свобідність.
thomasrutter

1
Це відмінна відповідь. Дуже дякую за таке чудове пояснення.
Ден Баррон

2
Частина інформації в SwapFaq, на мою думку, вводить в оману: якщо встановити його на 100, буде "агресивно" міняти місцями. Я вважаю, що точніше сказати, що це дуже обережна, активна установка, що змінюється при перших ознаках того, що наявна пам'ять чи кеш-пам'ять стають ще трохи зниженими. Тоді як низькі налаштування, як-то 10, є більш ризикованим, захоплюючим настроєм, уникаючи будь-яких змін, поки наявна пам'ять не буде дуже низькою, а кеш-пам'ять майже повністю втрачена, залишаючи систему без особливого вимруження.
thomasrutter

14

На звичайному робочому столі у вас 4-5 активних завдань, які займають 50-60% пам'яті. Якщо встановити заміщення на 60, тоді приблизно 1 / 4-1 / 3 АКТИВНИХ сторінок завдань буде замінено. Це означає, що для кожної зміни завдання, для кожної нової вкладки, яку ви відкрили, для кожного виконання JS відбудеться процес заміни.

Рішення полягає в тому, щоб встановити свобідність на 10. За допомогою практичних спостережень це призводить до того, що система відмовиться від кеш-дискового іо кешу (що на робочому столі не грає жодної ролі, оскільки кеш читання / запису практично не використовується. Якщо ви постійно не копіюєте ВЕЛИКЕ файли) замість того, щоб щось підштовхувати до swap. На практиці це означає, що система відмовиться обмінюватися сторінками, скорочуючи кеш іо, якщо тільки це не набере 90% використовуваної пам'яті. А це в свою чергу означає плавний, швидкий досвід роботи на робочому столі.

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

На робочих столах, однак, ця точна настройка призводить до заміни блоків пам'яті програм REAL, які поруч постійно змінюють або отримують доступ до цих даних.

Як не дивно, браузери часто залишають великі шматки пам'яті, які вони постійно змінюють. Коли такі шматки заміняються, потрібно пройти деякий час, якщо їх запитують назад - і в той же час браузер продовжує оновлювати кеші. Що спричиняє величезні затримки. На практиці ви будете сидіти 2 хвилини, очікуючи завантаження єдиної веб-сторінки на новій вкладці.

Робочий стіл насправді не переймається диском io, оскільки робочий стіл рідко читає і записує кеш-пам'ять, повторюючи великі частини даних. Вирізання диска io з метою максимальної запобігання заміни набагато вигідніше для робочого столу, ніж 30% пам'яті, зарезервованої для кеш-диска з 30% оперативної пам’яті (повно блоків, що належать активно використовуваним програмам).

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


3
+1 для опису відмінностей сервера та робочого столу. Дисковий кеш сервера може бути виконаний на диску.
Ді

Якщо це так, то чому серверна та настільна версії Ubuntu за замовчуванням змінюються на 60? Якщо те, що ви заявляєте, є істинним, тоді було б більше сенсу, щоб версія для настільних ПК була забезпечена за замовчуванням 20 або навіть 10, але це не так.
JAB

1
Довідка про те, що заміщення - це прямий відсоток барана, який заміняється? Я не думаю, що це працює так.
Xen2050

1
Це не так. Заміна не пов'язана з відсотком оперативної пам'яті. Це регулятор, який налаштовує нечіткий алгоритм щодо того, щоб в тій чи іншій проблемній ситуації більш-менш ймовірно було замінено. Я також думаю, що опис навантажень сервера та настільних комп’ютерів у цій відповіді робить купу припущень, які не завжди виконуються.
thomasrutter

9

Якщо ви запускаєте сервер Java у вашій системі Linux, ви дійсно повинні розглянути можливість зменшення простоти в значній мірі від значення за замовчуванням 60. Тож 20 справді хороший початок. Обмін є вбивцею для процесу збирання сміття, оскільки колекції щоразу повинні торкатися великих частин пам'яті процесу. В ОС немає засобів для виявлення таких процесів і виправлення речей для них. Найкраща практика - уникати заміни настільки, наскільки це можливо, для продуктивних серверів додатків.


Це правда, що якщо ви присвятите сервер спеціалізованому навантаженню, яке, на вашу думку, не матиме користі від кешу системи (наприклад, сервер бази даних), то зменшення простоти може мати сенс. Я не думаю, що збирання сміття є достатньо спеціалізованою справою. Якщо часто торкатися пам'яті, її не буде замінюватися, вона зберігатиметься у фізичній оперативній пам'яті. Єдиний раз, коли це не так, якщо у вас серйозна ситуація з низькою пам’яттю - а заміна не несе відповідальності.
thomasrutter

4

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

Простий відеоурок про те, як це зробити з повним поясненням, дивіться на відео YouTube нижче

http://youtu.be/i6WihsFKJ7Q


1
Чудове відео, яке ви зробили, але це відео насправді не відповідає безпосередньо на питання, його більше - як порядок зміни змін.
jmunsch

+1 для натяку на життя SSD, для SSD найкраще, якщо система є максимально можливою лише для читання, відпочинок повинен залишатися в пам'яті, і сьогодні пам'ять зазвичай не є великою проблемою на нинішніх настільних ПК.
Ді

3

Я хочу додати певну перспективу від інженера Big Data Performance, щоб іншим отримати більше інформації про технологію 2017 року.

Мій особистий досвід полягає в тому, що, як правило, я відключаю заміну, щоб гарантувати, що мої системи працюють з максимальною швидкістю, на моїй робочій станції для конкретної проблеми я виявив, що заміщення 1 і 10 призводить до замерзання (назавжди) і тривалих пауз. Зміна 80 для цього конкретного додатку призводить до набагато кращої продуктивності та коротших пауз, ніж за замовчуванням (60). Зауважте, що у мене було 8 Гб оперативної пам’яті та 4х 256 ГБ свопів, підкріплених 1 HDD. Я, як правило, зазначаю точну статистику, що спостерігається в моїх орієнтирах та повних технічних характеристиках, але я ще цього не робив, і це не останнє місце для робочого столу низького класу.

Повернувшись до моєї колишньої компанії, причиною того, що ми не ввімкнули заміщення на серверах Spark із [500 ГБ до 4 ТБ] х [10-100] вузлами, це те, що ми бачили низьку ефективність як знак переробляти конвеєр даних та структури даних в більш ефективний манера. Ми також не хотіли орієнтувати жорсткі диски / SSD. Крім того, для заміни стільки оперативної пам'яті потрібно 10-30 дисків на вузол паралельним записом, щоб мінімізувати час доступу до диска.

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

Для тих, хто вважає, що вигідніша замішаність є поганою порадою, ось невелика перспектива. У минулому HD-диски мали лише кілька кб кешу, якщо такі були. Інтерфейс був IDE / Parallel ATA. Шина процесора також була набагато повільніше, а також оперативної пам'яті та багатьох інших речей. Коротше кажучи, всі системи були дуже повільними (відносно сьогоднішніх). Пару років тому HDD використовували SATA3. Сьогодні вони використовують протокол NVMe, який має значні покращення затримки. HD-файли мають багато МБ кешу. І найцікавіша частина - це коли ви використовуєте сучасний SSD (набагато стабільніший витривалість читання / запису та perf) з NVMe або PCIe як вашим сховищем для swap. Це найкращий компроміс між вартістю та продуктивністю. Будь ласка, не намагайтеся це робити з дешевими або старими SSD.

Міняйте + SSD-диски! Завдяки високоефективним енергонезалежним сховищам, я б дуже рекомендував експериментувати з високим значенням простоти. Це головним чином залежить від моделей доступу до пам'яті (випадковий доступ до всієї пам'яті проти рідкісного доступу до більшості), використання пам’яті, якщо пропускна здатність диска вже насичена, та фактичної вартості обмолоту.


1

Можливо, багато сприйманої поведінки під час заміни при запуску або при відкритті програм - це Linux зчитування конфігураційних файлів тощо з диска. Тому, можливо, найкраще подивитися програму монітора системи, перш ніж припускати, що доступ до жорсткого диска пов'язаний із заміною.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.