Подсистема основной памяти
Среди различных компонентов аппаратуры сервера СУБД конфигурация памяти системы обычно имеет самое большое воздействие на ее производительность. Хотя для многих людей память представляется только хранилищем выполняемых программ, большая часть основной памяти в системах СУБД используется в качестве буфера (кэша) данных, позволяющего во многих случаях устранить необходимость выполнения физического ввода-вывода с диска. Поскольку обращение к основной памяти выполняется примерно в 30000 раз быстрее, чем обращение к быстрому диску, минимизация дискового ввода-вывода является первостепенно важной задачей. Не будет преувеличением сказать, что "возня"с другими конфигурационными параметрами бесполезна, если в системе не хватает основной памяти. К счастью, обычно ошибки по конфигурации памяти сравнительно легко исправляются.
Поставщики СУБД называют буферы данных по-разному, но все они выполняют одну и ту же функцию. Компания Oracle, например, называет эту память Глобальной Областью Системы (SGA System Global Area), в то время как Sybase называет ее Кэшем Разделяемых Данных (Shared Data Cashe). Обычно буфер реализуется как большой массив разделяемой памяти, и его размер определяется специальным параметром в управляющем файле или таблицах СУБД. Размер памяти, необходимый для организации дискового кэша СУБД, меняется в широких пределах от приложения к приложению.
Возможно, самым простым и наиболее полезным является эмпирическое правило, которое называется "правилом пяти минут". Существующее в настоящее время соотношение между ценами подсистемы памяти и дисковой подсистемы показывает, что экономически целесообразно кэшировать данные, к которым осуществляются обращения более одного раза каждые пять минут. Это означает, что данные, к которым обращения происходят более часто, чем один раз впять минут, должны кэшироваться в основной памяти. Соответственно, чтобы оценить размер кэша данных необходимо просуммировать объемы всех данных, которые приложение предполагает использовать более часто, чем один раз в пять минут на уровне всей системы.
Поэтому при определении необходимого объема основной памяти рассчитывают, по крайней мере, на такой размер кэша данных. Дополнительно обычно резервируют еще 5-10% для размещения верхних уровней индексов B-деревьев, хранимых процедур и другой управляющей информации СУБД.
Каждая коммерческая СУБД обеспечивает механизм для определения стоимости или преимуществ изменения размера различных кэшей СУБД. Когда система инсталлирована и начинает работать, необходимо использовать эти механизмы для определения эффекта от изменения размеров кэша ввода-вывода СУБД.
Хотя основной целью СУБД на макроуровне является управление томами данных, которые по определению имеют очень большой объем и неизбежно во много раз превышают объем основной памяти, проведенные исследования показали, что доступ к данным в общем случае подчиняется правилу "90/10": 90%всех обращений выполняются к 10% данных. Более того, оказалось, что к "горячим" данным, обращения к которым составляют 90% всех обращений, снова применимо правило "90/10". Таким образом, примерно 80% всех обращений к данным связаны с доступом к примерно 1% агрегированных данных. Следует отметить, что это отношение включает обращения к внутренним метаданным СУБД (включающих индексы B-деревьев и т. п.), обращения к которым обычно скрыты от прикладного программиста. Хотя желательно иметь коэффициент попаданий в кэш примерно на уровне 95%, по экономическим соображениям невозможно слепо обеспечить объем кэша в памяти, позволяющий разместить 10% всех данных: даже для скромных баз данных объемом 5 Гбайт это потребовало бы увеличения размера основной памяти до 500 Мбайт. Однако обычно всегда возможно обеспечить кэш объемом в 1% всех данных даже для очень больших баз данных. Максимальный объем основной памяти современных серверов может быть очень большим. Например, в серверах DEC AlphaServer 8400 он достигает 28 Гбайт, в серверах ChallengeXL компании Silicon Graphics - 16 Гбайт, а в серверах Enterprise 6000 компании Sun Microsystems - 30 Гбайт.
Таким образом, эти серверы могут работать с базами данных объемом более одного терабайта (при наличии баз данных такого размера для поддержки неизбежно большого числа пользовательских приложений и т. д. очевидно также потребуется существенная часть этой памяти).
Естественно, конфигурация системы должна обеспечивать также пространство для традиционного использования памяти. В СУБД на базе Unix и NT всегда необходимо обеспечить по крайней мере 16 Мбайт для базовой операционной системы. Далее необходимо предусмотреть пространство объемом 2-4 Мбайт для ряда программ СУБД (программ ведения журнала, проверки согласованного состояния, архиваторов и т. п.) и достаточно пространства для размещения в памяти двоичных кодов приложения. Объем двоичных кодов приложения составляет обычно 1-2 Мбайт, но иногда они могут достигать 16-20 Мбайт. Операционная система обеспечивает режим разделения двоичных кодов между множеством пользующихся ими процессов, поэтому необходимо резервировать пространство только для одной копии. Пространство для размещения самого кода сервера СУБД зависит от его архитектуры.
Для многопроцессорных систем существует также эмпирическое правило, которое гласит, что неразумно конфигурировать менее, чем примерно 64 Мбайт памяти на процессор. Обрабатываемая каждым ЦП дополнительная информация требует выделения некоторого пространства для того, чтобы обойти интенсивную фрагментацию памяти.
