DeepEdit!

Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Представление V$MTS

Чтобы извлечь пользу из информации, содержащейся в представлении V$MTS, в первую очередь необходимо определить, какое значение параметра mts_max_servers используется базой данных. Для этого войдите в базу данных как SYS, SYSTEM или INTERNAL и введите команду show parameters mts_max_servers. Сравнив значение mts_max_servers с максимальным числом запущенных серверов, полученным из представления V$MTS, вы сможете решить, нужно ли увеличить количество серверов. Столбцы представления V$MTS перечислены в таблице
Давайте ненадолго остановимся и вспомним, как осуществляется работа через MTS. Клиент обращается к системе с запросом. Диспетчер принимает запрос и помещает его в очередь запросов. Процесс разделяемого сервера обращается к базе данных и возвращает информацию диспетчеру через очередь ответов. Диспетчер пересылает данные клиентскому процессу. Если разделяемых серверов недостаточно для обработки запросов по мере их поступления, очередь будет постоянно заполнена, а обработка запросов займет больше времени. Таким образом, перед просмотром времен ожидания следует выяснить, не использованы ли уже все разделяемые серверы.

Сначала нужно определить, сколько памяти использует каждый разделяемый сервер. В системе UNIX эту информацию можно получить с помощью утилиты ps. Кроме того, вам нужно узнать объем свободной оперативной памяти. Разделив эту величину на размер разделяемого сервера, вы увидите, сколько дополнительных разделяемых серверов может поддерживать система. Конечно, не стоит использовать всю доступную память под разделяемые серверы, но по крайней мере вы будете знать, до какого предела можно увеличивать их число.
На практике значения mts_servers и mts_max_servers обычно выбирают так, чтобы они немного превышали потребность в разделяемых серверах при средней и максимальной нагрузке. Увеличивайте эти параметры постепенно, чтобы найти оптимальные значения для своей системы. Если начнется страничный обмен с диском, уменьшайте значение до тех пор, пока обмен не прекратится, или в машину дополнительную память.
Использование объединения соединений, концентрации соединений и/или балансировки нагрузки на уровне соединения
Определяя, какому из диспетчеров должен быть передан клиентский запрос, прослушивающий процесс учитывает их загрузку, измеряемую числом текущих соединений. После закрытия каждого соединения диспетчеры посылают прослушивающему процессу уведомления, чтобы тот мог следить за числом активных соединений каждого диспетчера. Этот подход известен как балансировка нагрузки на уровне соединения (connection load balancing). Если диспетчеры располагаются на нескольких узлах, то прослушивающий процесс учитывает не только загрузку каждого диспетчера, но и количество соединений с узлами.
Каким образом диспетчер одновременно поддерживает многих пользователей? Ранее это уже обсуждалось, но давайте повторим еще раз. Если клиент не предпринимает никаких действий в течение заданного промежутка времени, механизм тайм-аута временно разрывает его транспортное соединение, сохраняя логическое соединение с диспетчером.
Освобожденное физическое соединение может использоваться диспетчером для приема новых входящих запросов. Когда простаивавший клиент вновь активизируется, диспетчер восстанавливает физическое соединение, действуя от имени клиента.
Подчеркну, что объединение соединений и балансировка нагрузки на уровне соединения возможны только на сервере и только в режиме MTS. Вы также можете задействовать менеджер соединений Oracle и реализовать мультиплексирование клиентских сеансов, чтобы одно транспортное соединение с MTS могло разделяться между многими пользователями. Эта технология, известная под названием нений (connection concentration), сокращает потребность в ресурсах, поскольку сервер может поддерживать множество соединений между процессами, используя гораздо меньшее количество точек приема входящих запросов. Таким образом, концентрация соединений позволяет увеличить общее число клиентов, обслуживаемых сервером. Если развить эту идею дальше и использовать нескольких менеджеров соединений, то можно обеспечить поддержку тысяч параллельных соединений пользователей с сервером. При совместном использовании менеджера соединений и многопоточного сервера количество поддерживаемых соединений возрастает в геометрической прогрессии.
Чтобы разрешить объединение соединений, необходимо включить в параметр mtsdispatchers атрибут pool. Вместе с ним можно использовать дополнительные атрибуты connections, sessions и ticks, которые были описаны в таблице 11.1. Вернемся к приводившемуся ранее примеру, где подсчитывалось начальное количество диспетчеров. Модифицируем этот пример так, чтобы для протокола TCP один диспетчер мог поддерживать 5000 соединений с 1500 сеансами.
Вы можете сконфигурировать диспетчер MTS так, чтобы он поддерживал лишь определенный тип клиентских запросов. Предположим, что обращения к таблице заказов в базе данных SKDL выполняются намного чаще, чем к любым другим таблицам. В этом случае можно SPX — 3000 соединений с 1000 сеансов в каждом:

 









jAntivirus