Чи повинні VM Linux у VMware / ESX мати розділ своп?


18

У налаштуваннях VMware ESX в чому різниця цих параметрів ?:

  • Linux VM з розміром 1 Гб оперативної пам’яті та 1 ГБ своп-розділу, а VM використовує 1,5 ГБ оперативної пам’яті
  • Linux VM з 1 Гб оперативної пам’яті та без розділів підкачки, а VM використовує 1,5 ГБ оперативної пам’яті

Я маю на увазі, в обох випадках використовується своп;

  • у першому swap робиться до розділу swap linux
  • у другому випадку VMware підмінить 512MB на пул зберігання VMware.

То чи є сенс надавати Linux VM в розділ swap?


Ви запитуєте, чи потрібен хост ESX своп або ні, або як він обробляється з VM? Можливо, ви хочете розібратися в цьому питанні, щоб уточнити, що ви маєте на увазі.
Барт Сільверстрім

Сподіваюся, зроблено зараз.
Сандра

Відповіді:


15

Ігноруючи той факт, що люди мають справу з конкретними причинами ОС, у мене є дві причини, чому це погана ідея не запускати розділ / файл swap.

  1. Якщо у вас розміщено 1,5 ГБ оперативної пам’яті, розміщеної на ВМ без файлу / розділу пробілу, і він хоче використовувати 1,5 ГБ + 1 Мб, він повідомить про помилку пам'яті. Завдяки простору обміну, він зможе обмінюватися даними з активної пам'яті та на диск.
  2. Гостьова ОС виконує набагато кращу роботу з управління пам'яттю, ніж хост. Ось чому така технологія, як повітряна куля пам’яті, існує тому, що Хост може вчитись здогадуватися про те, яка пам’ять зараз не потрібна, але гість знає на набагато більш інтелектуальному рівні (це не дозволяє замінювати пам’ять ОС, що може вбити вашу продуктивність).

10

Так. Це шлях Unix.

Unix (навіть Linux) розраховує на можливість обміну.
Погані речі трапляються, коли система не може поміняти місцями (або тому, що вона була неправильно налаштована без замінного розділу або через те, що місця для заміни заповнені). В Linux однією з таких поганих речей є Out Of Memory Killer, який занурить ножа в задню частину програми, на яку вона вважає, що використовує найбільшу оперативну пам’ять (улюблена ціль - сервери баз даних).


4

Що ви /proc/sys/vm/overcommit_memoryвстановили? З документації на ядро:

0       -       Heuristic overcommit handling. Obvious overcommits of
                address space are refused. Used for a typical system. It
                ensures a seriously wild allocation fails while allowing
                overcommit to reduce swap usage.  root is allowed to
                allocate slightly more memory in this mode. This is the
                default.

1       -       Always overcommit. Appropriate for some scientific
                applications.

2       -       Don't overcommit. The total address space commit
                for the system is not permitted to exceed swap + a
                configurable percentage (default is 50) of physical RAM.
                Depending on the percentage you use, in most situations
                this means a process will not be killed while accessing
                pages but will receive errors on memory allocation as
                appropriate.

Таким чином, якщо ви використовуєте 1, різниці немає. Якщо ви використовуєте 2 файли swap і не маєте жодного файлу Linux, жоден процес не зможе виділити 512M (віртуальної) пам'яті. Результат не зрозумілий для 0.

Редагувати: З http://utcc.utoronto.ca/~cks/space/blog/linux/LinuxVMOvercommit так працює 0:

Евристичні спроби перевиконання спроб визначити, скільки пам’яті може дати вам система, якби вона відновила всю пам'ять, яку могла, і жоден інший процес не використовував більше оперативної пам’яті, ніж зараз; якщо ви просите більше, ніж у цьому, у виділенні вам відмовляються. Зокрема, теоретичне число «вільної пам’яті» обчислюється шляхом додавання вільного простору підкачки, вільної оперативної пам’яті (менше 1/32, якщо ви не root), і всього простору, який використовується уніфікованим кеш-буфером та даними ядра, позначеним як відновлюваний (менше деяких зарезервованих сторінок).

Тому він використовує своп у розрахунку. Загалом я б дотримувався рекомендації RHEL щодо:

M = Amount of RAM in GB, and S = Amount of swap in GB, then
If M < 2
    S = M *2
Else
    S = M + 2

1
cat /proc/sys/vm/overcommit_memoryповертає 0. Що ви рекомендуєте щодо overcommit_memoryвартості та свопу / без заміни?
Сандра

3

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

Але продуктивність обох машин все одно вийде, якщо ви будете тримати 33% своїх потреб в пам'яті на диску.


Коли ви говорите "кореневий диск". Ви маєте на увазі хост ESX, де ESX створює свої файли swap?
Сандра

Ні, я маю на увазі системний диск VM, що містить кореневу файлову систему. Зрештою, саме там відбудеться заміна за відсутності виділеного розділу swap.
Свен

Зауважте, ця відповідь обговорюється між файлом swap і файлом swap. Я подумав, що питання вам взагалі потрібен.
user606723

@ user606723: Якщо ви взагалі не використовуєте своп, у вас виникла помилка в пам'яті, якщо ви спробуєте виділити більше пам'яті, ніж VM, і використання 1,5 Гб при 1 Гб фізична ситуація не може виникнути.
Свен

@SvenW, Так, але це не так, що може статися щось подібне. Це адміністратор вирішив.
user606723

0

Перегляньте наступне посилання- https://help.ubuntu.com/community/SwapFaq

В основному, якщо вам не потрібна сплячка або використання більшого обсягу пам'яті, ніж ви виділяєте на VM, немає суттєвої переваги в розділі swap.

Я не використовував swap розділ / файл на жодній з моїх Linux машин протягом багатьох років.


1
Питання не в суап / ні свопі. Йдеться про те, як VMware обробляє своп.
Сандра

0

Очевидною перевагою для swap є те, що коли ваша машина виходить з ладу, ви все одно можете створити дамп аварійного завершення роботи. Виправте мене, якщо я помиляюся, але afaik це неможливо без свопів. Звичайно, це не специфічно для VMWare, а стосується будь-якого місця. Я відчував, що це може бути важливо вказати.

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