Программы, поддерживающие и допускающие DLPAR

Программа, допускающая DLPAR, не прерывается аварийно при выполнении операций DLPAR.

Производительность программы может быть снижена в результате удаления ресурсов или остаться неизменной несмотря на их добавление, однако программа по-прежнему будет работать. Кроме того, программа, допускающая DLPAR, может отменить выполнение операции DLPAR, если у нее есть зависимости, о которых известно операционной системе.

Программа, поддерживающая DLPAR, с помощью кода DLPAR самостоятельно отслеживает и обрабатывает изменения конфигурации ресурсов. Это может быть реализовано следующими способами:

Путем регулярного опроса системы на предмет изменений в ее конфигурации.
Путем регистрации специального кода, который автоматически уведомляется при изменении конфигурации системы.

Программы, поддерживающие DLPAR, должны быть разработаны таким образом, чтобы при выполнении операций DLPAR как минимум не возникали ошибки. Рекомендуется, чтобы программы, поддерживающие DLPAR, также самостоятельно управляли производительностью и масштабируемостью. Это значительно более сложная задача, поскольку при удалении или добавлении памяти может потребоваться очистить и изменить размер буферов. Кроме того, при изменении числа включенных процессоров необходимо динамически изменить число нитей. Число нитей зависит не только от числа процессоров. Например, самый лучший способ снизить объем памяти, занимаемой программами на Java, - это уменьшить число нитей, поскольку это сокращает число активных объектов, которые должен обрабатывать сборщик мусора виртуальной машины Java™.

Большинство приложений по умолчанию допускают DLPAR.

Создание программ, допускающих DLPAR

DLPAR может вызвать следующие типы ошибок двоичной несовместимости:

Прим.: Эти ошибки вызваны добавлением процессора.

Если программа была оптимизирована для систем с одним процессором, но число процессоров в разделе увеличилось во время выполнения операции проверки, то может возникнуть ошибка. Ошибки также могут возникнуть в программах, содержащих операции блокировки для однопроцессорной системы, без инструкций sync и isync. Эти инструкции обязательны в коде, изменяющем самого себя, а также в сгенерированном коде, и, следовательно в системах с DLPAR. Постарайтесь найти все программы, в которых предполагается, что в системе есть только один процессор. В них необходимо включить функции, определяющие число активных процессоров.
Программы могут определить число включенных процессоров следующим образом:
- Путем загрузки поля _system_configuration.ncpus
- var.v_ncpus
- С помощью системного вызова sysconf с флагом _SC_NPROCESSORS_ONLN.
Программы, индексирующие данные по номеру процессора, используют для определения этого номера системный вызов mycpu. При добавлении нового процессора это может вызвать ошибку, поскольку пути к данным могут не быть правильно инициализированы и распределены. Сбой произойдет в программах, создающих список процессоров заранее, так как число процессоров может изменяться с DLPAR динамически.
Чтобы избежать этой ошибки, индексируйте данные по максимальному числу одновременно включенных процессоров. Значение N числа процессоров, которые могут поддерживаться операционной системой, предпочтительнее значения N включенных в данный момент процессоров. Максимальное число процессоров постоянно, в то время как число включенных процессоров увеличивается и уменьшается при включении и выключении процессоров. Минимальное и максимальное число процессоров задаются при создании раздела. Максимальное значение отражено в следующих переменных:
- _system_configuration.max_ncpus
- _system_configuration.original_ncpus
- var.v_ncpus_cfg
- sysconf (_SC_NPROCESSORS_CONF)
Переменные _system_configuration.original_ncpus и var.v_ncpus_cfg предопределены заранее. В системах с DLPAR они указывают максимально возможное число процессоров. В системах без DLPAR значение этих переменных отражает число процессоров, настроенное при загрузке. Обе эти переменные отражают максимальное поддерживаемое значение, вне зависимости от операций, выполняемых динамическое отключение процессоров. Эти предопределенные переменные рекомендуется использовать в приложениях, созданных в AIX 4.3, поскольку это гарантирует применение одного и того же кода в AIX 4.3 и более поздних версиях. Если приложение должно инициализировать зависящие от процессоров данные динамически, то зарегистрируйте обработчик DLPAR, который будет вызываться перед добавлением процессора.

Создание программ, поддерживающих DLPAR

Программа, поддерживающая DLPAR, может самостоятельно распознавать изменения конфигурации системы и динамически адаптироваться к ним. Код такой программы может не соответствовать модели DLPAR, например, в него может быть встроен системный монитор, позволяющий определить изменения в конфигурации системы. Такой подход позволяет добиться ограниченного повышения производительности, но неприменим для эффективной адаптации к крупным изменениям в системе, поскольку интегрирует программу с DLPAR. Например, системный монитор не подходит для компьютеров с оперативным подключением процессоров, так как одновременно может быть подключено несколько процессоров и карт памяти. Он также неприменим для работы с зависимостями приложений, такими как связывание с процессором, поскольку некоторые действия должны быть предприняты до непосредственного удаления процессора DLPAR.

Технологии DLPAR могут применяться в приложениях следующих типов:

Приложения, логика работы которых зависит от конфигурации системы, включая следующие:
- Определяющие число включенных процессоров и объем памяти при запуске приложения.
- Отрабатывающие внешние инструкции на основе конфигурации процессоров и памяти, что позволяет использоваться максимально возможное число нитей, максимальный объем буферов и закрепленной памяти.
Приложения, которые сами определяют число включенных процессоров и объем памяти, включая следующие:
- Мониторы производительности
- Средства отладки
- Программы устранения ошибок
- Администраторы загрузки
- Администраторы лицензий
  Прим.: DLPAR применяется не во всех администраторах лицензий, особенно при лицензировании числа пользователей.
Приложения, закрепляющие данные, текст или стек приложений с помощью системного вызова plock.
Приложения, использующие общие сегменты памяти System с помощью PinvOption (SHM_PIN)
Приложения, связывающие нити с процессорами с помощью системного вызова bindprocessor.

Динамическое распределение ресурсов для больших страниц памяти не поддерживаются. Объем памяти, заранее выделенной пулу больших страниц, может повлиять на способность DLPAR работать с памятью. Область памяти с большими страницами удалить нельзя. Разработчики программ должны предоставить возможность не использовать большие страницы.

Создание программ, поддерживающих DLPAR, с помощью API DLPAR

Для поддержки DLPAR предназначены специальные интерфейсы программирования. На разных этапах работы с динамическое распределение ресурсов между разделами приложениям отправляется сигнал SIGRECONFIG. Обычная операция с подсистемой DLPAR состоит из этапа проверки, предварительного и завершающего этапа. Получив этот сигнал, приложения могут с помощью системных вызовов DLPAR узнать, какая операция выполняется, и предпринять необходимые действия.

Прим.: Если приложения не будут блокировать сигналы, то загрузка системы может привести к нарушению синхронизации нитей. Приложение должно ждать в течение короткого периода времени, а затем переходить к следующему этапу. Ждать неограниченное время не рекомендуется, вся операция DLPAR может быть отменена из-за зависшей непривилегированной нити.

Для правильной доставки сигналов приложение может использовать маску сигналов и приоритет планирования. Код, поддерживающий DLPAR, может быть напрямую встроен в алгоритм. Кроме того, обработчик сигналов может состоять из модулей, находящихся в разных подключаемых библиотеках.

Для обработки события DLPAR с помощью API выполните следующие действия:

Отслеживайте сигнал SIGRECONFIG с помощью системного вызова sigaction. По умолчанию этот сигнал игнорируется.
Контролируйте маску сигнала как минимум в одной нити, чтобы сигнал доставлялся в реальном времени.
Убедитесь, что приоритет нити, получающий сигнал, достаточен для быстрой обработки полученного сигнала.
С помощью системного вызова dr_reconfig узнайте тип ресурса, тип действия, этап события и другую необходимую информацию.
Прим.: Системный вызов dr_reconfig применяется внутри обработчика для определения цели запроса DLPAR.