Дополнительные требования к памяти

Естественно конфигурация системы должна обеспечивать также пространство для традиционного использования памяти. В СУБД на базе UNIX всегда необходимо обеспечить по крайней мере 16 Мбайт для базовой операционной системы. Далее, необходимо предусмотреть пространство объемом 2-4 Мбайт для ряда программ СУБД (программ ведения журнала, проверки согласованного состояния, архиваторов и т.п.) и достаточно пространства для размещения в памяти двоичных кодов приложения. Объем двоичных кодов приложения составляет обычно 1-2 Мбайт, но иногда они могут достигать 16-20 Мбайт. Операционная система обеспечивает режим разделения двоичных кодов между множеством пользующихся ими процессов, поэтому необходимо резервировать пространство только для одной копии. Пространство для размещения самого кода сервера СУБД зависит от общей архитектуры сервера. Для архитектуры "2N" следует выделять по 100-500 Кбайт на пользователя. Многопотоковые архитектуры требуют только 60-150 Кбайт, поскольку они имеют намного меньше процессов и намного меньшие накладные расходы.

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

Процессоры

Потребление процессорных ресурсов очень сильно варьируется в зависимости от используемого приложения, СУБД, индивидуальных пользователей и даже от времени дня. Например, результаты теста TPC-A показывают, что восьмипроцессорный SPARCserver 1000 способен обрабатывать запросы от 4000 пользователей, или от 500 пользователей на процессор. (Эти результаты были достигнуты на многопотоковом сервере Oracle Version 7, работающим в режиме клиент/сервер, причем в качестве фронтальной системы использовался монитор обработки транзакций Tuxedo/T.) Следует отметить, что этот результат был достигнут специалистами компании Sun и Oracle путем очень тщательной настройки ОС Solaris, СУБД Oracle и самого оценочного теста. Возможности этих специалистов по настройке системы, очевидно значительно превосходят возможности большинства пользователей. Более реалистическая верхняя граница числа пользователей на процессор возможно составляет порядка 100-200 пользователей на один процессор 50 МГц SuperSPARC, даже для легких транзакций типа TPC-A. Более крупные приложения естественно приводят к меньшему числу пользователей на процессор.

Работа прикладного пакета Oracle*Financials создает для системы значительно более тяжелую рабочую нагрузку, чем работа теста TPC-A. Это связано с несколькими причинами. Во-первых, по сравнению с одной транзакцией, выполняемой тестом TPC-A, пакет Financials генерирует множество различных транзакций. Во-вторых, после того как данные найдены, сама основная СУБД должна выполнить нетривиальный объем прикладной обработки. В-третьих, пакет Financials не может работать с монитором обработки транзакций. Эксперименты компании Sun с этим пакетом показали, что процессор 50 МГц SuperSPARC может обрабатывать примерно 15 полностью активных пользователей в режиме разделения времени и 40-60 полностью активных пользователей в режиме клиент/сервер, даже с минимальным временем обдумывания.

Таблица 2.3. Примерное число поддерживаемых пользователей на ЦП

Тип приложения		Количество процессоров 50 Мгц SuperSPARC
		12 4 8 16
TP-монитор	клиент/ сервер	200-300350-500 550-850 800+ 1000+
Легковесное	клиент/ сервер	150-200250-350 450-550 725+ 800+
многопотоковое	Разделение времени	50-8085-135 150-225 200-300 250-300
Тяжеловесное	Клиент/ сервер	50-10085-170 150-250 200-350 350-600
многопотоковое	Разделение времени	20-6035-100 60-175 100-300 150-250
Тяжеловесное 2N	клиент/ сервер	40-7570-125 120-220 200-600 300-750
	Разделение времени	15-4025-70 45-120 75-200 110-230

Ни операционная система Solaris 2, ни СУБД не масштабируются линейно (то же самое происходит и с конкурирующими операционными системами). Поскольку как Solaris 2, так и версии СУБД под Solaris 2 являются относительно новыми, таблица 2.3 отражает коэффициент масштабирования на уровне 70% (т.е. дублирование процессоров дает 70% увеличение производительности). Ожидается, что эти цифры со временем будут улучшаться по мере дальнейшей настройки как Solaris 2, так и СУБД особенно в направлении достижения лучшей многопроцессорной масштабируемости.

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

Дисковые подсистемы ввода/вывода

Как уже было отмечено при обсуждении требований к основной памяти, обращения к диску выполняются примерно в 30000 медленнее, чем к памяти. В результате, лучший способ оптимизации дискового ввода/вывода - вообще его не выполнять! Однако экономически это не оправдано. Таким образом, обеспечение достаточной пропускной способности (емкости доступа) подсистемы ввода/вывода, является решающим фактором для обеспечения высокой устойчивой производительности СУБД. Множество технических соображений приводят к некоторым удивительным результатам.

Соотношение запрос/индекс/диск

Без понимания приложения заказчика, стратегии индексации, принятой администратором базы данных, а также механизмов поиска и хранения СУБД сложно сделать точное утверждение о том, какого типа доступ к диску данная транзакция будет навязывать системе. Особенно трудно количественно определить сложные транзакции, которые имеют место в приложениях третьих фирм, например, в продукте R/3 SAP, который надстроен над Oracle. Однако в отсутствие фирменной информации стоит предположить, что любая транзакция, которая находит небольшое число специально поименованных записей из индексированной таблицы "по индексному ключу" будет представлять собой операцию произвольного доступа к диску. Например, транзакция

select name, salary from employee

were phone-number = "555-1212" or

ssn = "111-111-1111";

почти наверняка будет осуществлять произвольное обращение к диску, если таблица служащих индексируется с помощью phone-number и ssn. Однако, если таблица индексируется только именем и номером служащего, то такая транзакция будет выполняться путем последовательного сканирования таблицы, вполне возможно затрагивая каждую ее запись.

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

Рассмотрим запрос

select part_no, description, num-on-hand from stock

where (part_no > 2000 and part_no < 24000);

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

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

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