Подсистема основной памяти

Вопросы производительности

Помимо достижения определенной гибкости за счет использования TP-мониторов, такая организация оказывается выгодной и с точки зрения увеличения производительности системы. TP-монитор всегда представляет собой многопотоковую программу. Поскольку TP-монитор открывает свое собственное соединение с СУБД, одновременно устраняя необходимость выполнения каждым прикладным процессом прямых запросов к СУБД, число одновременно работающих пользователей СУБД существенно сокращается. В подавляющем большинстве случаев СУБД обслуживает только одного "пользователя" -
TP-монитор. Это особенно важно, когда СУБД относится к классу "2N", поскольку в этом случае используется только один теневой процесс (для обеспечения соединения с TP-монитором), а не по одному процессу на каждый процесс конечного пользователя (рис. 2.4). Это может существенно сократить накладные расходы, связанные с переключением контекста на сервере СУБД.

Рис.2.4. Системы СУБД клиент/сервер сконфигурированные для работы с мониторами
обработки транзакций. Теневой процесс на серверной системе появляется, когда
СУБД использует архитектуру "2N".

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

Рекомендации:

• TP-мониторы могут рассматриваться как кандидаты для включения в состав системы, когда доступен исходный текст приложения.
• TP-мониторы следует использовать для интеграции в корне отличных источников информации базы данных.
• TP-мониторы особенно полезны для сокращения трафика клиент/сервер на сетях с низкой полосой пропускания или глобальных сетях.
• Применение системе TP-монитора следует рассматривать, когда должно обслуживаться большое количество пользователей и используемая СУБД предпочитает или требует реализации архитектуры "2N".

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