NUMA — це коротке слово, яке періодично помічаєш там, то тут. У налаштуваннях BIOS, логах операційної системи тощо. Розумієш, що воно якось пов’язане з багатопроцесорними системами, але на що саме впливає і навіщо потрібно — ці питання практично завжди залишаються без відповіді. У більшості випадків, не буває особливої потреби детально розумітися на цих тонкощах роботи комп’ютера. Як відомо, людина — створення ліниве, а отже: без потреби нічого робити не буде. Працює — значить не чіпай… нехай далі працює. Це девіз багатьох системних адміністраторів, і донедавна ми також цим від багатьох інших не відрізнялися.
Природно, ми намагалися щось оптимізувати, коректніше налаштовувати багато компонентів операційної системи та серверів. Але ми не намагалися оптимізувати абсолютно все. Не факт, що зусилля, витрачені на оптимізацію, якось окупляться. 
Це тривало доти, доки ми не зіткнулися з дивною поведінкою сервера, яку було дуже важко пояснити. У сервера періодично переставала працювати дискова підсистема, з системи просто зникав RAID-контролер. Це робило сервер непрацездатним. Після перезавантаження нормальна робота системи відновлювалася. RAID контролер знову з’являвся та працював справно, начебто нічого не відбувалося.
Заміна RAID контролера, встановлення його в інший слот PCI-X, а також заміна материнської плати, процесорів, блоків живлення — нічого не давало результатів. Сервер продовжував працювати нестабільно. Що ми тільки не робили — сервер продовжував падати із завидною регулярністю. Від одного разу на день до кількох разів на годину. Спрогнозувати дату падіння та пояснити, із чим воно пов’язане, було вкрай складно. Спостерігаючи за графіками завантаження сервера, ми не розуміли, у чому проблема. Проблеми виникали і за невеликого навантаження на процесор, і за великого.
Відповідь було знайдено випадково, у процесі перебору. Причиною збоїв виявився некоректний розподіл оперативної пам’яті між процесорами. Я випадково, збираючи інформацію про систему, глянув на топологію NUMA. Виявилося, що більшість процесів у системі виконує далекий доступ до пам’яті. Це змусило мене звернути увагу на те, що постачальник, з розрахунку на апгрейд (модернізацію), замість встановлення 6 планок пам’яті, встановив 3, але вдвічі більшого обсягу. Як наслідок, планки були встановлені лише у слоти одного процесора. І, з волі нагоди, перший процесор у системі залишився без планок пам’яті. Так, випадковий погляд, кинутий на речі, на які ми ніколи не звертали увагу, допоміг виявити проблему.
То що таке NUMA? Non-Uniform Memory Access – це «нерівномірний доступ до пам’яті». Так говорить Вікіпедія.
Простою мовою: це спосіб взаємодії одного процесора із блоками пам’яті другого процесора. Це розумний розподіл пам’яті між процесами (умовно — програмами) в ОС. NUMA допомагає розподілити процеси в системі так, щоб вони отримували області оперативної пам’яті, які розташовані максимально близько до процесорів, на яких вони працюють.
У такій ситуації, як у нас, програми (процеси), запущені на процесорі без оперативної пам’яті, використовували так званий «далекий доступ». Іншими словами: доступ здійснювався через контролер на іншому процесорі. Все б нічого і система linux давно вміє вирішувати подібні проблеми. Апріорі програми (процеси) розміщуються на процесорі з оперативною пам’яттю.
Але ми не врахували одного чинника. А саме: систему віртуалізації XEN.
Вона самостійно призначає відповідність віртуального процесора для віртуальної машини фізичному (реальному) процесору у системі. Погіршує ситуацію той факт, що хост-система (керуюча) є такою самою віртуальною машиною, як і інші. І тільки до неї підключено пристрої, такі як: контролер дисків, мережева карта тощо. За замовчуванням будь-який віртуальний процесор може виявитися на будь-якому фізичному. Найчастіше в хост-системі перший віртуальний процесор відповідають першому фізичному процесору. І оскільки на віртуальній машині з точки зору NUMA всі процесори і вся пам’ять локальні, хост-система розміщує на першому процесорі всі переривання і процеси для роботи з пристроями. А якщо цей процесор не має підключеної оперативної пам’яті, то це не лише знижує продуктивність системи, а й дозволяє виникнути аварійній ситуації. Плюс до всього цього першому фізичному процесору можуть бути призначені кілька віртуальних.
Отже, за час (ресурси) першого процесора конкуруватимуть кілька віртуальних машин. Встановлення пріоритету доступу до процесорного часу для хост-системи дещо покращує ситуацію, але не вирішує проблеми повністю. У процесі роботи через брак процесорного часу для хост-системи відбуваються збої і шина pci переініціалізується. У якийсь момент перевищується межа очікування відповіді, закладена в драйвер RAID контролера, і система констатує факт втрати. Родзинкою ситуації є той факт, що проблема з’являється лише за певного навантаження. Як тільки ми забираємо всі віртуальні машини з цього сервера, він починає стабільно працювати.
Рішенням виявився примусовий перерозподіл процесорів між віртуальними машинами. Так, щоб перший віртуальний процесор на хост-системі був на фізичному процесорі, до якого підключено оперативну пам’ять. До того ж, ми виділили одне фізичне ядро процесора з пам’яттю ексклюзивно для хост-системи. Це дозволило уникнути конкуренції з іншими віртуальними машинами.
І вуаля! Система вже понад місяць працює стабільно. Але це не все! Також суттєво збільшилася швидкість роботи з дисковою підсистемою. Це рішення не нове і часто описується на багатьох спеціалізованих ресурсах, але в програмних продуктах, що використовуються для автоматизації VPS-хостингу, воно чомусь не враховується в принципі.
На даний момент ми не купуємо системи без мінімального набору оперативної пам’яті для всіх процесорів. Також ми провели експеримент із системою, яка мала повний комплект пам’яті. Виділили одне ядро фізичного процесора для хост-системи та отримали приріст швидкості роботи дискової підсистеми. Тепер ми працюємо над тим, щоб автоматизувати подібні установки на всіх наших серверах. Це дозволить, не змінюючи апаратне забезпечення, підвищити продуктивність дискової підсистеми на наших серверах.
Керівник відділу Системного Адміністрації VPS.ua Денис Міщенко
