19 августа 2019 года    
Понедельник | 18:40    
Главная
 Новости
Базы данных
Безопасность PC
Всё о компьютерах
Графика и дизайн
Интернет-технологии
Мобильные устройства
Операционные системы
Программирование
Программы
Связь
Сети
 Документация
Статьи
Самоучители
 Общение
Форум







Разделы / Базы данных / Oracle

Новые правила для shared pool в версии 8.1.

Новые правила для shared pool в версии 8.1

28 марта 2001 г.

New pool rules

Стив Адамс

Управление фрагментацией разделяемого пула (shared pool) в Oracle 8.1.

Источник: Новости от Ixora News, ииль 2000 (http://www.ixora.com.au/newsletter/2000_07.htm#pool_rules)

Настройка буфера shared pool в Oracle – один из наиболее сложных видов настройки. К счастью, с нею приходится иметь дело далеко не всем. Большинство администраторов может себе позволить попросту выставить размер shared pool очень большим, так что риск столкнуться в результате этого со снижением производительности для них окажется невелик. Однако если вдруг на сервере в большом количестве выполняются фазы трансляции и исполнения SQL-запросов, к выставлению размера shared pool требуется отнестись с большой осторожностью: неудачный размер может привести к увеличению числа конкурирующих заявок на использование защелок (фиксаторов), которые регулируют работу библиотечного буфера и shared pool (library cache latches и shared pool latches).

Основная причина возникновения конкуренции за использование зашелок shared pool кроется в фрагментации свободной памяти. Если свободная память превращается в большой набор небольших кусков, то процесс, подыскивающий себе кусок по размеру, будет держать защелку shared pool долгое время. Степень фрагментированности свободной памяти очень легко посмотреть с помощью сценария shared_pool_free_lists фирмы Ixora. Для сокращения фрагментации ключевым является закрепление в библиотечном буфере попавших туда объектов, а также выставление размера shared pool в меру необходимого – и не более того.

К счастью, в своей борьбе с фрагментацией свободной памяти вы не одиноки. Фирма Oracle сама предлагает ряд возможностей для снижения фрагментации, а кроме того в самых последних версиях по этой части появились некоторые улучшения.

Сращивание “с передним”

Если кусок памяти освобождается, и следующий кусок тоже свободен, то Oracle соединит эти два свободных куска в один. Это называется сращиванием “с передним”. Такой метод эффективен, так как для проверки занятости системе достаточно заглянуть в 16-байтовый заголовок следующего куска. В том же заголовке хранятся указатели на предыдущий и следующий куски в свободном списке. Их наличие позволяет просто удалить в случае надобности этот кусок из списка свободных и ликвидировать возникшую в списке “дыру”.

По нашим наблюдениям в версии 8.1 Oracle при освобождении ранее занятого куска сращивает его теперь не с одним, как раньше, а со всеми следующими сразу после него смежными свободными кусками. Это приводит к тому, что “сбрасывать” вручную состояние shared pool командой flush для сращивания свободных кусков в один теперь нужно реже, чем это требовалось раньше. Соответственно, в таком ручном “сбросе” пользы теперь будет значительно меньше, особенно когда shared pool сформирована без запаса.

Резерв постоянной памяти

Резерв постоянной памяти – это участок свободной памяти, оставляемый при старте системы в shared pool “про запас”. Так, если параметр shared_pool_size выставлен в 10,000,000 байт и структуры постоянной (permanent) памяти требуют с самого старта 1,000,000 байт плюс к этому дополнительно, то общий размер shared pool будет 11,000,000 байт. В момент запуска системы, тем не менее, для использования будет выдано из shared pool 5,500,000 байт, а остальные 4,500,000 байт свободной памяти будет зарезервировано в виде куска постоянной основной памяти в “одну кассу” с 1,000,000 байт постоянной памяти. Резерв постоянной памяти освобождается по мере необходимости – всякий раз по 50% от имеющегося запаса.

Освобождаемые в процессе работы куски из резерва постоянной памяти оказываются фрагментированы намного менее своих “собратьев”, доступных для использования с самого начала. Однако в версии 7 выделение памяти из резерва осуществлялось неоправданно долго, так что нередко предпочтительнее оказывалось освободить давно неиспользуемые куски в соответствии с LRU-списком. В версии 8 освобождению “старых” кусков (по LRU-списку) всегда предшествует попытка найти место в резерве постоянной памяти.

Резервный пул

Резервный пул (а точнее – резервный список внутри shared pool) не следует путать с резервом постоянной памяти. Резервный пул имеет постоянное предназначение выдавать большие куски памяти, в то время как резерв постоянной памяти выступает в качестве временного резерва, на время старта системы, для предотвращения избыточной фрагментации. Тем не менее, размеры этих двух областей памяти связаны друг с другом. Размер резервного пула не может быть больше 20% shared pool; его наличие приводит к тому, что резерв постоянной памяти не будет освобождаться чересчур быстро и фрагментация уменьшится.

Однако начиная с версии 8.0, когда использование резервного пула стало обязательным, он нередко в процессе работы оставался нетронутым. Этому способствовали два обстоятельства. Во-первых, в последних версиях Oracle просто берет большие куски из shared pool, если находит в свободном списке кусок достаточно большого размера, не прибегая к просмотру LRU-списка в поисках кандидатов на освобождение памяти в компьютере. А во-вторых, Oracle теперь очень редко нуждается в кусках памяти, больше 5000 байт (значение параметра _shared_pool_reserved_min_alloc по умолчанию). Минимально допустимое значение для этого параметра доведено до 4000 байт, и использование этого значения позволяет вам более успешно справляться с фрагментацией памяти, уменьшая риск появления ошибки ORA-4031 и не требуя обращения к LRU-списку при необходимости размещения кусков в диапазоне от 4000 до 5000 байт.

Скрипт shared_pool_free_lists.sql

-------------------------------------------------------------------------------

--

-- Script: shared_pool_free_lists.sql

-- Purpose: to check the length of the shared pool free lists

-- For: 8.1.6 to 8.1.7

--

-- Copyright: (c) Ixora Pty Ltd

-- Author: Steve Adams

--

-------------------------------------------------------------------------------

@save_sqlplus_settings

select

decode(

sign(ksmchsiz - 812),

-1, (ksmchsiz - 16) / 4,

decode(

sign(ksmchsiz - 4012),

-1, trunc((ksmchsiz + 11924) / 64),

decode(

sign(ksmchsiz - 65548),

-1, trunc(1/log(ksmchsiz - 11, 2)) + 238,

254

)

)

) bucket,

sum(ksmchsiz) free_space,

count(*) free_chunks,

trunc(avg(ksmchsiz)) average_size,

max(ksmchsiz) biggest

from

sys.x_$ksmsp

where

inst_id = userenv('Instance') and

ksmchcls = 'free'

group by

decode(

sign(ksmchsiz - 812),

-1, (ksmchsiz - 16) / 4,

decode(

sign(ksmchsiz - 4012),

-1, trunc((ksmchsiz + 11924) / 64),

decode(

sign(ksmchsiz - 65548),

-1, trunc(1/log(ksmchsiz - 11, 2)) + 238,

254

)

)

)

/

@restore_sqlplus_settings

 

Вид выходного листинга

SQL> @shared_pool_free_lists

BUCKET FREE_SPACE FREE_CHUNKS AVERAGE_SIZE BIGGEST

---------- ---------- ----------- ------------ ----------

0 166344 3872 42 72

1 32208 374 86 96

4 928 1 928 928

6 11784 4 2946 3328

 

 Новые правила для shared pool в версии 8.1.
Лента новостей


2006 (c) Copyright Hardline.ru