shmmax

11gR2 32-разрядный на 32-разрядном же SUSE.
RAM = 8 Gb

1) Каков оптимальный размер SHMMAX? Я выставил согласно документации 4Гб. И (что меня еще больше волнует) каков оптимально-максимальный размер памяти PGA/SGA, выделяемый при инсталляции. По умолчанию предлагает 3 с чем-то. А можно ли вплотную приблизить к 4 Гб (ну больше-то, понятно, не дает)? Не порушится ли что-нибудь? И правильно ли я понимаю, что делать больший, чем 4 Гб, SHMMAX и, соотв., увеличивать PGA/SGA не имеет смысла, так как Оракл 32-разрядный?

2) Я с 64-разрядным Ораклом дел не имел, поэтому и спрашиваю. Может, если память есть, взять да и поставить 64-разрядный. Тогда SHMMAX и PGA/SGA можно будет увеличить или все равно только половина оперативной? И кстати, разумно ли для ответственной базы использовать 64-разрядный Оракл - в смысле, не будет ли каких несовместимостей или повышенного кол-ва багов? Например, где-то попадались сообщения (правда, для 10-ки), что там с гетерогенным сервисом проблемы (а может, еще с чем-нибудь?) Или может я все проспал и 64-разрядный Оракл уже является стандартом де-факто? =)

у некотрых и выбора то нет - только 64 и все.....

shmmax определяет максимальный размер одного непрерывного куска (сегмента) разделяемой памяти. Если указать его меньшим, чем требуемый размер SGA, будет выделено несколько сегментов, каждый из которых не превышает shmmax. Максимальное количество сегментов в системе определяется параметром shmmni, по дефолту, вроде, там достаточно (100).
Естественно, что размер сегмента (shmmax) не может превышать размер прямо адресуемой памяти (в 32-битах 2³²-1)

Способы увеличения размера SGA описаны в Oracle® Database Administrator's Reference 11g Release 2 (11.2) for Linux and UNIX-Based Operating Systems

а есть ли метода, выяснить какой из Shared Memory Segments принадлежит какому из запущенных на сервере инстансов?

например:

oracle@nsk-fis04:~>  ps -ef |grep pmon| grep -v 'grep pmon'
oracle   30536     1  0 12:34 ?        00:00:00 ora_pmon_C1
oracle   30828     1  0 12:35 ?        00:00:00 ora_pmon_C2
oracle@nsk-fis04:~> ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 4718593    oracle    640        2667577344 17
0x00000000 4751362    oracle    640        1593835520 17
0x00000000 4784131    oracle    640        1593835520 17
0x69f1791c 4816900    oracle    640        2097152    17
0x00000000 4849669    oracle    640        654311424  14
0x00000000 4620294    oracle    640        2768240640 0
0x00000000 4653063    oracle    640        2768240640 0
0x00000000 4882440    oracle    640        213909504  14
0x00000000 4915209    oracle    640        209715200  14
0xd173d094 4947978    oracle    640        2097152    14

sysresv

Вячеслав Любомудров, спасибо, помогло.

Подниму ка я темку.

Понадобилось мне память оракловую поднастроить. Заодно и с выделением ее в ОС решил разобраться.

Изначально shmmax был 4Г-1 и было выделено несколько сегменов(тоже что-то около 8). После настройки БД решил собрать шаред память в один сегмент:

[root@storage pfile]# sysctl -w kernel.shmmax=3221225472
kernel.shmmax = 3221225472
[root@storage pfile]# [root@storage bdump]# ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 9109504    oracle    600        16777216   29
0x00000000 9240577    oracle    600        1291845632 29
0x00000000 9371650    oracle    600        654311424  29
0x00000000 9502723    oracle    600        318767104  29
0x00000000 9633796    oracle    600        167772160  29
0x00000000 9764869    oracle    600        83886080   29
0x00000000 9895942    oracle    600        33554432   29
0x00000000 10027015   oracle    600        16777216   29
0xeaea2344 10059784   oracle    640        18874368   29

[root@storage bdump]# sysctl -w kernel.shmmax=2147483648
kernel.shmmax = 2147483648
[root@storage bdump]# ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 10092544   oracle    600        16777216   23
0x00000000 10125313   oracle    600        2147483648 23
0x00000000 10256386   oracle    600        218103808  23
0xeaea2344 10289155   oracle    640        220200960  23

[root@storage etc]# uname -a
Linux storage.primbank.ru 2.6.18-92.el5PAE #1 SMP Fri May 23 22:26:05 EDT 2008 i686 i686 i386 GNU/Linux

После каждого изменения параметра инстанс перестартовывал. На сервере кроме БД ничего нет. Теоретически можно списать на фрагментацию памяти - типа при первом старте он нашел только кусок 1291845632 байт, а при втором уже был доступен 2147483648 байт. А размер сегмента это уже случайно наложилось. Но вероятность этого мне кажется исчезающе мала. Опять же, живший до этого инстанс имел много сегментов при shmmax в 4Г. и он точно был запущен на не фрагментированной памяти (стартовал после перезагрузки).

на всякий случай как выглядит БД:

SQL> startup force
ORACLE instance started.

Total System Global Area 2600468480 bytes
Fixed Size                  1275368 bytes
Variable Size             469764632 bytes
Database Buffers         2113929216 bytes
Redo Buffers               15499264 bytes
Database mounted.
Database opened.
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production

Используются hugepages:

[root@storage bdump]# cat /proc/meminfo
MemTotal:      4151124 kB
MemFree:        339624 kB
Buffers:        146096 kB
Cached:         651120 kB
SwapCached:       5852 kB
Active:         638904 kB
Inactive:       569560 kB
HighTotal:     3275648 kB
HighFree:        62560 kB
LowTotal:       875476 kB
LowFree:        277064 kB
SwapTotal:     4080424 kB
SwapFree:      4056076 kB
Dirty:              20 kB
Writeback:           0 kB
AnonPages:      413436 kB
Mapped:         117804 kB
Slab:            29044 kB
PageTables:      23856 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   4886224 kB
Committed_AS:  1408908 kB
VmallocTotal:   116728 kB
VmallocUsed:      4000 kB
VmallocChunk:   112400 kB
HugePages_Total:  1240
HugePages_Free:    209
HugePages_Rsvd:    105
Hugepagesize:     2048 kB

Кто-нибудь может объяснить зависимость размера и кол-ва сегментов от значения shmmax?

Судя по HugePages_Total, HugePages_Free, больших страниц страниц не достаточно. Предлагаю сконфигурировать Huge Pages, чтобы вмещался сегмент 2602565632 байт. Также проверить soft memlock, hard memlock, может ли он блокировать такое кол-во памяти.

Действительно, сумма сегментов ровно на 2М больше, чем рапортует оракл при старте. Но тогда мне становится непонятен механизм использования hugepages - до этого если я промахивался с его размером в меньшую сторону, БД при старте просто не использовала hugepages. Получается если промахнулся на одну страницу, то она(hugepages) как-то может пользоваться?

tail /etc/security/limits.conf
...
oracle soft memlock 3145728 #2097152
oracle hard memlock 3145728 #2097152

Но это же общее кол-во памяти которое ему позволено лочить? Есть какая-то связь с "какими кусками он будет это делать"?

wurdu
Предлагаю сконфигурировать Huge Pages, чтобы вмещался сегмент 2602565632 байт. Также проверить soft memlock, hard memlock, может ли он блокировать такое кол-во памяти.

Что б уж не было оговорок сделал все на рядом стоящем сервере:

изначально:

[root@storage2 ~]# ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 1507328    oracle    600        16777216   14
0x00000000 1638401    oracle    600        1291845632 14
0x00000000 1769474    oracle    600        637534208  14
0x00000000 1900547    oracle    600        318767104  14
0x00000000 2031620    oracle    600        167772160  14
0x00000000 2162693    oracle    600        83886080   14
0x00000000 2293766    oracle    600        33554432   14
0x19eab63c 2326535    oracle    600        35651584   14

[root@storage2 ~]# cat /proc/sys/kernel/shmall
268435456
[root@storage2 ~]# grep Huge /proc/meminfo
HugePages_Total:  1280
HugePages_Free:   1101
HugePages_Rsvd:   1054
Hugepagesize:     2048 kB
[root@storage2 ~]# uname -a
Linux storage2.primbank.ru 2.6.18-92.el5PAE #1 SMP Fri May 23 22:26:05 EDT 2008 i686 i686 i386 GNU/Linux
[root@storage2 ~]# grep lock /etc/security/limits.conf
#        - memlock - max locked-in-memory address space (KB)
#        - locks - max number of file locks the user can hold
oracle soft memlock 3145728 #2097152
oracle hard memlock 3145728 #2097152

Насколько я понимаю в hugepages влазим. по memlock вопросов нет.

далее:

[root@storage2 ~]# sysctl -w kernel.shmmax=2147483648
kernel.shmmax = 2147483648
[root@storage2 ~]# ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 2359296    oracle    600        16777216   14
0x00000000 2392065    oracle    600        2147483648 14
0x00000000 2523138    oracle    600        218103808  14
0x19eab63c 2555907    oracle    600        203423744  14

[root@storage2 ~]# sysctl -w kernel.shmmax=4294967295
kernel.shmmax = 4294967295
[root@storage2 ~]# ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 2654208    oracle    600        16777216   14
0x00000000 2785281    oracle    600        1291845632 14
0x00000000 2916354    oracle    600        637534208  14
0x00000000 3047427    oracle    600        318767104  14
0x00000000 3178500    oracle    600        167772160  14
0x00000000 3309573    oracle    600        83886080   14
0x00000000 3440646    oracle    600        33554432   14
0x19eab63c 3473415    oracle    600        35651584   14

И чтоб убрать вопросы с фрагментацией памяти контрольный выстрел:

[root@storage2 ~]# sysctl -w kernel.shmmax=2147483648
kernel.shmmax = 2147483648
[root@storage2 ~]# ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 3506176    oracle    600        16777216   14
0x00000000 3538945    oracle    600        2147483648 14
0x00000000 3670018    oracle    600        218103808  14
0x19eab63c 3702787    oracle    600        203423744  14

БД перестартовывал в соседнем окне:

SQL> startup force mount
ORACLE instance started.

Total System Global Area 2583691264 bytes
Fixed Size                  1275344 bytes
Variable Size             469764656 bytes
Database Buffers         2097152000 bytes
Redo Buffers               15499264 bytes
Database mounted.
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production