STU.Part 2

Оперативной памяти почти всегда не хватает если у Вас есть база данных.  Поэтому инженеры начали борьбу за то чтобы ее стало больше -)

На сегодня существует два подхода:

Если у Вас Solaris или Linux (кто бы сомневался в таком ограничении) то вы можете использовать Smart Flash Cache – если очень коротко, то это кэш второго уровня (L2) для Buffer Cache.   Чтобы влючить эту возможность вам понадобится установить параметры db_flash_cache_file (указать устройство) и db_flash_cache_size (указать размер).  Конечно устройство должно быть быстрее наших дисков и поэтому предполагается использовать solid state storage devices.  Подождите, даже SSD  нам придется поставить не один, потому что один диск  скорее всего  не вытянет нужную нам производительность !
Дальше читая документацию мы находим фразу  “can improve response time for read intensive OLTP application”. Мне кажется что это ключевой момент, потому что если приложение write intensive то этот механизм может сделать даже хуже.

Все равно, отличная инженерная идея !  L2 кэш давно  используется при разработке процессоров и пора уже было давно сделать что-нибудь подобное.  К сожалению, даже после прочтения этого поста я не понял как это работает
 - каков алгоритм вытеснения из памяти во  FC
-  скорее всего процесс если ему нужны данные и они во FC считывает их и они попадают обратно во buffer cache. Но так ли это ?

Теперь перечитайте этот пост сначала – все это волшебство только для Solaris и Linux.
Инженеры IBM нанесли ответный удар – технология называется Active Memory Expansion. Они предложили .. сжимать страницы основной памяти, но не все конечно, а какую-то их часть (дальше я предполагаю что и не все типы страниц памяти сжимаются). Для приложения эта технология абсолютна прозрачна и приложения просто видят больше памяти, чем физически есть на машине.

После запуска специальной команды awepat вы сможете увидеть (если у Вас AIX 6 или 7 и машина класса 750 или выше)

True Memory                    : 1.00 GB

SMT Threads                    : 4

Active Memory Expansion        : Enabled

Target Expanded Memory Size    : 1.50 GB

Target Memory Expansion factor : 1.60

Что в моей системе (LPAR) только 1 Gb физической памяти, которая превратилась в 1.5 Gb видимой приложению. Постойте, но чтобы сжимать память нам нужна процессорная мощность?  Да, конечно и поэтому в следующем разделе awepat вы видите

Expansion    Modeled True      Modeled              CPU Usage

Factor       Memory Size       Memory Gain          Estimate

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

     1.00          1.50 GB         0.00 KB [  0%]   0.00 [  0%]

     1.20          1.25 GB       256.00 MB [ 20%]   0.00 [  0%]

     1.60          1.00 GB       512.00 MB [ 50%]   0.18 [ 18%] << CURRENT CONFIG

что доп 512 Mb памяти нам будут стоить  18% от одного  ядра. Нагрузка эта распределяется между всеми ядрами LPAR. Посмотреть % реальной занятости ядер обслуживанием этого механизма  можно с помощью lparstat -c.  Сколько же нам попросить доп памяти по отношению к основной чтобы не убить процессоры ?   По оценкам инженеров пока рекомендуется использовать Expansion factor в районе 1.2 – 1.5.

Два дополнительных замечания:
- все таки это новая возможность и пока рекомендуется ее использовать для test & dev.
- попробовать эту возможность можно совершенно бесплатно и легально в течении 60 дней, ничего покупать не нужно -). А вот дальше придется доплатить, но конечно меньше чем за реальную память.
Как вы видите, теперь ответить на вопрос а сколько у меня памяти отведено  под Oracle весьма непросто. Скажу больше, что на AIX с учетом Active Memory Expantion & Active Memory Sharing вывод команды vmstat может довести до истерики -))) Но об этом на семинаре 29 апреля -)