Итак, есть такая тема, как использование Very Large Memory (VLM) в Oracle 8.1.7 на RHEL3 AS.
Тема возникла по той простой причине, что человеческой информации в интернете я по этому поводу не нашел, а проблема с тем, что невозможно данную версию Oracle заставить использовать под SGA больше 1,7 Gb очень животрепещуща. Ситуация такова, что есть достаточно серьезная железка с 8Gb ОЗУ, 8 HDD, 2*4 CPU с установленным RHEL3 AS Update 6, на которой кроме этого самого Oracle 8i ничего нет. И того максимального количества оперативы(1,7), которого раньше хватало по уши, сейчас хватать резко перестало. Ну тупо количество пользователей системы выросло на порядок. 64 битной версии 8i не существует в природе, и поменять ее на что-то другое невозможно. На ней весь буховский софт крутится, а контора производитель поддерживать его практически перестали, на аксапту они видите ли переваливаются и никакие ораклы им более не антиресны. Так что крутитесь, что называется, как хотите. Вот и приходится.
Короче, сервер в постоянном затыке из-за того, что постоянно читает с диска, а процы затарены под завязку тем, что разруливают ресурсы оперативы между 20-ю - 40-ка активными сессиями. Можно долго рыть события, которые зафаживают систему, но ясно одно - пока не увеличишь количество памяти, которое данная версия оракла может адресовать, рыть дальше бесполезно.
И это дело для настоящих пацанов. Понял я это после того, как НЕДЕЛЮ пытался это сделать, ухоркал 2 тестовые виртуалки, но добился только того, что НИЧЕГО не добился. И если вы думаете, что я пишу это потому, что знаю, как выделить хотя-бы 4 Gb ОЗУ под SGA, то плачьте, ибо это не так!!! Но истинный путь самурая заключается в том, чтобы решить нерешаемую задачу на зависть всем недоделанным нинзям, и выложить ее, решенную и разжеванную, всему сообществу, чтобы любой мог проделать этот же путь не умываясь соплями отчаянья, а с радостью того, что не надо ничего даже понимать, а тупо выполнить набор инструкций и быть в шоколаде.
Но в сторону сантименты и словоблудие....
Вот основные ресурсы, которыми я буду руководствоваться в решении проблемы:
http://www.puschitz.com/TuningLinuxForOracle.shtml
http://www.oracle-base.com/articles/linux/LargeSGAOnLinux.php
На данный момент init.ora выглядит так:
db_name = "main"
instance_name = main
service_names = main
global_names = false
control_files = ("/u02/oradata/main/control01.ctl", "/u02/oradata/main/control02.ctl", "/u02/oradata/main/control03.ctl")
background_dump_dest = /u01/admin/main/bdump
core_dump_dest = /u01/admin/main/cdump
user_dump_dest = /u01/admin/main/udump
utl_file_dir = /u01/admin/main/utl_file_dir
open_cursors = 10000
max_enabled_roles = 148
db_block_size = 8192
db_block_buffers = 110000
db_file_multiblock_read_count = 32
shared_pool_size = 700000000
large_pool_size = 614400
java_pool_size = 50000000
log_buffer = 163840
log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800
processes = 600
timed_statistics = true
log_archive_start = true
log_archive_dest_1 = "location=/u02/arch/main"
log_archive_format = main%s.rdo
remote_login_passwordfile = shared
os_authent_prefix = ""
compatible = "8.1.0"
sort_area_size = 65536
sort_area_retained_size = 65536
job_queue_processes = 4
sysctl.conf выглядит так:
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
kernel.sysrq = 0
kernel.core_uses_pid = 1
kernel.shmmax = 4096000000
kernel.shmmni = 100
kernel.sem = 600 32000 100 128
fs.file-max = 131072
Необходимо увеличить db_block_buffers. На данном этапе даже при незначительном увеличении значения Oracle не стартует, выдает ошибку, будь она неладна:
SVRMGR> ORA-27123: unable to attach to shared memory segment
Linux Error: 22: Invalid argument
Additional information: 1
Additional information: 32768
Первым делом меняем ядро. По умолчанию используется 2.4.21-37.ELsmp (kernel-smp-2.4.21-37.EL)
Ставим ядро 2.4.21-37.ELhugemem (kernel-hugemem-2.4.21-37.EL)
До установки нового ядра /boot/grub/grub.conf выглядит так:
default=0
timeout=10
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
title Red Hat Enterprise Linux AS (2.4.21-37.ELsmp)
root (hd0,0)
kernel /boot/vmlinuz-2.4.21-37.ELsmp ro root=LABEL=/
initrd /boot/initrd-2.4.21-37.ELsmp.img
title Red Hat Enterprise Linux AS-up (2.4.21-37.EL)
root (hd0,0)
kernel /boot/vmlinuz-2.4.21-37.EL ro root=LABEL=/
initrd /boot/initrd-2.4.21-37.EL.img
После установки hugemem ядра он должен выглядеть так:
default=0
timeout=10
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
title Red Hat Enterprise Linux AS (2.4.21-37.ELhugemem)
root (hd0,0)
kernel /boot/vmlinuz-2.4.21-37.ELhugemem ro root=LABEL=/
initrd /boot/initrd-2.4.21-37.ELhugemem.img
title Red Hat Enterprise Linux AS (2.4.21-37.ELsmp)
root (hd0,0)
kernel /boot/vmlinuz-2.4.21-37.ELsmp ro root=LABEL=/
initrd /boot/initrd-2.4.21-37.ELsmp.img
title Red Hat Enterprise Linux AS-up (2.4.21-37.EL)
root (hd0,0)
kernel /boot/vmlinuz-2.4.21-37.EL ro root=LABEL=/
initrd /boot/initrd-2.4.21-37.EL.img
Следующее, что мы сделаем, это настроим параметры ядра для использования 4Gb для Oracle. Для этого отредактируем /etc/sysctl.conf так, чтобы он имел следующий вид:
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
kernel.sysrq = 0
kernel.core_uses_pid = 1
kernel.shmmax = 4294967295
kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.sem = 1000 150000 1000 150
fs.file-max = 131072
Тут заметил такой прикол :) На ядре hugemem с этими параметрами ядра oracle может выделить под SGA меньше оперативы, чем на ядре smp, хотя со слов Пушитса, ситуация должна быть обратной. Я себе чуть мозг не поломал, пока эту закономерность выяснил. Прикольно получается, пытаешься лучше сделать, а получается только хуже. То есть если вы делали все как я говорю, то на данном этапе вы в еще большей жопе, чем были в начале. А свет в конце туннеля еще впереди :)
Спустя неделю....
Этот туннель не для оптимистов.... Чем дальше, тем хуже. Ни на каком линуксе никаким способом сделать то, что хотелось не получилось...
Предположительно сделать это можно на винде 2000 или 2003 с PAE ядром.
Получилось только на Windows 2000 Advanced Server с указанием опции /PAE в boot.ini. Но при этом выделать много оперативы можно только под буферный кэш блоков данных, под shared pool выделить больше не получится, потому что он большую память не использует.
Вот така муйня, малята. Если есть возможность, меняйте 8-ю версию оракла на что-то более современное :) Иначе вам (и нам) удачи не видать...
Тема закрывается.
Читать далее
год назад
