МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ (Дополнительные методические материалы)

Методические рекомендации по использованию

КИСП (КСАМ)

Руководитель разработки:

Ю. А. Григорьев

НИИ ИСУ МГТУ им. Н.Э. Баумана

2000 г.

Содержание

1. Обоснование выбора входных параметров КИСП…………………………….... 3

2. Обоснование выходных характеристик КИСП

для оценки КСА АС ВН……………………………………………………………. 4

3. Описание способов включения и адаптации КИСП к новой конфигурации

сервера, отсутствующей в реестре КИСП………………………………………... 6

4. Методика анализа с помощью КИСП комплексов средств автоматизации,

построенных на файлах…………………………………………………………..... 9

5. Раздельный анализ загрузки процессора и диска………………………………... 10

Литература………………………………………………………………………….. 11

1. Обоснование выбора входных параметров КИСП

Программный комплекс включает взаимосвязанные подсистемы, обеспечивающие описание:

1. концептуальной (инфологической) схемы базы данных КСА АС ВН и наполнения базы данных (прогнозируемое число записей в таблицах и мощности атрибутов),

2. запросов (SQL-операторов) и транзакций КСА, которые могут обращаться к другим транзакциям распределённой системы,

3. архитектуры КСА (топологии и характеристик узлов и сетей из реестров результатов тестов TPC и параметров сетей),

4. распределения таблиц (с учетом тиражирования) и транзакций по узлам КСА АС ВН,

5. интенсивностей обращений рабочих станций к транзакциям и транзакций к транзакциям.

Выбор перечисленных выше параметров объясняется тем, что они существенно влияют на временные показатели качества КСА.

Параметры схемы базы данных и её наполнения влияют на объём данных, используемых приложениями при выполнении операторов обращений к базе данных. Эти параметры определяют число блоков индексов и таблиц, читаемых или обновляемых прикладными программами. Они существенно влияют на загрузку дисков КСА.

Запросы и транзакции КСА определяют процессы обработки данных. Именно здесь указывается, как и какие данные обрабатываются. Параметры запросов и транзакций влияют на число читаемых или обновляемых записей базы данных. В зависимости от параметров запроса может быть прочитана из БД одна запись или вся таблица. Очень часто именно запросы к БД являются узким местом автоматизированной системы.

Архитектура КСА (топология, характеристики узлов и сетей) также существенно влияет на временные характеристики функционирования системы. Иногда КСА сравнивают со стаканом воды. Собственно под стаканом (оболочкой) подразумевают технические средства системы и общесистемные пакеты, которые меняются редко в действующей системе. А с водой (содержимым стакана) связывают количество рабочих станций, наполнение базы данных, приложения, которые подвержены частым изменениям. В процессе функционирования системы растёт число станций, наполняется база данных, добавляются новые приложения (стакан наполняется). Начиная с какого-то момента, рост нагрузки на КСА может превысить возможности технических средств и система начнёт пробуксовывать (вода выливается из стакана). В силу невозможности выполнить натурное моделирование архитектуры на начальных этапах проектирования очень важно именно с помощью математической модели оценить возможности выбираемых технических средств на перспективу, т. е. при увеличении нагрузки на систему, росте наполнения базы данных, добавлении новых приложений и др.

Правильное распределение таблиц (с учетом тиражирования) и транзакций по узлам КСА АС ВН также является важной задачей. Отсутствие дублирующих таблиц может привести к росту числа обращений к требуемым данным, расположенным на удалённых узлах, что может вызвать перегрузку телекоммуникационных каналов связи. С другой стороны, большое число дублей приводит к росту объёма тиражируемых данных, что также перегружает каналы связи. Использование КИСП может помочь найти компромиссное решение.

Интенсивности обращений рабочих станций к транзакциям и транзакций к транзакциям определяют нагрузку на ресурсы КСА: процессоры, диски, шины ЛВС, каналы связи. Большая интенсивность может привести к перегрузке ресурсов. Известно, что максимальная загрузка шины Ethernet не должна превышать 0.32 (это связано с коллизиями), а загрузка процессора и диска должна быть меньше 0.6.

2. Обоснование выходных характеристик КИСП для оценки КСА АС ВН

Показатели качества автоматизированных систем условно можно разделить на две группы [1]: количественные и качественные. Количественных показателей немного, это - характеристики производительности (эффективности использования ресурсов [2]), надёжности и стоимости. Качественных показателей намного больше, можно выделить следующие группы [2]:

• функциональная пригодность (пригодность для применения, точность, защищённость, способность к взаимодействию, согласованность со стандартами и правилами проектирования),

• применимость (понятность, обучаемость, простота использования),

• сопровождаемость (удобство для анализа системы, изменяемость, стабильность, тестируемость),

• переносимость (адаптируемость, структурированность, замещаемость, внедряемость),

• функциональные показатели качества информации БД (полнота накопленных в БД описаний объектов, достоверность данных, безошибочность данных, актуальность данных) и др.

В [3] отмечается, что способность к логическим обобщениям и решениям в неопределённых ситуациях, способность к анализу событий, распределённых во времени и в пространстве, и их распознаванию более характерны для человека, чем для компьютера. Т. е. проектировщик КСА оценивает качественные показатели намного адекватнее. Анализ системы КОК [4] показывает, что попытка количественно оценить качественные показатели приводит к неутешительным результатам.

Действительно, в [4] для оценки вероятности отсутствия воздействий в результате несанкционированного доступа к информационным и программным ресурсам необходимо задать функцию распределения времени расшифровки злоумышленником значений параметров -й преграды системы защиты КСА. Конечно, получить устойчивые статистики для оценки вряд ли возможно, а поэтому формулу для нельзя считать адекватной. Тем более, что степень обеспечения конфиденциальности очень трудно оценить количественно, т. к. этот показатель является качественным и определяет, что засекреченная информация должна быть доступна только тому, кому она предназначена [2]. Если необходимо дать количественную оценку, то правильнее было бы говорить о влиянии программных и технических средств защиты от несанкционированного доступа на временные показатели КСА.

С другой стороны вычислительные возможности у компьютера существенно выше, чем у человека [3]. Поэтому для сложных расчётов количественных показателей лучше использовать компьютерные инструментальные средства. Например, при создании распределённых КСА большое значение имеет анализ временных характеристик. Но даже опытному проектировщику КСА бывает очень трудно спрогнозировать их значения, т. к. временные показатели зависят от большого числа параметров, выбираемых на ранних этапах проектирования распределённой системы. На индексы производительности влияют параметры концептуальной схемы базы данных, спецификаций разрабатываемых программ, архитектуры будущей системы (модели доступа к данным, комплекса технических средств, операционной системы, системы управления базой данных), наполнения базы данных. Более того, для выполнения расчётов необходимо знать достаточно сложные математические методы анализа автоматизированных систем. Поэтому важно дать проектировщику, выполняющему разработку в среде СУБД, инструмент, позволяющий прогнозировать временные показатели распределённых систем и выявлять потенциальные "узкие места" КСА на основе описаний проектных решений. Это особенно важно, если учесть, что основной язык (SQL) доступа к данным относится к классу непроцедурных языков. Неосторожное использование спецификаций этого языка может привести к существенному увеличению времени реакции системы. Следует также отметить, что характеристики надёжности часто можно свести к показателям производительности [5], т. к. отказы системы приводят к дополнительным временным задержкам, которые связаны с ожиданием восстановления системы после сбоев.

Поэтому в КИСП оцениваются временные показатели функционирования КСА. Более того, временные характеристики раскладываются на составляющие (по узлам, сетям, запросам и транзакциям) с целью выявления узких мест системы и их дальнейшего устранения в проекте.

3. Описание способов включения и адаптации КИСП к новой конфигурации сервера, отсутствующей в реестре КИСП

Можно предложить два способа включения в КИСП новой конфигурации:

1. Провести тесты по спецификациям TPC-C (www.tpc.org) и полученные данные ввести в БД КИСП (форма "Описание конфигураций узлов"). Чтобы воспользоваться этим способом, необходимо иметь требуемые средства для тестирования, которые применяются в организации TPC (Transactional Processing Performance Council).

2. Провести серию натурных экспериментов и воспользоваться методикой,

рассмотренной ниже.

Рассмотрим второй вариант. В этом случае для новой конфигурации сервера базы данных и приложений в базу данных КИСП необходимо включить следующие параметры:

• размер диска - форма "Описание конфигураций узлов" (1-е дополнительное окно - характеристики сервера),

• размер блока диска - форма "Описание конфигураций узлов" (1-е дополнительное окно - характеристики сервера),

• время на блок - форма "Описание конфигураций узлов" (3-е дополнительное окно - результаты тестов TPC-C),

• время обработки одной записи курсора - форма "Описание конфигураций узлов" (3-е дополнительное окно - результаты тестов TPC-C).

Первые два параметра - это размер диска и размер блока диска сервера базы данных. Они оцениваются достаточно просто.

Для определения двух других параметров необходимо провести на новой конфигурации серию экспериментов (не менее 3-х).

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

, (1)

где

- оцениваемый параметр "время на блок",

- оцениваемый параметр "время обработки одной записи курсора",

- оцениваемый параметр "производительность шины связи между сервером и рабочей станцией, где выполнялись приложения". Если приложения выполнялись на самом сервере базы данных, то 3-е слагаемое в формуле (1) следует опустить,

- число блоков базы данных, к которым обращалась транзакция,

- число записей курсора, обработанных транзакцией,

- объём данных, переданных по шине, в процессе выполнения транзакции.

Величину можно получить на основе статистик, собираемых СУБД. Например, в Oracle для этой цели можно использовать следующий оператор: