При выборе конфигурации системы приходится рассматривать комбинацию достаточно сложных объектов: аппаратные средства + операционная система + СУБД + приложение. Из-за сложности анализа комбинации этих объектов обычно невозможно определить, будет ли способна данная система поддерживать требуемую нагрузку. Тем не менее, часто возможно сделать некоторые предположения и затем грубо проанализировать основные транзакции чтобы определить, при каких конфигурациях система не будет способной обработать эти основные транзакции. Хотя такой подход полезен только для относительно простых приложений, особенно для приложений с одной или двумя основными транзакциями, он дает неплохое начальное приближение и для больших и более сложных приложений. Вопрос о том, как соотнести конкретные запросы с требованиями пропускной способности дисковой подсистемы уже обсуждался в разделе 2.2.6.1.
В процессе оценки рассматриваются известные ограничения отдельных частей предлагаемой системы и затем производится их сравнение с минимальными потребностями в соответствии с поставленной задачей. Например, известно, что диск емкостью 2.1 Гбайт может выполнить 62 операции произвольного доступа в секунду. На каждую операцию затрачивается примерно 2 мс процессорного времени. Если приложение требует выполнения примерно 700 операций произвольного чтения диска в секунду, то очевидно, что система с одним диском не справится с такой задачей за требуемое время: необходимо по крайней мере 12 накопителей. Более того, практически сразу видно, что однопроцессорная система не может справиться с этой задачей, поскольку для обработки 700 дисковых операций требуется 1400 миллисекунд процессорного времени в секунду (т.е. более 1 секунды). Хотя совершенно ясно, что однопроцессорная система с одним диском не будет способна выполнять это приложение с требуемой скоростью, совсем неочевидно, что двухпроцессорная система с 12 дисками обеспечит требуемую производительность. Это происходит потому, что приложение очень сильно абстрагировано (в этом случае, любой вид работы приложения упрощен!).
В качестве примера рассмотрим приложение, которое в течение четырех часов каждую ночь должно быть способно заново создавать базу данных. База данных состоит из двух таблиц, одна из которых содержит 10 миллионов записей по 2 Кбайт каждая, а другая - 40000 записей размером примерно по 1 Мбайт, т.е. общим объемом 40 Мбайт. Предположим, что индексация выполняется с помощью отдельной операции. Тогда для создания первой таблицы требуется выполнить 10 миллионов дисковых операций (по 2 Кб) за 4 часа, или 695 операций в секунду. Как показано в таблице 2.4, дисковый накопитель может обеспечить выполнение примерно 60 операций (по 2 Кб) произвольного доступа в секунду в режиме "чистого" диска и примерно 400 операций в секунду в режиме последовательного доступа. Отсюда ясно, что необходимо иметь по крайней мере два параллельно работающих диска, если создание таблицы выполняется последовательными операциями, или 12 параллельно работающих дисков, если выполняются операции произвольного доступа. Обычно сама таблица создается последовательными операциями, в то время как индексы создаются часто операциями произвольного доступа.
Создание второй таблицы требует размещения на диске 40000 записей по 1 Мбайт каждая (всего 40 Гбайт). Хотя конкретные СУБД отличаются обработкой и размещением двоичных данных большого объема (такие объекты часто называются BLOBs - Binary Large OBjects), все они почти наверняка будут использовать для записи каждого элемента данных только один адрес, и в результате, такие записи будут выполняться последовательными операциями. Таким образом, поскольку в нашем случае каждая запись будет состоять примерно из 512 физических записей на диск, в этой работе будут доминировать операции последовательного доступа к диску (даже, если каждая запись хранится отдельно, потребуется не более одного позиционирования головок на все 512 обращений к диску). Для создания этой таблицы требуется выполнить 20480000 операций записи на диск со скоростью примерно 1450 операций в секунду. Для достижения этой скорости по крайней мере 4 диска должны осуществлять запись одновременно. Поскольку для размещения 40 Гбайт данных потребуется не менее 14 дисковых накопителей емкостью 2.9 Гбайт, для достижения требуемой производительности не возникает проблем с обеспечением достаточного количества дисков, но требование параллельной записи на 4 диска диктует, чтобы использовался некоторый механизм, позволяющий расщепить доступ по дискам. Поэтому минимально требуемая конфигурация должна обеспечивать четырехкратное расщепление.
Необходимо помнить, что при достижении таких скоростей дискового ввода/вывода, система должна затрачивать также примерно 1.7 мс процессорного времени на каждую операцию с диском. Создание первой таблицы требует выполнения 695 дисковых операций в секунду, или 1181 мс на каждую секунду процессорного времени. Для создания второй таблицы требуется выполнить 1425 дисковых операций в секунду, или примерно 2425 мс на каждую секунду процессорного времени. В сумме это составляет примерно 3606 мс на каждую секунду процессорного времени. Таким образом можно сделать вывод о том, что четыре процессора 50 МГц SuperSPARC должны заниматься исключительно обслуживанием дисков. Кроме того, следует заметить, что все данные для формирования таблиц базы данных откуда-то должны поступить, а обработка приходящих данных также требует некоторого процессорного времени. Предположим, что данные поступают по сети FDDI с использованием протоколов TCP/IP и мы ожидаем получить всего 60 Гбайт данных за 4 часа, т.е. скорость поступления данных составляет примерно 4.2 Мбайт/с. Если взять максимальный размер пересылки по FDDI равным 4500 байт, это составит примерно 949 пакетов в секунду. На обработку каждого пакета процессор должен затратить 400 микросекунд (0.4 мс), поэтому обработка всего потока обойдется нам в 380 мс процессорного времени на каждую секунду. Эти накладные расходы могут еще увеличиться, если данные не занимают полностью 4500-байтового пакета (например, СУБД Oracle version 6 просто осуществляет пересылку в пакете одного поля одной записи независимо от его размера).
Для обеспечения дискового и сетевого ввода/вывода нам достаточно четырех процессоров. Однако в конфигурацию системы необходимо включить по крайней мере еще один дополнительный процессор, чтобы выполнять любую другую работу. Следует отметить, что для работы самой СУБД, а также для любой другой обработки, которая должна выполняться во время ночных перезагрузок базы данных, необходимо некоторое процессорное время. Более того, необходимо предусмотреть небольшой поправочный коэффициент, поскольку проведенный анализ предполагал, что работа может осуществляться со средней скоростью и закончится в точно определенное время. Однако это мало вероятно, так что в системе необходимо предусмотреть некоторые дополнительные ресурсы из-за того, что неизбежно ее средняя производительность окажется меньше, чем было вычислено.
Таким образом, в состав конечной конфигурация системы следует включить 6 процессоров. Поскольку минимальный объем дискового пространства составляет 40 Гбайт, вполне разумным кандидатом для выбора системы представляется SPARCcenter 2000 (см. табл. 4.13 - 4.15). Для хранения только данных требуются четырнадцать дисков емкостью 2.9 Гбайт, так что в конфигурацию системы необходимо включить по крайней мере 16 накопителей (отдельный диск требуется для размещения системы и журнала СУБД). Поскольку в обращениях к дисковой подсистеме доминируют последовательные операции, при конфигурировании дисков СУБД необходимо подключать не более 4 дисков к одному главному адаптеру SCSI. Необходимость 4-кратного расщепления увеличивает общее количество дисков до восемнадцати. Они будут подключаться к пяти главным адаптерам DWI/S: по 4 диска на 4 адаптера для реализации расщепления, а также системный и журнальный диски на отдельном главном адаптере. Конструкция дисковых шасси определяет необходимость установки пяти шасси в одной стойке (кабинете) расширения. (Восемнадцать дисков могли бы быть установлены и в одной основной стойке, но в ней невозможно сконфигурировать необходимую комбинацию дисков и шин SCSI). Для подключения 5 плат интерфейса SCSI и одной (двухслотовой) платы интерфейса FDDI всего требуется 7 слотов SBus. Для установки 6 процессоров необходимы три системных платы, обеспечивающие 12 слотов SBus. Сам по себе процесс загрузки СУБД не предъявляет каких-либо особых требований к объему основной памяти. Базовые 64 Мбайт на процессор или всего 384 Мб представляют собой вполне умеренную оценку. Этот объем близок к рекомендованному (1% от размера базы данных составляет 400 Мбайт).
Рассмотрим приложение, которое обеспечивает информацию о состоянии заказов для телефонного бюро обслуживания. Хотя прикладная система поддерживает некоторое число различных типов пользователей, имеется одна ключевая транзакция: запрос о состоянии счета/заказа. В течение дня система должна поддерживать 120 пользователей, выполняющих запросы счет/заказ с максимальным временем ответа 2 секунды. Обычно операторы обрабатывают примерно один телефонный звонок за две минуты. (Оформление новых заказов выполняется на отдельной системе, новые заказы поступают в систему запросов по ночам после резервного копирования).
В среднем имеется 7000 активных счетов и примерно 8500 неуплаченных заказов. Всего в текущий момент времени имеется 260000 счетов и 65000 последних заказов (заказы сроком более трех месяцев архивируются и изымаются из таблицы неуплаченных счетов). Каждая строка в таблице счетов имеет объем примерно в 3 Кбайт, и таблица счетов индексируется номером заказа и фамилией заказчика. Строки в таблице неуплаченных счетов имеют размер в 90 байт; каждый заказ ссылается в среднем на 6 строк в таблице Строка_Наименование_Товара (line item); каждая Строка_Наименование_Товара содержит 30 байт. Таблица заказов индексируется номером заказа. Наконец, каждая Строка_Наименование_Товара ссылается на описание товара; в текущий момент имеется 1050 описаний товаров, длиною 200 байт каждое. Эти размеры данных приведены в таблице 2.6.
Таблица 2.6. Размеры таблиц данных для приложения телефонных заказов
| Таблица | Кол-во строк | Размер строки | Чистый размер
данных
|
| Счета | 260000
(7000 активных) | 3 Кб | 780 Мб
|
| Заказы | 65000
(8500 активных) | 90 байт | 5.9 Мб
|
| Строка_Наименование_Товара | 390000 | 30 байт | 11.7 Мб
|
| Описание товара | 1050 | 220 байт | 231 Кб
|
Из этой таблицы видно, что для хранения активных данных требуется примерно 800 Мб для размещения чистых данных; после индексации и сохранения в базе данных этот объем возможно будет составлять 1.6 - 2.0 Гбайт дискового пространства.
В нормальных условиях работы оператор отвечает на телефонный звонок от покупателя, который сообщает либо номер заказа, либо имя заказчика. В редких случаях заказчик не может быть найден прямо по имени, и оператор должен запрашивать таблицу заказов по zip-коду. Это случается примерно в 5% случаев. Когда место заказа определено, строки с наименованием товара и их состояние отображаются на экране. Большая часть звонков заказчиков (более 99%) связана с запросом состояния одного заказа.
В терминах обращения к диску типовая транзакция включает чтение по ключу (произвольное) для выборки индекса счета, за которым следует чтение по ключу из таблицы счетов, которое читает 3 Кб данных. В записи счета хранится индексный ключ для поиска индекса таблицы заказов. Поскольку имеется 8500 неоплаченных заказов и только 7000 активных счетов, каждое обращение к индексу заказа приводит грубо к
8500/7000 = 1.21 обращений к диску, каждое к таблице индексов и ее индексу. Наконец, в каждом заказе имеется ссылка на 6 строк Строка_Наименование_Товара; поскольку они очень малы по размеру и записаны в базу данных в одно и то же время, обычно уместно предположить, что они будут генерировать обращение к индексу и затем только одно обращение к данным (6 строк по 30 байт на строку (это намного меньше, чем типовой блок данных СУБД размером 2 Кб). Последнее обращение происходит к описанию товара; однако, поскольку объем этих данных очень мал (вся таблица составляет всего
230 Кб) и они очень часто используются, можно предположить, что они кэшированы в памяти и возможно обращения к диску не происходят.
Рассмотрев эти цифры, мы можем вывести заключение, что обработка каждого звонка заказчика возможно будет вызывать одно обращение к диску за индексом счета, 1.5 обращения к таблице счетов (строка составляет 3 Кб, но большинство блоков данных имеют размер 2 Кб), примерно 1.2 обращений к таблице заказов и 1.2 обращений к индексу таблицы заказов, и каждый из них к таблице Строка_Наименование_Товара и ее индексу, т.е. всего примерно 6 операций чтения диска. Почти все из них выполняются в режиме произвольного доступа.
Поскольку ожидается, что каждый запрос будет приводить к 6 операциям чтения диска, и что 120 операторов будут генерировать 120 запросов каждые 2 минуты, среднее число запросов будет составлять один запрос в секунду. Поскольку для обработки каждого запроса требуется 6 обращений к диску ясно, что даже одной дисковой системы будет вполне достаточно для обработки запросов в установившемся режиме работы. (Напомним, что всегда рекомендуется иметь отдельный диск для ведения журнала, поскольку это связано не с обеспечением необходимой производительности, а скорее с вопросом обеспечения безопасности данных и стратегии выживания). Поскольку дисковый накопитель способен выполнить примерно 60 полностью произвольных операций ввода/вывода в секунду, отдельная дисковая система очевидно может обработать десять запросов возникших почти в один и тот же момент времени, так что если остальная часть системы имеет достаточно ресурсов, дисковая подсистема может обработать почти все, что пользователи запросят.
Имеется еще одно соображение касающееся 5% транзакций, записи счетов которых должны отыскиваться с помощью zip-кода. Поскольку таблица счетов не индексируется с помощью zip-кода, поиск должен осуществляться последовательно. Это означает, что чтобы обработать один такой запрос, для определения местоположения правильной записи счета система должна в среднем прочитать в течение 2 секунд (!) 260000/2=130000 строк. Поскольку каждая строка составляет 3 Кб, для каждой строки требуется 1.5 операции ввода/вывода, всего 195000 операций ввода/вывода (строк) по 2 Кб. Обращаясь к таблице 5 находим, что диск емкостью 535 Мб способен выполнить около 450 последовательных операций ввода/вывода в секунду, а четыре таких диска (общей емкостью 2.1 Гб) способны выполнить примерно 1800 операций в секунду. Даже при использовании 16 дисков (в 4 раза превышая требуемую емкость памяти) можно обеспечить обработку только 7200 операций в секунду. Отсюда ясно, что экономически невыгодно конфигурировать дисковую подсистему, которая будет обеспечивать необходимую пропускную способность. Единственный альтернативный вариант заключается в том, чтобы разрешить этой транзакции выполняться гораздо дольше, чем обычно, или проиндексировать таблицу счетов с помощью zip-кода.
В конце концов, возможно наилучшей конфигурацией дисков является 4 диска по 535 Мб, сконфигурированных на двух главных адаптерах SCSI, если это представляется возможным по экономическим соображениям. Журнальный файл будет иметь очень небольшой объем и потому может размещаться на системном диске. Поскольку тип СУБД не был определен, а также не было никакой информации о количестве времени, связанного с обработкой самого приложения, невозможно точно оценить количество процессоров в системе. Каждый пользователь выполняет одну транзакцию за каждые две минуты, а каждая транзакция требует тривиального количества обработки: 6 операций с диском отнимают по 1.7 мс процессорного времени каждая, или примерно 1% от каждой минуты работы процессора. Для обработки запросов всех операторов потребуется примерно 10 мс процессорного времени на каждый запрос ( 120 пользователей / 120 секунд = 10 мс процессорного времени в секунду. Ясно, что любой процессор легко справится с такой нагрузкой. Поскольку имеется 120 пользователей, рекомендуются процессоры с большими внешними кэшами, поэтому SPARCstation 10 Model 51 является наиболее подходящим процессором. При данном уровне загрузки процессора никакой дополнительный процессор возможно не потребуется.
Что касается объема основной памяти, то ясно, что необходим минимальный объем в 128 Мб, поскольку с ней будут работать 120 пользователей. Если выделить под каждого пользователя 1 Мбайт памяти, 16 Мб под базовую операционную систему и 8 Мб для кэша разделяемых данных СУБД (1% от размера базы данных), то минимальный объем основной памяти составит 144 Мб, а 160 Мб возможно представляют собой более безопасную оценку. Поскольку операции обновления СУБД отсутствуют, отсутствуют и требования к использованию NVSIMM для ускорения работы с журнальным файлом.
Наконец, 120 пользователей должны быть подсоединены к терминальным серверам. Другие требования к Ethernet для периода опытной эксплуатации системы отсутствуют, поэтому терминальные серверы не создадут каких либо проблем с использованием полосы пропускания Ethernet.
Таким образом, в состав конечной оцениваемой конфигурации входит SPARCstation 10 Model 51 с 160 Мб основной памяти, одним FSBE/S, четырьмя дисками по 535 Мб для СУБД и один 1.05 Гб внутренний диск для операционной системы и разнообразных функций СУБД. Требуются также 2 сетевых терминальных сервера по 64 порта.
Такого рода анализ связан с целым рядом неточностей. В частности, он пренебрегает эффективностью, получаемой за счет кэширования различных частей данных, он не принимает во внимание накладные расходы, связанные с входом в систему и архивацией и предполагает, что B-деревья и другие внутренние механизмы доступа к базе данных ничего не стоят. Также в расчет не принимался объем обработки, выполняющейся приложением, который часто бывает существенным. Однако этот метод обеспечивает возможность оценки минимальной конфигурации и особенно при отсутствии более формального и/или полного анализа позволяет создать хорошую начальную конфигурацию системы.
Важно напомнить, что такого рода анализ позволяет скорее определить, что данная конфигурация недостаточна для удовлетворения заданных требований. Однако этот метод не способен решить с какой либо определенностью, что предлагаемая конфигурация способна удовлетворить всем требованиям.
Предыдущая глава | Оглавление | Следующая глава
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
