Виктор Кустов - Руководство администратора баз данных Inrformix. Страница 4

В версии 6.0 сетевые функции заложены в ядре СУБД. Поэтому для функционирования в сети OnLine Dynamic Server модули Informix-Net или Informix-Star не требуются.

2.2 Архитектура СУБД сервера Informix OnLine v.7.X

К СУБД, претендующим на роль информационной основы современных предприятий, предъявляются все новые и более жесткие требования. К числу важнейших можно отнести следующие:

1. высокая производительность

2. масштабируемость

3. смешанная загрузка сервера разными типами задач

4. непрерывная доступность данных

Данный раздел посвящен, главным образом, рассмотрению архитектурных особенностей и механизмов сервера INFORMIX-OnLine DS, направленных на удовлетворение перечисленных выше требований. Приводится также информация о средствах распределенных вычислений, безопасности, поддержки национальной среды.

2.2.1 . Динамическая масштабируемая архитектура

Архитектура сервера INFORMIX-OnLine DS получила название "динамическая масштабируемая архитектура" (DSA). Суть ее заключается в том, что одновременно выполняется относительно небольшое число серверных процессов (виртуальных процессоров), которые разделяют между собой работу по обслуживанию множества клиентов. По сравнению с более ранними моделями сервера INFORMIX, где для каждого клиента создавался индивидуальный серверный процесс (рис. 1), новая модель обладает рядом преимуществ:

1. снижение нагрузки на операционную систему (число серверных процессов невелико);

2. сокращение совокупной потребности клиентов в оперативной памяти;

3. снижение конкуренции при одновременном использовании системных ресурсов;

4. более рациональное по сравнению с ОС назначение приоритетов и планирование;

Для многопроцессорных платформ:

1. равномерная загрузка наличных процессоров;

2. ускорение обработки сложных запросов за счет параллельного выполнения на нескольких процессорах.

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

Архитектура DSA полностью использует возможности симметричных многопроцессорных платформ SMP (Symmetric Multiprocessing systems), и может работать на однопроцессорных платформах. В последующих версиях предполагается расширить архитектуру сервера, обеспечив поддержку слабосвязанных систем и систем с массовым параллелизмом (MPP). Все базовые технологии DSA являются встроенными, они включены в библиотеки сервера, и их применение не зависит от особенностей ОС или аппаратных платформ различных поставщиков.

2.2.1.1 Потоки

Архитектуру INFORMIX-OnLine DS называют также многопотоковой. Для каждого клиента создается так называемый поток, или нить (thread). Поток - это подзадача, выполняемая в рамках одного из серверных процессов.

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

INFORMIX-OnLine DS не полагается на механизмы потоков, имеющиеся в некоторых операционных системах. Он формирует потоки, специфичные для задач обработки баз данных, оптимальные в отношении выделяемой под них памяти, методов планирования и числа инструкций, затрачиваемых на переключение между потоками.

2.2.1.2 Виртуальные процессоры

Виртуальным процессором называется процесс сервера баз данных. Виртуальный процессор можно сравнить с операционной системой. Поток по отношению к нему выступает как процесс, подобно тому, как сам виртуальный процессор является процессом с точки зрения операционной системы.

Виртуальные процессоры (ВП) являются специализированными - они подразделяются на классы в соответствии с типом потоков, для выполнения которых они предназначены. Примеры классов ВП:

CPU - Потоки обслуживания клиентов, реализуют оптимизацию и логику выполнения запросов. К этому классу относятся и некоторые системные потоки.

AIO - Операции асинхронного обмена с диском.

ADM - Административные функции, например, системный таймер.

TLI - Контроль сетевого взаимодействия посредством интерфейса TLI (Transport Layer Interface).

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

Начальное число виртуальных процессоров каждого класса, создаваемых при запуске INFORMIX-OnLine DS, задается в конфигурационном файле. Однако, потребности в каждом виде обработки не всегда предсказуемы. Инструменты администрирования позволяют динамически, не останавливая сервер, запустить дополнительные виртуальные процессоры. Например, если растет очередь потоков к виртуальным CPU-процессорам, то можно увеличить их число. Точно так же, возможно добавление виртуальных процессоров обмена с дисками, сетевых процессоров взаимодействия с клиентами, создание процессора обмена с оптическим диском, если он отсутствовал в начальной конфигурации. Динамически сократить можно только число виртуальных процессоров класса CPU.

На некоторых мультипроцессорных платформах, где OnLine DS поддерживает родство процессоров (processor affinity), допускается привязка виртуальных CPU-процессоров к определенным центральным процессорам компьютера. В результате производительность виртуального CPU-процессора повышается, поскольку операционная система реже производит переключение процессов. Привязка позволяет также изолировать работу с базой данных, выделяя для этой цели определенные процессоры, в то время как остальные будут заняты другими задачами.

2.2.1.3 Планирование потоков

Сервер осведомлен о степени значимости различных потоков и в соответствии с этим назначает для них приоритеты. Например, потоки ввода-вывода получают приоритеты следующим образом:

1. ввод-вывод логической журнализации - наивысший приоритет;

2. ввод-вывод физической журнализации - второй по значимости приоритет;

3. прочие операции ввода-вывода- низший приоритет.

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

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

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

1. когда он временно не может выполняться, например, если необходимо дождаться завершения обмена с диском, ввода данных от клиента, снятия блокировки.

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

2.2.1.4 Разделение потоков между виртуальными процессорами.

Для каждого класса поддерживаются три очереди потоков, которые разделяются всеми виртуальными процессорами данного класса:

Очередь готовых к выполнению потоков.Очередь спящих потоков. В нее помещается, например, CPU-поток, которому требуется доступ к диску. Предварительно CPU-поток порождает запрос на обмен с диском, для обслуживания которого формируется AIO-поток. Завершив обмен с диском, AIO-поток оповещает об этом виртуальный процессор CPU, который "будит" спящий CPU-поток и перемещает его в очередь готовых потоков.Очередь ждущих потоков. Эта очередь служит для координации доступа потоков к разделяемым ресурсам. В нее помещаются потоки, ожидающие какого-либо события, например, освобождения заблокированного ресурса. Когда поток, заблокировавший этот ресурс, готов освободить его, просматривается очередь ждущих потоков. Если в ней есть поток, ожидающий именно этот ресурс, то он перемещается в очередь готовых.

Если выполняемый поток завершается, засыпает или откладывается, то освободившийся виртуальный процессор выбирает из очереди готовых очередной поток с наивысшим приоритетом. Как правило, OnLine DS стремится выполнять поток на одном и том же виртуальном процессоре, поскольку передача его другому процессору требует пересылки некоторого объема данных. Тем не менее, если поток готов к выполнению, он может быть продолжен другим процессором, с целью исключения простоев и обеспечения общего баланса загрузки.