Анатомия серверного процессора. Производительность сервера в первую очередь определяется характеристиками его центрального процессора (CPU). В отличие от десктопных решений, серверные CPU (например, Intel Xeon Scalable или AMD EPYC) проектируются для обеспечения максимальной надежности и непрерывной работы в режиме 24/7 под высокой нагрузкой. Ключевыми характеристиками являются: количество физических ядер (Cores), базовая и турбо-частота (Clock speed), а также объем кэш-памяти.

Кэш-память — это сверхбыстрая статическая память (SRAM), расположенная прямо на кристалле процессора. Она необходима для сглаживания разницы в скорости между невероятно быстрым CPU и относительно медленной оперативной памятью (RAM). Кэш строится по иерархическому принципу: L1 (Level 1) — самый быстрый, но самый маленький (десятки килобайт на ядро), хранит инструкции и данные, которые нужны процессору прямо сейчас. L2 — больше по объему (мегабайты), но чуть медленнее. L3 — общий кэш для всех ядер процессора (достигает сотен мегабайт), используется для обмена данными между ядрами. Эффективная работа кэша L3 критически важна для баз данных, где множество потоков обращаются к общим таблицам.

Многопроцессорные системы и архитектура NUMA. Большинство корпоративных серверов имеют многопроцессорную архитектуру. На материнской плате располагается два, четыре или даже восемь физических сокетов (разъемов) для установки процессоров. Исторически все процессоры обращались к общему контроллеру памяти по единой шине (архитектура SMP/UMA). Это создавало «бутылочное горлышко»: при одновременном обращении нескольких CPU к памяти шина не справлялась с трафиком.

Для решения этой проблемы была разработана архитектура NUMA (Non-Uniform Memory Access) — Неравномерный доступ к памяти. Это важнейший концепт для системного администратора. В NUMA-архитектуре контроллер оперативной памяти встроен прямо в каждый процессор. Оперативная память физически разделена на банки (слоты на материнской плате), которые жестко привязаны к конкретным сокетам. Один процессор (Node 0) и привязанная к нему память образуют NUMA-узел.

Особенности работы NUMA и межпроцессорные связи. Доступ процессора к «своей» локальной памяти (Local Memory) происходит на максимальной скорости и с минимальной задержкой. Однако, что произойдет, если Процессору 1 понадобятся данные, которые физически лежат в планках памяти, подключенных к Процессору 2? В этом случае запрос передается по специальным высокоскоростным шинам, соединяющим процессоры между собой (у Intel это называется UPI/QPI, у AMD — Infinity Fabric). Доступ к памяти соседнего процессора называется удаленным (Remote Memory Access). Главная проблема — такой доступ занимает значительно больше времени (увеличивается latency).

Just-in-Time Learning: Как проверить NUMA-топологию на Linux-сервере? Если вы подозреваете проблемы с производительностью, подключитесь по SSH и используйте утилиту numactl --hardware. Команда покажет количество NUMA-узлов, объем памяти в каждом из них и матрицу задержек (node distances) между узлами. Это первый шаг в диагностике узких мест производительности.

Практика виртуализации: NUMA-awareness. Понимание NUMA критически важно при настройке гипервизоров (VMware ESXi, KVM). Когда вы создаете виртуальную машину (ВМ), гипервизор выделяет ей виртуальные процессоры (vCPU) и виртуальную память (vRAM). Типичная и фатальная ошибка новичков: создание огромных виртуальных машин (Monster VMs), размер которых превышает емкость одного физического NUMA-узла. Например, на сервере с двумя 16-ядерными процессорами и 128 ГБ RAM (по 64 ГБ на узел), администратор создает ВМ с 20 vCPU и 80 ГБ RAM.

Последствия (Direct Instruction): Гипервизор будет вынужден «размазать» эту ВМ по двум физическим процессорам. Часть процессов ВМ будет выполняться на CPU 1, но обращаться к памяти, физически подключенной к CPU 2. Это вызовет постоянный поток данных через межпроцессорную шину UPI, резкий рост задержек (latency) и глобальную деградацию производительности всего физического сервера. Правильный подход — NUMA-awareness: при конфигурации ВМ необходимо следить, чтобы её ресурсы (vCPU и RAM) укладывались в границы одного физического NUMA-узла (в нашем примере — максимум 16 vCPU и 64 ГБ RAM на одну ВМ). Если ВМ должна быть больше, необходимо правильно настроить vNUMA внутри гостевой ОС.