среда, 18 ноября 2009 г.

Shared-сервер и large_pool_size

Когда мы строим масштабируемое решение на основе Oracle Shared Server, не следует забывать о правильном выборе large_pool_size.

Если вы не хотите получить проблем - минимальной из которых будет неожиданное снижение скорости отклика БД при резком увеличении нагрузки (даже при использовании connection pooling), а максимальной - падение экземпляра с ошибкой 7445 (даже при использовании ASMM) - необходимо устанавливать достаточно большое значение вышеупомянутого параметра.

Окей, каковы оценки и как можно определить потребное количество памяти либо как промониторить использование large pool?

Достаточно приличной начальной цифрой будет следующее соотношение: примерно 30 Мб large pool на каждые 100 коннектов к БД.

Однако, при использовании shared server позади веб-сервера этого может оказаться недостаточно. Средняя цифра shared_pool_size для относительно некрупного веб-сервера с ожидаемой нагрузкой 700 веб-сессий (при настройках shared-сервера на прием до 2000 одновременных сессий) составляет свыше 64 Мбайт.

Насколько выше?

Попробуем взглянуть.

SQL> show parameter large_pool_size

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
large_pool_size big integer 100M

SQL> select sum(value) || ' Bytes' "Total memory for all sessions"
from v$sesstat, v$statname
where name = 'session uga memory'
and v$sesstat.statistic# = v$statname.statistic#; 2 3 4

Total memory for all sessions
----------------------------------------------
16537248 Bytes

16 мегабайт при не очень высокой установившейся нагрузке.

Сколько памяти UGA за период задействовалось в максимуме?

SQL> select sum(value) || ' Bytes' "Max memory for all sessions"
from v$sesstat, v$statname
where name = 'session uga memory max'
and v$sesstat.statistic# = v$statname.statistic#; 2 3 4

Max memory for all sessions
----------------------------------------------
22971128 Bytes

22 мегабайта.

Величина кажется не очень большой и становится непонятно, зачем мы выделили 100 мегабайт large pool?

Однако не следует забывать, что у нас включен пулинг соединений:

SQL> show parameters dispatchers

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
dispatchers string (ADDRESS=(PROTOCOL=tcp)(POOL=o
n)(TICK=1)(CONNECTIONS=100)(SE
SSIONS=1000)(SERVICE=SUN11_XPT
))(DISPATCHERS=2)
max_dispatchers integer 5

что означает, что возможно внезапное и резкое увеличение нагрузки, которое, в свою очередь, способно сильно увеличить длину очередей (напоминаю, что пулинг соединений повторно использует лишь физические ресурсы соединений - сокеты, что до увеличения объема обработки, стоящего в очереди - то он никуда не девается), и, соответственно, потребность в UGA.

Вывод из всего вышесказанного следующий.

Относительно маленький large pool бывает лишь в небольших базах. В масштабируемых конфигурациях большой пул оправдывает свое название и должен становиться действительно большим.CVYFV92SG7U4