Планирование мощности системы

Исторический обзор планирования мощности

Во времена многопользовательских ЭВМ концепции планирования мощности и производительности не были осознаны и не получили развития. В начале 1970-х годов предварительное планирование мощности заключалось лишь в поиске потребителей, применявших приложения, которые "работали бы так же", как и нужное приложение. Находить таких потребителей было трудно, а сравнивать фирмы и организации и как у них работают приложения – еще труднее.

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

Во время этого периода аналитики создавали методики для предсказания использования ресурсов существующих систем. Внешне этот процесс казался менее интересным, но он оказался таким же сложным, так как не существовало ни методик тестирования, ни инструментальных средств для сбора нужных данных. Ученые-компьютерщики (такие как д-р Джеффри Бузен [Jeffrey Buzen] – родоначальник теории планирования мощности) еще только разрабатывали теории об использовании ресурсов компьютеров и исследовали вопрос, как можно выполнять эти вычисления.

С 1980-х годов первоначальные тестовые модели развились в тесты стандартных нагрузок, такие как тесты ST1, TP1 и Debit/Credit, но усилия в то время были направлены на выявление аппаратуры с наивысшей производительностью для рекламных целей, а не на разработку стандартных моделей нагрузки от приложений, которые можно было бы использовать при предварительном планировании и поддержке систем. Потребители еще не могли пользоваться этими тестами для сравнения аппаратуры систем, потому что они работали в различных ситуациях. В ответ на эти нужды потребителей возник консорциум представителей компьютерной промышленности, "Совет по производительности обработки транзакций" (Transactional Processing Performance Council). Этот Совет задал стандарты обработки транзакций для более чем 45 производителей оборудования и программного обеспечения. Эти тесты часто могут показать относительные возможности оборудования и программного обеспечения для баз данных; к сожалению, они не могут помочь при предварительном планировании нагрузки от работы приложений.

В это самое время подоспела архитектура "клиент/сервер" и технология реляционных баз данных, и потребность в предварительной оценке размера системы и в планировании мощности возросла. Большинство из современных приложений сейчас пишутся на основе архитектуры "клиент/сервер". Серверы обычно используют устройства для централизованного хранения данных, а пользовательский интерфейс обычно исполняется локально на настольных компьютерах пользователей или на удаленном веб-сайте. Эта экономная стратегия использования дорогих мощностей для обработки данных на сервере имеет еще одно достоинство: пользователи работают в уже привычных для них графических интерфейсах. Так как серверы, на которых работают приложения доступа к базам данных, используются очень интенсивно, то именно им уделяется основное внимание в большинстве проектов предварительного планирования мощности и исследований последующего планирования мощности.

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

Обработка транзакций

В данном разделе мы изучим, как выполнять анализ тенденций использования сервером базы данных ресурсов процессоров, памяти и дисков. Это нужно, чтобы правильно выбирать систему для нужного приложения. Сервер базы данных выполняет только функции работы с базой данных: при своей работе этот сервер выполняет только транзакции. При исполнении оператора SELECT или UPDATE сервер базы данных интерпретирует данные операторы как последовательности операторов чтения и записи. На самом деле, любая транзакция может быть разбита на чтения и записи в базу данных. На этом атомарном уровне сервер базы данных обрабатывает операции ввода-вывода. Нужно выбрать систему, способную обращаться с транзакциями различных видов и объемов, и с порождаемыми ими операциями ввода-вывода. Основными типами транзакций являются системы оперативной обработки транзакций (OLTP, on-line transaction processing) и системы поддержки принятия решений (DSS, decision support system).

Транзакции систем оперативной обработки транзакций

Транзакции систем оперативной обработки транзакций (OLTP) являются компонентами рабочей нагрузки, исполнение которых ожидается за короткие промежутки времени, так как они взаимодействуют с базой данных в режиме реального времени или в режиме "он-лайн". Другими словами, эти транзакции будут непрерывно обновлять базу данных, основываясь на наиболее свежей доступной информации, чтобы следующий пользователь мог бы быть уверен в том, что эта информация является наиболее свежей. Например, в системе ввода заказов вся информация, относящаяся к складскому учету, хранится в таблицах, распределенных по дисковой системе, и база данных может работать в режиме "он-лайн". Доступ к информации в базе данных получает каждый пользователь. Таблицы базы данных, такие как Таблица_изделий или Таблица_складских_запасов, содержат наиболее свежую информацию о разновидностях и об имеющемся количестве продаваемых товаров. Таким образом, когда поступает заказ на некоторое количество какого-либо товара, вы можете произвести доступ к таблицам базы данных, чтобы выяснить, имеется ли этот товар и сколько его осталось на складе, чтобы не продать отсутствующий товар.

Типичный сценарий предварительного планирования мощности для подобных систем обработки транзакций для сбора специальной информации предусматривает опрос людей. Вы должны провести беседы с проектировщиком базы данных, с разработчиком приложения и с представителем управленческого персонала. Эти люди могут дать начальные и корректирующие сведения о предполагаемом объеме обрабатываемых транзакций и о времени суток, когда предполагается обработка этих транзакций (например, 25 тысяч транзакций должны быть обработаны в течение 8-часового рабочего дня), сведения о количестве одновременно работающих пользователей, о времени пиковой нагрузки (времени суток, когда нагрузка на систему максимальна). Возможно, эти опросы окажутся самой важной частью процесса предварительного планирования мощности.

Транзакции систем поддержки принятия решений

Другим типом систем обработки транзакций являются системы поддержки принятия решений (DSS). Транзакции систем поддержки принятия решений возвращают большие объемы информации и требуют для своей обработки гораздо больше времени, чем транзакции OLTP. Для обработки транзакции DSS могут понадобиться часы или даже дни. В качестве примера системы поддержки принятия решений можно привести архив складских запасов, запись в который производится редко, только при его обновлениях. Такие системы обычно снабжают информацией сотрудников-управленцев, чтобы они могли принимать важные решения, например, о развитии бизнеса или о необходимом уровне складских запасов. В качестве другого примера можно привести используемую военно-воздушными силами США систему поддержки принятия решений, информирующую руководящий состав ВВС о текущем состоянии, расположении и вооружении реактивных истребителей, бомбардировщиков и людей.

Как мы уже говорили, транзакции DSS обычно не завершаются за то же время, что и транзакции OLTP. Транзакции DSS обрабатываются гораздо дольше, потому что они извлекают гораздо больший объем данных. Так как транзакции OLTP извлекают необходимые данные по уникальному ключу (например, по номеру потребителя), то они начинают и завершают запрос с информацией, относящейся только к этому ключу. У транзакций DSS запрос не начинается с уникального ключа, наоборот, он начинает работу от начала таблицы базы данных и продолжает работать, пока не просмотрит все данные в базе данных. Транзакции DSS также включают в себя соединения таблиц, связываясь для получения дополнительной информации с другими таблицами.

Как знают системные аналитики, в системах этого типа обычно достигается 100-процентное использование центрального процессора и других системных ресурсов, поэтому вопрос состоит не в загрузке системы работой, а в сроках обработки запросов системой. Есть такое практическое правило при проектировании систем DSS: распределяйте, насколько это возможно, систему по имеющемуся оборудованию. Другими словами, вы должны не просто иметь количество дисков, достаточное для того, чтобы база данных помещалась бы на них, а спланировать размещение базы данных по многим томам, чтобы рассеять по ним активность ввода-вывода. Насчет оперативной памяти в этом отношении никакие подобные меры не понадобятся, потому что кэширование к ней почти не применяется. (Для обработки транзакций DSS потребуются полные сканирования таблиц, т.е. просмотр таблиц будет начинаться от их начал и продолжаться пока они не будут полностью обработаны.)

Принципы планирования мощности

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

Если вы знаете максимальное количество транзакций, которые будут выполняться в течение рабочего дня и знаете длительность рабочего дня, то вы сможете подсчитать среднее количество транзакций за единицу времени. Однако, так как вы не знаете истинного темпа, в котором будут поступать транзакции, то предварительное планирование мощности системы надо выполнять с "встроенным" резервом мощности. Та часть мощностей системы, которая оставлена как резерв на периоды повышенной рабочей нагрузки, называется резервная мощность.

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

Использование мощности центрального процессора

Еще одна причина, по которой надо создавать и поддерживать резерв мощности компьютера, связана с теорией "загиба кривой" (knee of the curve theory). Если объяснять просто, эта теория предсказывает, что загруженность системы работой непосредственно влияет на образование очередей, а так как длина очередей непосредственно связана со временем отклика (фактически, длина очередей является частью формулы для расчета времени отклика), то загруженность системы оказывает непосредственное влияние на время отклика. Загибом кривой называется точка, начиная от которой такие показатели, как время отклика или длительность очередей, переходят от линейного роста к экспоненциальному или асимптотическому (с уходом в бесконечность при приближении нагрузки к некоторому конечному значению) росту.

Сравнение линейного и экспоненциального роста

Обычно мы стремимся добиться, чтобы система работала в линейном режиме, т.е., чтобы рост очередей был бы линейным. Из рисунка 6-1 видно, что линейный рост является равномерным ростом очередей в зависимости от роста загруженности системы. Согласно одному практическому правилу, рост очередей остается линейным, пока центральный процессор используется не более чем на 75%.

Впрочем, иногда при установившемся режиме центральный процессор может быть загружен и более чем на 75%. У такой работы имеются некоторые недостатки – в частности, из-за такой высокой загруженности рост длины очередей может стать экспоненциальным. Экспоненциальный рост – это рост в геометрической прогрессии (см. рис. 6.2).

Обратите внимание, что при загруженности центрального процессора, превышающей 75%, кривая зависимости длины очередей переходит от линейного роста к экспоненциальному (т.е. кривая превращается почти в вертикальную линию).

Время отклика

График на рис 6.3 показывает, как использование мощностей центрального процессора влияет на время отклика. Обратите внимание на то, как похожи графики времени отклика и длины очереди. Наличие на обоих графиках точек загиба, после которых происходит резкое увеличение времени отклика, показывает, что никогда не следует применять установившийся режим с загруженностью центрального процессора более 75%. Это не значит, что процессор никогда не будет работать с загруженностью более 75%, но чем дольше это будет происходить, тем больше негативных последствий вызовет (в отношении длины очередей и длительности отклика).

Недопущение выхода за точку загиба кривой (в нашем примере – 75% мощности процессора) является одним из наиболее важных принципов предварительного планирования мощности, и его нужно соблюдать при определении количества центральных процессоров, нужных для вашей системы. Например, допустим, при предварительном планировании мощности системы, вы оценили, что потребность в ресурсе процессора составит 180% от мощности процессора. Вы можете мучиться из-за очень плохой производительности, а можете запустить два процессора с 90% загруженностью их мощности (на 15% выше точки загиба кривой). Но еще лучше было бы запустить три процессора, загрузив их на 60% мощности, тогда их загруженность будет на 15% ниже точки загиба кривой.

Этот же принцип применяется и к другим элементам системы, например, к дискам. У графиков для дисков точка загиба расположена не так, как у графиков для процессоров, она находится где-то при 85% загруженности их мощности. Эта пороговая величина (85%) относится и к вместимости, и к производительности ввода-вывода дисковых накопителей. Например, 9 Гб диски не должны содержать более 7,65 Гб данных, хранящихся на нем одновременно. Это ограничение на объем хранимых данных может послужить как резерв для роста, но оно более важно для сокращения времени отклика, потому что время поиска для дисков, заполненных полностью, становится больше, увеличивая тем самым суммарное время отклика. В соответствии с этим же правилом, если дисковый накопитель имеет производительность обмена данными 70 операций ввода-вывода в секунду, то его не следует применять в условиях, когда темп ввода-вывода постоянно превышает 60 операций ввода-вывода в секунду (при установившемся режиме работы). Следуя этим правилам, вы сможете минимизировать суммарное время отклика и получить наибольшую производительность своей системы, так как ваши процессоры и диски используются не с полной загруженностью. Кроме того, ваша система сохранит резервы мощности, которые пригодятся при работе в периоды пиковых нагрузок.

Обращения к отсутствующим страницам виртуальной памяти

Для процессора и дисков надо не допускать превышения их загруженности выше точки загиба, это важный принцип предварительного планирования мощности. А что можно сказать о памяти? Для предварительного планирования памяти нужно рассмотреть обращения к отсутствующим страницам виртуальной памяти (page faulting). Обращения к отсутствующим страницам – это нормальное явление при обычном функционировании системы, оно применяется для доступа к данным на диске. Если системе потребуется что-нибудь из памяти (страница с кодом программы или с данными) и будет иметься нужная страница памяти, то произойдет логическое событие ввода-вывода, означающее, что код или данные считываются из памяти, и транзакция, которой понадобился этот программный код или данные, будет обработана.

А что произойдет, если нужного кода или страницы с данными не окажется в памяти? В этом случае придется выполнить физический ввод-вывод и прочитать нужную страницу с диска. Эта задача выполняется при помощи обращения к отсутствующей странице. Система, если в ее рабочем наборе оперативной памяти не найдется нужная страница с кодом программы или с данными, выдаст прерывание обращения к отсутствующей странице (page fault interrupt). Обработка обращения к отсутствующей странице прикажет другой части системы доставить программный код или данные с физического диска. Другими словами, если нужная вашей системе страница с кодом или данными отсутствует в памяти, то система выполнит обращение к отсутствующей странице, которое прикажет другой части системы выполнить физическую операцию ввода-вывода и доставить нужную страницу с диска. Обращение к отсутствующей странице не повлечет доставку нужной страницы с диска, если эта страница находится в списке резерва (standby list) и, следовательно, уже находится в оперативной памяти, или если она находится в пользовании у другого процесса, с которым она может совместно использоваться (разделяться).

Существует два типа ввода-вывода: пользовательский и системный. Пользовательский физический ввод-вывод происходит, когда пользовательская транзакция просит прочитать данные, которые нашлись в памяти. Происходит простая передача данных с диска в память. Такая передача данных обычно выполняется какой-либо программой для управления потоком данных (data flow manager), дополненной функциональными возможностями контроллера дисков. Системный физический ввод-вывод происходит, когда система запрашивает страницу с программным кодом, нужным для выполняемого ею процесса, а этой страницы нет в памяти. Тогда система выдает прерывание обращения к отсутствующей странице, препятствующее продолжению работы до тех пор, пока с диска не будет доставлена нужная страница. После доставки этой страницы обработка будет продолжена. Обе эти разновидности физического ввода-вывода удлиняют время отклика, потому что время, необходимое на доставку данных из оперативной памяти, занимает микросекунды (миллионные доли секунды), а физический ввод-вывод занимает миллисекунды (тысячные доли секунды). Так как обращения к отсутствующим страницам вызывают физический ввод-вывод, который увеличивает длительность времени отклика, то при минимизации обращений к отсутствующим страницам будет достигаться лучшая производительность системы.

В вашей системе могут возникать три типа обращений к отсутствующим страницам:

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

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

Страничный обмен. При внесении изменений в страницу данных (в результате чего она становится "недействительной" (dirty page, "черновой" страницей)), производится двухэтапный обмен страниц (page fault swap), при котором система не только доставляет новые данные с диска, но и записывает измененные данные из памяти на диск. Для выполнения этого двухэтапного обращения к отсутствующей странице потребуется две физических операции ввода-вывода, но это гарантирует сохранение всех измененных данных. Если обмен страниц будет происходить слишком часто, то он может стать единственным наиболее значительным фактором, ухудшающим длительность времени отклика. Помните, что при обмене страниц происходит передача данных целиком всей страницы, даже если на самом деле нужно передать лишь несколько байтов. Обмены страниц, вызванные обращениями к отсутствующим страницам, требуют больше времени, чем просто обращения к отсутствующим страницам, потому что для них требуется по два физических ввода-вывода. Поэтому вы в своей системе должны стараться минимизировать количество обменов из-за обращений к отсутствующим страницам.

Когда вы для новой системы оцениваете ее минимальную потребность в оперативной памяти, всегда пытайтесь предугадать общий объем памяти, необходимой для обработки рабочей нагрузки, для чего следует обратиться к спецификациям с требованиями к памяти всех процессов, которые будут работать на вашей системе (включая операционную систему и программы управления базой данных). И не забывайте про обращения к отсутствующим страницам. Для работы с памятью системы нужно собирать информацию о происходящих обращениях к отсутствующим страницам и хранить эту информацию в качестве составной части базы данных о производительности. Чтобы определить, когда понадобится добавить в систему дополнительную память, следует применить упреждающий анализ. На случай пиковых нагрузок следует сохранять достаточно большой объем резервной памяти. При планировании системы постарайтесь предусмотреть резерв памяти, составляющий от 5 до 10 процентов от памяти, необходимой для работы процессов.

Планирование мощности памяти

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

Сервер базы данных обрабатывает запросы от пользователей и доставляет информацию, необходимую для выполнения транзакций. Чтобы спланировать оперативную память сервера базы данных, вы должны знать число пользователей, одновременно соединяющихся с системой, и количество транзакций ввода-вывода, возникающих из-за этих пользователей. Этот ввод-вывод имеет форму операций чтения и записи. Беседа с проектировщиком приложения нужна, чтобы получить информацию о различных транзакциях и о генерируемых ими операциях ввода-вывода.

Рассчитывая объем памяти, нужной для вашей системы, вы также должны учесть такие характеристики, как желательную частоту удачных обращений к кэшу и обращений к отсутствующим страницам. Рассмотрим типичный сценарий: вы участвуете в проектировании системы для сервера базы данных, которая будет применяться для заказов в режиме реального времени, и вам надо знать количество одновременно работающих пользователей, из-за которых возникает рабочая нагрузка. Эта информация поможет вам определиться с необходимым вам объемом оперативной памяти. Например, вы знаете, что в каждый момент времени с системой будут одновременно работать 50 пользователей. Для такой системы вам потребуется 25 Мб памяти только для пользователей.

Затем вам надо знать, какую операционную систему вы будете применять. В нашем случае эта операционная система – Microsoft Windows 2000, для которой нужно 20 Мб памяти. Поэтому теперь вам понадобится уже 45 Мб памяти. Вам также надо будет узнать размер программы базы данных, которая будет у вас работать, в нашем случае – Microsoft SQL Server, для которого нужно 5,5 Мб памяти. Итого теперь требуется 50,5 Мб памяти.

И последняя информация, которая вам понадобится, – размер области памяти для обработки базы данных. Эта область состоит из двух элементов: области журнала и кэша базы данных. Область журнала содержит информацию о выполняющихся действиях записи. Эта область очень важна, потому что в случае сбоя системы во время исполнения транзакции в ней сохранится информация для восстановления образа данных перед транзакцией, т.е. образа базы данных, бывшего до того, как произошел сбой. Область журнала имеет также названия "аудиторский след", "контрольный журнал" (audit trail).

Кэш базы данных представляет собой специальную область вашей системы. Через нее передаются все данные, обрабатываемые вашей системой. Чем кэш крупнее, тем больше будет процент успешных обращений к нему (попаданий в кэш). Процент успешных обращений к кэшу – это вероятность, с которой ваша система находит нужные данные в оперативной памяти; очевидно, что вы хотели бы иметь максимально большой процент попаданий в кэш. Обращения к данным, отсутствующим в кэше, похожи на обращения к отсутствующим страницам памяти тем, что нужная информация должна быть доставлена системой и помещена в память кэша. Поэтому, если область кэша окажется слишком маленькой, то будет происходить физический ввод-вывод, потому что системе придется обращаться к диску и доставлять данные, отсутствующие в кэше. Этот физический ввод-вывод, несомненно, увеличит время отклика для транзакций.

Для расчета размера кэша воспользуйтесь следующей формулой:

размер кэша  =  (размер блока кэша) х (количество блоков в кэше)

Размер блока кэша – это объем данных, передаваемых при одной операции ввода-вывода. Помните, что в SQL Server уже задан стандартный размер блока кэша, равный 8 КБ. Количество блоков в кэше – это просто выбираемый вами размер кэша (в блоках). Для систем оперативной обработки транзакций (OLTP) размер блока следует выбирать поменьше, потому что объем передаваемых данных – небольшой, а чем меньше объем передаваемых данных, тем меньше будет и время, необходимое для исполнения транзакции. В системах поддержки принятия решений (DSS) размер блока должен быть гораздо больше, потому что объем передаваемых данных будет гораздо больше, из-за чего уменьшится количество операций ввода-вывода.

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

минимальная память = (системная память) + (пользовательская память) + 
  +(память процесса базы данных)

Здесь системная память – это объем памяти, необходимой для операционной системы и SQL Server, пользовательская память – это по 500 Кб памяти, выделяемых каждому из одновременно работающих пользователей, а память процесса базы данных – это память, необходимая для журнала и кэша.

Эта простая формула может применяться для расчета минимального необходимого объема памяти, нужного для нормальной работы как приложений оперативной обработки транзакций (OLTP), так и для систем поддержки принятия решений (DSS). Для систем DSS нужно выбирать более крупные размеры блоков кэша, потому что приложения DSS выполняют полное сканирование таблиц в режиме последовательного чтения. Увеличив размер блока, можно увеличить количество записей, считываемых за одну физическую операцию ввода-вывода. Для систем DSS кэш не используется, потому что все операции ввода-вывода будут физическими.

Для приложений оперативной обработки транзакций (OLTP) после инсталляции системы вы должны следить за процентом удачных обращений к кэшу. Высокий процент удачных обращений к кэшу поможет вам добиться наилучшего времени отклика и производительности для своей системы.

Сбор данных об использовании памяти

После того как система, для которой производилось предварительное планирование, будет сконфигурирована и настроена, вам надо будет методично собирать данные об использовании ее памяти. Эти данные можно использовать для проверки соответствия созданной вами системы требованиям соглашения об уровне обслуживания, таким как время отклика или загруженность памяти и центрального процессора. Данные можно собрать при помощи просто Microsoft Performance Monitor (Монитора производительности) для среды Microsoft Windows NT.

Помните, что данное исследование является анализом для планирования производительности и поэтому должно производиться достаточно долго. Измерения будут длиться часами (в большинстве случаев – 24 часа), и интервал измерений тоже должен быть установлен равным 24 часам. Для задач планирования производительности нужно заносить в базы данных о производительности по одной записи в сутки. Критерии производительности, называющиеся счетчики (counters), выбираемые вами для мониторинга, будут усредняться по интервалам измерений. Счетчики для планирования мощности памяти, находятся в объекте Memory (в "мониторе производительности" объектом называется набор счетчиков).

Среди счетчиков монитора производительности имеются следующие:

Вам следует хотя бы включить в общий процесс сбора данных для планирования мощности, наблюдение за счетчиками Available Memory и Page Faults/sec.

Анализ данных о памяти

После сбора данных их можно отобразить в графической форме, чтобы предсказать, какими они станут в будущем. График на рисунке 6-4 показывает пример упреждающего анализа. В этом примере показаны данные о свободной памяти, собранные с 22 октября 1999 года по 14 января 2000 года. При помощи Microsoft Excel эти данные были нанесены на график и построена линия тренда. Зубчатая линия обозначает историю фактического использования памяти, а прямая линия обозначает линейный тренд использования памяти. Как видите, этот анализ предсказывает, что 18 февраля 2000 года у системы останется менее 6% свободной памяти.

График на рис. 6.5 показывает увеличение обращений к отсутствующим страницам виртуальной памяти за тот же период, а также демонстрирует, что по мере уменьшения объема свободной памяти число обращений к отсутствующим страницам увеличивается.

Обратите внимание на то, что данные о количестве обращений к отсутствующим страницам виртуальной памяти за секунду собирались за тот же период времени, что и данные о свободной памяти. Снова воспользуемся Microsoft Excel, чтобы записать эти данные и отобразить их на графике. Зубчатая линия снова обозначает историю фактического изменения показателя, а прямая линия обозначает линейный тренд этого показателя. В нашем случае график предсказывает, что 18 февраля 2000 года у системы будет происходить более шести обращений к отсутствующим страницам в секунду. Значит, и после этой даты число обращений будет увеличиваться и это может привести к нарушению соглашения об уровне обслуживания. Рассмотренный метод упреждающего анализа является простым и эффективным способом слежения за ресурсами памяти.

Планирование мощности процессора

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

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

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

Как вы уже поняли, всегда предпочтительным является предварительное планирование для периода пиковых нагрузок, потому что оно соответствует наихудшему сценарию развития событий, а мы могли бы создать такую систему, которая выдержала бы это. К сожалению, в большинстве случаев, необходимая для этого информация недоступна, поэтому остается довольствоваться информацией, полученной для установившегося режима. Чтобы получить более глубокое понимание обрабатываемых транзакций, мы должны разобраться во внутреннем устройстве ("анатомии") транзакций, в их "профиле", что поможет нам подсчитать количества генерируемых чтений и записей, благодаря чему мы сможем спрогнозировать ожидаемую нагрузку на центральный процессор. Эту информацию можно получить из бесед с проектировщиками базы данных и проектировщиками приложений. Сначала надо узнать, сколько транзакций каждого типа будут проходить через систему, а затем надо определить количество генерируемых операций чтения и записи. Так будет рассчитана оценка нагрузки на центральный процессор.

Для уже работающих систем пользователи могут определить профили транзакций, запуская транзакции по одной за раз и следя за ними через Performance Monitor (чтобы определить количество генерируемых операций чтения и записи). Эта "натурная" информация может применяться для подбора скорости, типа и количества используемых центральных процессоров.

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

Отказоустойчивость

Сейчас большинство компьютерных фирм добиваются отказоустойчивости при помощи поддержки технологии RAID (Redundant Array of Independent Disks, "массивы независимых дисковых накопителей с избыточностью"). (О технологии RAID см. лекцию 5.) Запомните, что чаще всего применяются следующие уровни RAID:

Так как в RAID 0 не применяется дублирование данных, то для них достаточно одиночного повреждения – при отказе дискового накопителя вы потеряете данные на нем и, следовательно, во всей базе данных. Схема массива RAID 0 показана на рис. 5.9. В RAID 1 обеспечивается зеркальное дублирование диска базы данных. При отказе какого-либо дискового накопителя остается резервный накопитель, весь заполненный данными, такими же, какие были и на отказавшем дисковом накопителе. Если вы решите применять массивы RAID 1, то можно воспользоваться достоинствами параллельного поиска (split seek, см. лекцию 5), благодаря которому система может выполнять поиск данных одновременно сразу на двух дисковых накопителях, что значительно повышает скорость поиска и, следовательно, уменьшает время отклика для транзакций. Схема массива RAID 1 показана на рис. 5.10.

Выбор уровня RAID непосредственно влияет на количество операций дискового ввода-вывода, т.к. разные уровни RAID отличаются количеством записей на диски. Например, для RAID 1 по сравнению с RAID 0 требуется в два раза больше записей на диск. Если пользователь задаст транзакцию, требующую 50 чтений и 10 записей, то при использовании RAID 1 количество записей вырастет до 20.

Если конфигурация RAID 0 имеет два дисковых накопителя, то равноценная конфигурация RAID 5 должна иметь три дисковых накопителя. В конфигурациях RAID 5 применяется слой данных (stripe), содержащий информацию о данных на двух других накопителях, который может быть использован для восстановления данных с отказавшего диска. Схема массива RAID 5 показана на рис. 5.11. Эта схема защиты базы данных хороша и по показателям производительности и по цене. Каждая запись в RAID 5 удваивает количество чтений и количество записей для каждой обрабатываемой транзакции, потому что каждая транзакция должна быть записана на два диска – должен быть прочитан слой контроля по четности, изменен в соответствии с новыми данными, а затем снова записан. Эта избыточность несколько увеличивает длительность времени отклика.

Чтобы рассчитать количество операций ввода-вывода для различных уровней RAID, можно воспользоваться следующими формулами:

Для RAID 0:

количество операций ввода-вывода = (количество чтений на одну транзакцию) + 
+(количество записей на одну транзакцию)

Если транзакция содержит 50 чтений и 10 записей, то общее количество операций ввода-вывода для уровня RAID 0 будет равно 60.

Для RAID 1:

количество операций ввода-вывода = 
(количество чтений на одну транзакцию) + 
(2 х [количество записей на одну транзакцию])

Если транзакция содержит 50 чтений и 10 записей, то общее количество операций ввода-вывода для уровня RAID 1 будет равно 70.

Для RAID 5:

количество операций ввода-вывода = 
3 х (количество операций ввода-вывода на одну транзакцию)

Если транзакция содержит 50 чтений и 10 записей, то общее количество чтений будет равно 150, а общее количество записей будет равно 30. Общее количество операций ввода-вывода для уровней RAID 5 будет равно 180.

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

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

загруженность центрального процессора = 
(темп ввода-вывода) х (время обслуживания) х 100

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

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

общее количество чтений = 
(количество чтений на одну транзакцию) х (общее количество транзакций)

общее количество логических чтений = 
(общее количество чтений) х (процент успешных обращений к кэшу)

общее количество физических чтений = 
(общее количество чтений) – 
-(общее количество логических чтений)

количество логических чтений в секунду = 
 (общее количество логических чтений) / (рабочий период)
 
количество физических чтений в секунду = 
 (общее количество физических чтений) / (рабочий период)

время для выполнения логических чтений = 
(количество логических чтений в секунду) х 
(длительность операции логического чтения)

время для выполнения физических чтений = 
(количество физических чтений в секунду) х 
(длительность операции физического чтения)

загруженность = (темп чтения) х (время обслуживания) х 100

загруженность операциями логического чтения = 
(количество логических чтений в секунду) х 
(длительность операции логического чтения) 

загруженность операциями физического чтения = 
(количество физических чтений в секунду) х 
(длительность операции физического чтения)

общее количество записей = (количество записей на одну транзакцию) х 
(общее количество транзакций) х (множитель RAID)

количество записей в секунду = (общее количество записей) / 
(рабочий период)

время центральных процессоров для выполнения записей = 
(количество записей в секунду) х 
(длительность обработки центральным процессором одной операции записи)

загруженность операциями записи = (количество записей в секунду) х 
(длительность обработки центральным процессором одной операции записи) х 100

загруженность центральных процессоров  = 
((загруженность операциями логического чтения) + 
(загруженность операциями физического чтения) +
(загруженность операциями записи)) х 100

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

суммарная загруженность на один процессор  = 
(суммарная загруженность центральных процессоров) / 
(количество центральных процессоров)

Как узнать длительность операций чтения

Длительность операций чтения в вашей системе можно определить при помощи утилиты Performance Monitor. Включите Diskperf при помощи следующей команды, вводимой в окне MS-DOS:

diskperf -y

Затем запустите Performance Monitor и наблюдайте в объекте Physical Disk за счетчиками Avg. Disk sec/Read и Avg. Disk sec/Write. Обратите внимание, что эти счетчики дают вам среднее время для операций физического чтения. Для определения длительности логического чтения операций эти счетчики неприменимы.

Сбор данных о загруженности одного центрального процессора

После того как ваша система будет реализована, потребуется тщательно следить за загруженностью центрального процессора, так же, как и за памятью. В Performance Monitor имеется множество счетчиков, связанных с измерением загруженности отдельных центральных процессоров. Эти счетчики находятся в объекте Processor. Для задач предварительного планирования мощности наиболее полезны следующие счетчики:

Для предварительного планирования мощности могут понадобиться не все эти показатели; выбор применяемых показателей зависит от глубины проводимого вами исследования. По крайней мере, следует использовать счетчик % Processor Time.

Сбор данных о загруженности нескольких центральных процессоров

При помощи Performance Monitor вы можете также получить усредненные данные для нескольких центральных процессоров. Для этого воспользуйтесь объектом System, содержащим, среди прочих, следующие счетчики:

Анализ данных о загруженности центральных процессоров

Информация, собранная при помощи счетчиков Performance Monitor, может применяться для прогнозирования увеличения нагрузки на отдельные центральные процессоры, следствием которого станет увеличение времени отклика для этого процессора. На рис. 6.6 показан график загруженности центрального процессора (значения загруженности для разных дат). Обратите внимание, что тренд загруженности центрального процессора растет и достигнет 75% порога 18 февраля 2000 года.

Планирование мощности дисковой подсистемы

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

Многие люди бывают удивлены количеством дисковых накопителей, необходимых для их баз данных. Но дополнительные накопители дают дополнительные точки доступа к данным. Если вы имеете только одну точку доступа к данным, то вы создаете узкое место ("бутылочное горлышко"). Так как через это узкое место придется проходить всем транзакциям, то длительность откликов будет увеличиваться. Есть такое практическое правило – имейте как можно больше точек доступа к данным. Чем больше точек доступа к данным будет у вас, тем меньше станет вероятность возникновения узкого места из-за недостаточного количества дисковых накопителей. Кроме того, вы сможете генерировать больше операций ввода-вывода в секунду – чтобы система могла выдерживать большой поток операций ввода-вывода, необходимый для больших баз данных.

Предположим, ваша система управляет базой данных объемом 10 Гб и в ней генерируется 140 операций ввода-вывода в секунду. Из правила 85% об объеме дисковой памяти следует, что вам понадобится дисковый накопитель объемом примерно в 12 Гб, чтобы его хватило для хранения базы данных. Теперь взглянем на требования к дисковым накопителям с точки зрения производительности ввода-вывода. Если дисковые накопители имеют производительность ввода-вывода 70 операций в секунду, то с учетом правила 85% для производительности каждого из накопителей вам потребуются три накопителя. Поэтому, так как анализ производительности ввода-вывода требует применения трех накопителей (максимально), мы должны применять три дисковых накопителя, суммарный объем которых составит 12 Гб, а производительность каждого будет 70 операций ввода-вывода в секунду.

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

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

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

Дисковые накопители для Windows 2000 и SQL Server

Сначала надо рассчитать количество дисковых накопителей, необходимых для хранения первой категории данных – операционной системы Windows 2000 Server и СУБД SQL Server. Обычно для этого применяют отдельный набор томов RAID 1 (дисковые накопители с зеркальным дублированием), чтобы обеспечивать наиболее быстрое восстановление после отказов. Количество дисковых накопителей может быть разным в зависимости от объема хранимой на них информации, но операционная система Windows 2000 и СУБД SQL Server обычно умещаются на одном диске. Наш простой метод расчета можно выразить следующей формулой:

диски для операционной системы и SQL  = 
(диски для Windows 2000 Server и SQL) х (множитель RAID)

В данном случае, для дисковых накопителей с зеркальным дублированием, результатом формулы будет 2 диска (Windows NT и SQL Server уместятся на одном диске, а другой будет служить дублирующим диском массива RAID 1). Конфигурация тома для операционной системы как RAID 5 или как RAID 0 не рекомендуется. Применять RAID 5 имеет смысл, только когда для собственно хранения данных требуется более одного диска, и вам следует стремиться к как можно более быстрому восстановлению операционной системы и программы СУБД.

Дисковые накопители для файлов журналов

Затем вам потребуется рассчитать количество дисковых накопителей, необходимых для поддержки системных файлов журналов. Это количество сильно зависит от общего количества операций записи за одну секунду, вызываемых вашими транзакциями. Помните, что ценность информации, содержащаяся на этих дисках, очень велика. Она представляет собой "аудиторский след" (контрольный журнал) или "образ до сбоя", который понадобится, если что-нибудь случится с базой данных. При помощи аудиторского следа вы сможете отменить транзакции, незавершенные из-за отказа диска. Расчет количества операций записи уже был выполнен при предварительном планировании мощностей процессоров. Пусть, например (эти числа взяты произвольно), транзакции вызывают 1 500 000 операций записи при использовании тома RAID 0. Если мы решим, что для дисковых накопителей, хранящих журнал, надо применять RAID 1, то получится, что за 8-часовой рабочий день должно быть выполнено 3 000 000 операций записи, или 104,16 операций записи за одну секунду. (Помните, что по сравнению с RAID 0, массивы RAID 1 удваивают количество операций записи на одну транзакцию.) Для расчета необходимого количества дисковых накопителей примените следующую формулу:,

диски для журналов  = 
(количество записей в секунду) / (производительность ввода-вывода диска)

Помните, что производительность ввода-вывода диска в данной формуле должна составлять 85% от его паспортной максимальной производительности. Также не забудьте округлить результат деления (количество записей в секунду) / (производительность ввода-вывода диска) до ближайшего целого числа в сторону увеличения. И наконец, не забудьте скорректировать величину количество записей в секунду в соответствии с увеличением количества операций записи, вызванным из-за применения того или иного уровня RAID. Если мы применим 85-процентный потолок к дисковым накопителям, имеющим максимальную производительность ввода-вывода 70 операций ввода-вывода за одну секунду, то получится, что нам надо иметь 1,7 накопителя. Округлив этот результат, мы получим, что нам надо иметь два накопителя.

Дисковые накопители для базы данных

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

Расчет для объема дисковой памяти

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

диски для базы данных  = (объем данных) / (размер диска) + (прибавка RAID)

Помните, что размер диска в данной формуле должен составлять 85% от его паспортной максимальной емкости. Также не забудьте, что для объема данных и размера диска надо применять одинаковые единицы измерения (например, килобайты или мегабайты). Прибавка RAID – это количество дополнительных дисковых накопителей, необходимых для обеспечения отказоустойчивости. Для RAID 1 это число равно количеству дисковых накопителей, необходимых для хранения самой базы данных. Для RAID 5 требуется один дополнительный накопитель. Для нашей 10-гигабайтной базы данных, использующей RAID 5, потребуется два 12 Гб накопителя.

Расчет для производительности ввода-вывода при доступе к базе данных

Количество дисков, необходимых, чтобы система могла выдержать необходимый темп ввода-вывода, может вырасти очень значительно, как вы уже видели из простого примера, приведенного ранее. Чтобы рассчитать это количество, надо выполнить ряд действий:

общее количество чтений = (количество чтений на одну транзакцию) х 
(общее количество транзакций)

общее количество логических чтений = (общее количество чтений) х 
(процент успешных обращений к кэшу)

общее количество физических чтений = (общее количество чтений) - 
(общее количество логических чтений)

количество физических чтений в секунду = 
(общее количество физических чтений) / (рабочий период)

общее количество записей = (количество записей на одну транзакцию) х 
(количество транзакций) х (множитель RAID)

количество физических записей в секунду = (общее количество физических записей) / 
(рабочий период)

количество физических операций ввода-вывода в секунду = 
	(общее количество физических чтений в секунду) + 
	(количество физических записей в секунду)

количество дисков для базы данных = 
	((количество физических операций ввода-вывода в секунду) / 
	(производительность ввода-вывода одного диска)) + (прибавка RAID)

Помните, что значение производительности ввода-вывода одного диска вы должны брать с учетом правила "85%". Прибавка RAID – это количество дополнительных дисковых накопителей, необходимых для обеспечения отказоустойчивости. Если мы имеем всего 138,9 физических операции ввода-вывода в секунду, а производительность диска составляет 70 операций ввода-вывода в секунду и применяется массив RAID 5, то всего понадобится четыре дисковых накопителя – три для поддержки суммарного ввода-вывода и еще один для обеспечения отказоустойчивости массива RAID 5.

Итак, вы видите, что для размещения базы данных размером 10 Гб было бы достаточно иметь всего лишь один диск, но с учетом выполняемого ввода-вывода потребуется три диска – больший из двух результатов расчета.

Общее количество дисковых накопителей, нужных в системе

Чтобы определить суммарное количество дисковых накопителей, нужных для системы, надо суммировать все количества накопителей, нужных для всех ее компонент. В соответствии с условиями нашего примера нам понадобятся два накопителя для Windows 2000 Server и SQL Server, два накопителя для файлов журнала и четыре накопителя для базы данных, из чего следует, что для всей системы потребуется восемь дисковых накопителей.

Сбор данных об использовании дисков

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

При выполнении исследований последующего планирования загруженности дисков понадобится следить за следующими счетчиками утилиты Performance Monitor, которые вы найдете в объекте PhysicalDisk:

Для запуска Disk Administrator нажмите на экранную кнопку Start, затем выберите Programs, Administrative Tools (Common) и, наконец, Disk Administrator. Для получения дополнительной информации об использовании утилиты Disk Administrator, производительности, нажмите на кнопку Help в окне Disk Administrator.

Анализ данных об использовании дисков

Анализ информации об использовании дисков несложен. Например, если бы мы анализировали работу системы, то для определения объема свободного места мы собирали бы информацию о свободном месте на дисках. На рис. 6.7 показаны нагрузка на базу данных в отношении наличия свободного места.

Как можно видеть, в начале наблюдений у нас было 2,05 Мб свободного места из общего объема в 6,15 Мб, т.е. диск был заполнен примерно на 67%. 14 января 2000 года объем свободного места на диске уменьшился примерно до 1,5 Мб, т.е. диск заполнился примерно на 75%. Проведя при помощи Microsoft Excel линию тренда, можно спрогнозировать, что 18 февраля 2000 года на диске останется свободно только около 1,3 Мб, т.е. диск заполнился примерно на 83%. Администратор баз данных может принять решение приобрести в этот момент дополнительный диск.

Планирование мощности сети

Планирование мощности сети мы оставили под конец, потому что изнутри системы вы не сможете получить много информации. Из утилиты Performance Monitor нельзя получить никакие счетчики производительности работы сети, поэтому предварительное планирование сети может оказаться достаточно трудным делом. Сеть обычно является самым слабым звеном в системе, поэтому будьте реалистичны при ее оценке.

Чтобы выполнить предварительное планирование сети, вам понадобится определить, сколько пользователей будут одновременно работать в системе, сколько сообщений (messages) будет проходить за одну секунду и сколько в среднем байт будет содержаться в этих сообщениях. Опираясь на эту информацию, вы можете произвести некоторые оценки минимально необходимой пропускной способности сети. Пусть, например, в нашей системе будут передаваться такие объемы данных: будет 10 пользователей, каждый из которых будет передавать 25 сообщений в минуту. Каждое сообщение будет иметь длину 259 байтов. Можно оценить, что за одну минуту все эти 250 сообщений будут генерировать 64 750 байтов в минуту, т.е. 518 000 битов в минуту, т.е. 8633,33 бита в секунду. Для такой нагрузки подойдет небольшая сеть. Для оценки мощности сети можно применять следующую формулу:

мощность сети = (количество сообщений секунду) х  (длина сообщений) х  
(количество битов в одном байте)

При помощи этого расчета вы можете приблизительно оценить мощность (бит/сек), которую должна будет иметь линия передачи данных.

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

Сбор данных об использовании сети

При выполнении исследований последующего планирования загруженности сети вам понадобится следить за счетчиком производительности Bytes/Sec Through Network Interface утилиты Network Monitor (Сетевой монитор). Этот счетчик обозначает процент времени, когда линия передачи данных занята.

Анализ данных об использовании сети

Для анализа сетевых данных надо сначала рассчитать пропускную способность линии передачи данных (мощность сети), как было показано выше, а затем посмотреть значение счетчика Bytes/Sec Through Network Interface. Зная два этих значения, можно вычислить общую загруженность сети при помощи следующей формулы:

загруженность сети = 
((количество байт, проходящих через сеть за одну секунду) / 
(мощность сети)) х 100

На рис. 6.8 показан пример линейного роста процента загруженности сети в зависимости от даты.

График показывает, что 2 сентября 2000 года загруженность данного сегмента сети станет максимально возможной. Опять напомним, что чем больше точек с данными вы нанесете на график, тем точнее будет ваш прогноз.

Как выбирать оценочные данные

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

Сбор данных о процессах

Информация о процессах может оказаться очень ценной при создании профилей рабочей нагрузки. Создание профилей рабочей нагрузки – это выяснение, какую именно работу выполняет каждый из пользователей. Performance Monitor имеет много разнообразных счетчиков для выполнения этой задачи. Эти счетчики подобны счетчикам из объекта Processor, но в данном случае они применяются для сбора данных о процессе. Они находятся в объекте Process и перечислены ниже:

Анализ данных о процессах

Анализ этой информации вовсе не так сложен, как вы могли бы подумать. Например, если бы потребовалось провести анализ работ, выполняемых процессами системы, то нам надо было бы собрать данные процессов при помощи, например, счетчика % Processor Time. Этот счетчик позволяет оценить, насколько много внимания система уделяет данной функции. На рис. 6.9 показан рост пользовательского процесса в запросе CalProc, применяемом отделом кредиторских задолженностей.

Эта информация полезна тем, что мы можем спрогнозировать результат от увеличения числа пользователей в отделе кредиторских задолженностей. Линия тренда на данном графике показывает, что процент использования возрастает и достигнет 18 февраля 2000 года 30%. Допустим, в отделе кредиторских задолженностей имеется 10 пользователей, тогда можно оценить в 3% вклад каждого из пользователей в загруженность в феврале. Мы можем сделать вывод, что если в феврале добавить еще трех пользователей, то загруженность для запроса CalProc составит приблизительно 39%.

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

В табл. 6.1 дан список счетчиков, которые послужат хорошей основой для исследований планирования мощности.