У цій статті поговоримо про лічильники продуктивності оперативної пам'яті (RAM) у vSphere.
Начебто з пам'яттю все однозначніше, ніж з процесором: якщо на ВМ виникають проблеми з продуктивністю, їх складно не помітити. Проте якщо вони з'являються, впоратися з ними набагато складніше. Але про все по порядку.
Трохи теорії
Оперативна пам'ять віртуальних машин береться з пам'яті сервера, де працюють ВМ. Це цілком очевидно :). Якщо оперативної пам'яті сервера не вистачає всім бажаючих, ESXi починає застосовувати техніки оптимізації споживання оперативної пам'яті (memory reclamation techniques). А якщо ні, то операційні системи ВМ падали б з помилками доступу до ОЗУ.
Які техніки застосовувати ESXi вирішує залежно від завантаженості оперативної пам'яті:
Стан пам'яті
кордон
Дії
Високий
400% від minFree
Після досягнення верхньої межі великі сторінки пам'яті розбиваються на маленькі (TPS працює в стандартному режимі).
Очистити
100% від minFree
Великі сторінки пам'яті розбиваються на малі, TPS працює примусово.
М'який
64% від minFree
TPS + Balloon
Жорсткий
32% від minFree
TPS + Compress + Swap
низький
16% від minFree
Compress + Swap + Block
minFree - це оперативна пам'ять, необхідна для роботи гіпервізора.
До ESXi 4.1 включно minFree за умовчанням було фіксованим - 6% від обсягу оперативної пам'яті сервера (відсоток можна було змінити через опцію Mem.MinFreePct на ESXi). У пізніших версіях через зростання обсягів пам'яті на серверах minFree стало розраховуватися виходячи з обсягу пам'яті хоста, а не фіксоване відсоткове значення.
Значення minFree (за замовчуванням) вважається так:
Відсоток пам'яті, що резервується для minFree
Діапазон пам'яті
6%
0-4 Гбайт
4%
4-12 Гбайт
2%
12-28 Гбайт
1%
Пам'ять, що залишилася
Наприклад, для сервера зі 128 Гбайт RAM значення MinFree буде таким:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 Мбайт = 1,88 Гбайт
Фактичне значення може відрізнятися на пару сотень Мбайт, це залежить від сервера та оперативної пам'яті.
Відсоток пам'яті, що резервується для minFree
Діапазон пам'яті
Значення для 128 Гбайт
6%
0-4 Гбайт
245,76 Мбайт
4%
4-12 Гбайт
327,68 Мбайт
2%
12-28 Гбайт
327,68 Мбайт
1%
Пам'ять, що залишилася (100 Гбайт)
1024 Мбайт
Зазвичай для продуктивних стендів нормальним вважатимуться лише стан High. Для стендів для тестування та розробки прийнятними можуть бути стани Clear/Soft. Якщо оперативної пам'яті на хості залишилося менше 64% MinFree, то у ВМ, які працюють на ньому, точно спостерігаються проблеми з продуктивністю.
У кожному стані застосовуються певні memory reclamation techniques починаючи з TPS, що практично не впливає на продуктивність ВМ, закінчуючи Swapping'ом. Розповім про них докладніше.
Transparent Page Sharing (TPS). TPS — це, власне кажучи, дедуплікація сторінок оперативної пам'яті віртуальних машин на сервері.
ESXi шукає однакові сторінки оперативної пам'яті віртуальних машин, рахуючи та порівнюючи hash-суму сторінок, і видаляє дублікати сторінок, замінюючи їх посиланнями на ту саму сторінку у фізичній пам'яті сервера. В результаті споживання фізичної пам'яті знижується і можна домогтися деякої перепідписки з пам'яті практично без зниження продуктивності.
Цей механізм працює лише для сторінок пам'яті розміром 4 Кбайт (small pages). Сторінки розміром 2 Мбайт (large pages) гіпервізор дедуплікувати навіть не намагається: шанс знайти однакові сторінки такого розміру не великий.
За промовчанням ESXi виділяє пам'ять великих сторінок. Розбивання великих сторінок на малі починається при досягненні порогу стану High і відбувається примусово, коли досягається стан Clear (див. таблицю станів гіпервізора).
Якщо ви хочете, щоб TPS починав роботу, не чекаючи заповнення оперативної пам'яті хоста, в Advanced Options ESXi потрібно встановити значення "Mem.AllocGuestLargePage" 0 (за замовчуванням 1). Тоді виділення великих сторінок пам'яті для віртуальних машин буде вимкнено.
З грудня 2014 року в усіх релізах ESXi TPS між ВМ за замовчуванням відключено, оскільки було знайдено вразливість, що теоретично дозволяє отримати з однієї ВМ доступ до оперативної пам'яті іншої ВМ. Подробиці тут. Інформація про практичну реалізацію вразливості TPS мені не зустрічалося.
Політика TPS контролюється через advanced option "Mem.ShareForceSalting" на ESXi:
0 - Inter-VM TPS. TPS працює на сторінках різних ВМ;
1 – TPS для ВМ з однаковим значенням “sched.mem.pshare.salt” у VMX;
2 (за замовчуванням) – Intra-VM TPS. TPS працює для сторінок усередині ВМ.
Однозначно має сенс вимикати великі сторінки та включати Inter-VM TPS на тестових стендах. Також це можна використовувати для стендів із великою кількістю однотипних ВМ. Наприклад, на стендах з VDI економія фізичної пам'яті може сягати десятків відсотків.
Memory Ballooning. Ballooning вже не така нешкідлива та прозора для операційної системи ВМ техніка, як TPS. Але при грамотному застосуванні з Ballooning'ом можна жити і навіть працювати.
Разом з Vmware Tools на ВМ встановлюється спеціальний драйвер, який називається Balloon Driver (він же vmmemctl). Коли гіпервізору починає бракувати фізичної пам'яті і він переходить у стан Soft, ESXi просить ВМ повернути оперативну пам'ять, що не використовується, через цей Balloon Driver. Драйвер у свою чергу працює на рівні операційної системи та запитує вільну пам'ять у неї. Гіпервізор бачить, які сторінки фізичної пам'яті зайняв Balloon Driver, забирає пам'ять у віртуальної машини та повертає хосту. Проблем із роботою ОС немає, оскільки лише на рівні ОС пам'ять зайнята Balloon Driver'ом. За промовчанням Balloon Driver може забрати до 65% пам'яті ВМ.
Якщо на ВМ не встановлені VMware Tools або вимкнено Ballooning (не рекомендую, але є :), гіпервізор відразу переходить до жорсткіших технік відбирання пам'яті. Висновок: стежте, щоб VMware Tools на ВМ були.
Роботу Balloon Driver'а можна перевірити з ОС через VMware Tools.
Memory Compression. Ця техніка застосовується, коли ESXi досягає стану Hard. Як випливає з назви ESXi намагається стиснути 4 Кбайт сторінки оперативної пам'яті до 2 Кбайт і таким чином звільнити трохи місця у фізичній пам'яті сервера. Дана техніка значно збільшує час доступу до вмісту сторінок оперативної пам'яті ВМ, оскільки сторінку треба попередньо розтиснути. Іноді не всі сторінки вдається стиснути і процес займає деякий час. Тому дана техніка практично не дуже ефективна.
Memory Swapping. Після недовгої фази Memory Compression ESXi практично неминуче (якщо ВМ не поїхали на інші хости або не вимкнулися) переходить до Swapping'у. Якщо пам'яті залишилося мало (стан Low), то гіпервізор також перестає виділяти ВМ сторінки пам'яті, що може викликати проблеми у гостьових ОС ВМ.
Ось як працює Swapping. При включенні віртуальної машини створюється файл з розширенням .vswp. За розміром він дорівнює незарезервованій оперативній пам'яті ВМ: це різниця між конфігурованою та зарезервованою пам'яттю. При роботі Swapping ESXi вивантажує сторінки пам'яті віртуальної машини в цей файл і починає працювати з ним замість фізичної пам'яті сервера. Зрозуміло, така така “оперативна” пам'ять на кілька порядків повільніша за справжню, навіть якщо .vswp лежить на швидкому сховищі.
На відміну від Ballooning'а, коли у ВМ відбираються сторінки, що не використовуються, при Swapping'e на диск можуть переїхати сторінки, які активно використовуються ОС або додатками всередині ВМ. В результаті продуктивність ВМ падає до підвисання. ВМ формально працює та її як мінімум можна правильно відключити з ОС. Якщо ви будете терплячі 😉
Якщо ВМ пішли в Swap — це нештатна ситуація, яку краще не допускати.
Основні лічильники продуктивності пам'яті віртуальної машини
Ось ми й дісталися головного. Для моніторингу стану пам'яті у ВМ є такі лічильники:
Active - Показує обсяг оперативної пам'яті (Кбайт), до якого ВМ отримала доступ у попередній період вимірювання.
Використання — те, що Active, але у відсотках від налаштованої оперативної пам'яті ВМ. Розраховується за такою формулою: active ÷ virtual machine configured memory size.
Високий Usage та Active, відповідно, не завжди є показником проблем продуктивності ВМ. Якщо ВМ агресивно використовує пам'ять (як мінімум отримує до неї доступ), це не означає, що пам'яті не вистачає. Скоріше, це привід подивитися, що відбувається в ОС.
Є стандартний Alarm по Memory Usage для ВМ:
Загальні - Обсяг оперативної пам'яті ВМ, дедуплікованої за допомогою TPS (всередині ВМ або між ВМ).
Звичайно - Обсяг фізичної пам'яті хоста (Кбайт), який був відданий ВМ. Включає Shared.
Споживається (Granted – Shared) – обсяг фізичної пам'яті (Кбайт), яку ВМ споживає з хоста. Не містить Shared.
Якщо частина пам'яті ВМ віддається не з фізичної пам'яті хоста, а з swap-файлу або пам'ять відібрана у ВМ через Balloon Driver, цей обсяг не враховується Granted і Consumed.
Високі значення Granted та Consumed – це абсолютно нормально. Операційна система поступово забирає пам'ять у гіпервізора та не віддає назад. Згодом у активно працює ВМ значення даних лічильників наближається до обсягу налаштованої пам'яті, і там залишаються.
Нульовий - Обсяг оперативної пам'яті ВМ (Кбайт), який містить нулі. Така пам'ять вважається гіпервізором вільною і може бути віддана іншим віртуальним машинам. Після того, як гостьова ОС отримала записала щось у занулену пам'ять, вона переходить у Consumed і назад уже не повертається.
Reserved Overhead - Обсяг оперативної пам'яті ВМ, (Кбайт) зарезервований гіпервізором для роботи ВМ. Це невеликий обсяг, але він обов'язково має бути в наявності на хості, інакше ВМ не запуститься.
Повітряна куля - Обсяг оперативної пам'яті (Кбайт), вилученої у ВМ за допомогою Balloon Driver.
Стиснута - Обсяг оперативної пам'яті (Кбайт), яку вдалося стиснути.
Після перестановки - Об'єм оперативної пам'яті (Кбайт), яка через відсутність фізичної пам'яті на сервері переїхала на диск.
Balloon та інші лічильники memory reclamation techniques дорівнюють нулю.
Ось так виглядає графік з лічильниками Memory нормально працює ВМ зі 150 ГБ оперативної пам'яті.
На графіку нижче у ВМ очевидні проблеми. Під графіком видно, що з даної ВМ було використано всі описані техніки роботи з оперативної пам'яттю. Balloon для цієї ВМ значно більше, ніж Consumed. За фактом ВМ скоріше мертва, ніж жива.
ESXTOP
Як і з CPU, якщо хочемо оперативно оцінити ситуацію на хості, а також динаміку її з інтервалом до 2 секунд, варто скористатися ESXTOP.
Екран ESXTOP по Memory викликається клавішею «m» і виглядає так (вибрані поля B, D, H, J, K, L, O):
Цікавими для нас будуть такі параметри:
Mem overcommit avg - Середнє значення передплати пам'яті на хості за 1, 5 і 15 хвилин. Якщо вище нуля, це привід подивитися, що відбувається, але завжди показник наявності проблем.
У рядках PMEM/MB и VMKMEM/MB — інформація про фізичну пам'ять сервера та пам'ять доступну VMkernel. З цікавого тут можна побачити значення minfree (в Мбайт), стан хоста по пам'яті (у нашому випадку, high).
У рядку NUMA/MB можна побачити розподіл оперативної пам'яті за NUMA-нодами (сокетами). У цьому прикладі розподіл нерівномірний, що у принципі дуже добре.
Далі йде загальна статистика по серверу з memory reclamation techniques:
PSHARE/MB - Це статистика TPS;
SWAP/MB - Статистика використання Swap;
ZIP/MB - Статистика компресії сторінок пам'яті;
MEMCTL/MB - Статистика використання Balloon Driver.
По окремих ВМ нас може зацікавити така інформація. Імена ВМ я приховав, щоб не бентежити аудиторію:). Якщо метрика ESXTOP аналогічна лічильнику у vSphere, наводжу відповідний лічильник.
MEMSZ - Об'єм пам'яті, налаштований на ВМ (МБ).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT - Granted в МБайт.
TCHD - Active в МБайт.
MCTL? - Чи встановлено на ВМ Balloon Driver.
MCTLSZ - Balloon в МБайт.
MCTLGT - Обсяг оперативної пам'яті (МБайт), який ESXi хоче вилучити у ВМ через Balloon Driver (Memctl Target).
MCTLMAX — максимальний обсяг оперативної пам'яті (МБайт), який ESXi може вилучити з ВМ через Balloon Driver.
SWCUR - поточний обсяг оперативної пам'яті (МБайт), відданий ВМ із Swap-файлу.
SWGT - Обсяг оперативної пам'яті (МБайт), який ESXi хоче віддавати ВМ з Swap-файлу (Swap Target).
Також через ESXTOP можна переглянути докладнішу інформацію про NUMA-топологію ВМ. Для цього потрібно вибрати поля D, G:
Маленький - NUMA вузли, на яких розташована ВМ. Тут можна відразу помітити wide vm, які не містяться на один NUMA вузол.
NRMEM - Скільки мегабайт пам'яті ВМ бере з віддаленого NUMA вузла.
NLMEM - Скільки мегабайт пам'яті ВМ бере з локального NUMA вузла.
N%L – відсоток пам'яті ВМ на локальному NUMA вузлі (якщо менше 80% можуть виникнути проблеми з продуктивністю).
Memory на гіпервізорі
Якщо лічильники CPU за гіпервізором зазвичай не становлять особливого інтересу, то з пам'яттю ситуація зворотна. Високий Memory Usage на ВМ не завжди говорить про наявність проблеми з продуктивністю, а ось високий Memory Usage на гіпервізорі саме запускає роботу технік управління пам'яттю і викликає проблеми з продуктивністю ВМ. За аларма Host Memory Usage треба стежити і не допускати попадання ВМ в Swap.
Розміняти місцями
Якщо ВМ потрапила до Swap, її продуктивність дуже знижується. Сліди Ballooning'а та компресії швидко зникають після появи вільної оперативної пам'яті на хості, а ось повертатися зі Swap в оперативну пам'ять сервера віртуальна машина зовсім не поспішає.
До версії ESXi 6.0 єдиним надійним і швидким способом виведення ВМ із Swap було перезавантаження (якщо точніше вимкнення/ввімкнення контейнера). Починаючи з ESXi 6.0 з'явився хоч і не зовсім офіційний, але робочий та надійний спосіб вивести ВМ із Swap. На одній із конференцій мені вдалося поспілкуватися з одним із інженерів VMware, який відповідає за CPU Scheduler. Він підтвердив, що спосіб цілком робочий та безпечний. У нашому досвіді проблем із ним також помічено не було.
Власне команди для виведення ВМ із Swap Duncan Epping. Не повторюватиму докладний опис, просто наведу приклад її використання. Як видно на скріншоті, через деякий час після виконання зазначеної команди Swap на ВМ зникає.
Поради з управління оперативною пам'яттю на ESXi
Насамкінець наведу кілька порад, які допоможуть вам уникнути проблем з продуктивністю ВМ через оперативну пам'ять:
- Не допускайте передплати оперативної пам'яті в продуктивних кластерах. Бажано завжди мати ~20-30% вільної пам'яті в кластері, щоб у DRS (і адміністратора) був простір для маневру, і при міграції ВМ не пішли в Swap. Також не забувайте про запас для стійкості до відмови. Неприємно, коли при виході з ладу одного сервера та перезавантаженні ВМ за допомогою HA частина машин ще й йде у Swap.
- В інфраструктурах з високою консолідацією намагайтеся НЕ створювати ВМ із пам'яттю більше половини пам'яті хоста. Це знову ж таки допоможе DRS без проблем розподіляти віртуальні машини по серверах кластера. Це правило, зрозуміло, не є універсальним :).
- Слідкуйте за Host Memory Usage Alarm.
- Не забувайте ставити на VM VMware Tools і не вимикайте Ballooning.
- Розгляньте можливість включення Inter-VM TPS та вимкнення Large Pages у середовищах з VDI та тестових середовищах.
- Якщо ВМ має проблеми з продуктивністю, перевірте чи не використовує вона пам'ять з віддаленої NUMA-ноди.
- Виводьте ВМ із Swap якнайшвидше! Окрім іншого, якщо ВМ у Swap'і, з очевидних причин страждає СГД.
На цьому про оперативну пам'ять маю все. Нижче статті на тему для тих, хто хоче заглибитися в деталі. Наступна стаття буде присвячена стораджу.
Корисні посилання
Джерело: habr.com