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