Menu de navegação

[Sousa04Participante]

Bom dia a Todos,

Andei realizando umas pesquisas sobre esses parâmetros do kernel e cheguei a seguinte dúvida:

kernel.shmall – controla o tamanho total do segmento de memória compartilhada
e
kernel.shmmax – controla o tamanho do segmento de memória que uma aplicação pode utilizar. E segundo a documentação, a Oracle sugere definir esse parâmetro como a Metade de memória física.

Dúvida:
Se shmall controla o tamanho máximo, então não pode ser menor que shmmax?
Tenho visto várias configurações do tipo
kernel.shmmax = 16865718272
kernel.shmall = 2097152

shmmax maior que shmall.

Tenho 3 ambientes onde trabalho e em todos o parâmetro shmmax é maior que shmall isso está certo??

Dei uma lida em outros post aqui no forúm mas não me ficou muito claro. Desde já agradeço a todos

Vlw

🙂

[vieriParticipante]

kernel.shmmax = 16865718272
kernel.shmall = 2097152

Servidores de 32Gb de ram possui essa config, está correto.
Pois a Oracle recomenda que a SGA seja metade da ram disponivel.

A sua interpretação que está errada com relação ao conceito de segmento.
Segmento é uma fatia e não uma totalidade, a memoria é dividida em diversos segmentos de 2Mb, e uma plicação só pode alocar
16Gb, ou seja o tamanho máximo da SGA será de 16Gb,
terá centenas de segmentos de tamanho definidos por SHMALL,
até chegar a um total máximo de 16Gb.

Kernel.shmall – controla o tamanho total do segmento de memória compartilhada ==> OK
e
kernel.shmmax – controla o tamanho(somátorio) de diversos segmentos de memória que uma aplicação pode utilizar. E segundo a documentação, a Oracle sugere definir esse parâmetro como a Metade de memória física.

eclareceu ?

[Sousa04Participante]

Olá Vieri Blz!!

Achei muito legal sua explicação
Deixa eu ver se saquei a jogada.

SHMALL=2097152 defini diversos segmentos cada um com 2mb.
e
SHMMAX=16865718272 vai controlar o somatorio desses segmentos até um limite 16gb

bem, se for isso tenho q alterar um dos servidores
veja:
$ ipcs -a

—— Shared Memory Segments ——–
key shmid owner perms bytes nattch status
0x00000000 4161539 root 644 80 2
0x00000000 4194309 root 644 16384 2
0x00000000 4227078 root 644 280 2
0x00000000 27983880 oracle 640 16777216 31
0x00000000 28016649 oracle 640 536870912 31
0x00000000 28049418 oracle 640 536870912 31
0x00000000 28082187 oracle 640 536870912 31
0x00000000 28114956 oracle 640 536870912 31
0x00000000 28147725 oracle 640 536870912 31
0x00000000 28180494 oracle 640 536870912 31
0x00000000 28213263 oracle 640 536870912 31
0x5ee5dce0 28246032 oracle 640 522190848 31

—— Semaphore Arrays ——–
key semid owner perms nsems
0x651133e8 10813441 oracle 640 154

—— Message Queues ——–
key msqid owner perms used-bytes messages

o maior segmento alocado para o Oracle é 536870912 pois shmmax=512MB
E somando esses segmentos chego a um total de 4297064448 bytes ou 4Gb
pois meu parâmetro sga_max_size=4Gb

porém
meu parâmetro shmall=2097152

Está meio confuso né.

A única alteração será no shmmax né?

😀

[vieriParticipante]

é isso ai mesmo…

Para você alocar a SGA em apenas uma área contigua de memôria..
que é o ideial vc precisa alterar esse valor de shmmax.

cfrme abaixo:

—— Shared Memory Segments ——–
key shmid owner perms bytes nattch status
0x7f231aac 0 oracle 640 2518679552 32
0x790206ce 32769 oracle 666 404 0

—— Semaphore Arrays ——–
key semid owner perms nsems
0xb94bd744 98304 oracle 640 125
0xb94bd745 131073 oracle 640 125
0xb94bd746 163842 oracle 640 125
0xb94bd747 196611 oracle 640 125
0xb94bd748 229380 oracle 640 125
0xb94bd749 262149 oracle 640 125
0xb94bd74a 294918 oracle 640 125
0xb94bd74b 327687 oracle 640 125
0xb94bd74c 360456 oracle 640 125
0x790206ce 393225 oracle 666 1

—— Message Queues ——–
key msqid owner perms used-bytes messages

SQL> show sga

Total System Global Area 2516582400 bytes
Fixed Size 1263368 bytes
Variable Size 369101048 bytes
Database Buffers 2130706432 bytes
Redo Buffers 15511552 bytes

Percebe como minha SGA está contigua, ela está
com apenas um Key definido no output do comando.
Ao contrário da sua congfig que precisou alocar varios semgmentos
de memôria compartilhada.

entendeu?

[vieriParticipante]

outro exemplo com uma SGA maior de 7Gb.

[oracle@ ~]$ ipcs -a

—— Shared Memory Segments ——–
key shmid owner perms bytes nattch status
0x59e234d8 131073 oracle 600 132120576 17
0xf8eba608 163842 oracle 600 7568621568 309

—— Semaphore Arrays ——–
key semid owner perms nsems
0x615b9f44 98304 oracle 640 44
0xed4397a8 229377 oracle 660 125
0xed4397a9 262146 oracle 660 125
0xed4397aa 294915 oracle 660 125
0xed4397ab 327684 oracle 660 125
0xed4397ac 360453 oracle 660 125
0xed4397ad 393222 oracle 660 125
0xed4397ae 425991 oracle 660 125
0xed4397af 458760 oracle 660 125
0xed4397b0 491529 oracle 660 125

—— Message Queues ——–
key msqid owner perms used-bytes messages

Kernel sysctl configuration file for Red Hat Linux

#

For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and

sysctl.conf(5) for more details.

Controls IP packet forwarding

net.ipv4.ip_forward = 0

Controls source route verification

net.ipv4.conf.default.rp_filter = 1

Do not accept source routing

net.ipv4.conf.default.accept_source_route = 0

Controls the System Request debugging functionality of the kernel

kernel.sysrq = 0

Controls whether core dumps will append the PID to the core filename.

Useful for debugging multi-threaded applications.

kernel.core_uses_pid = 1

#Parametros recomendados na documentacao da Rightway para o Oracle Rac
kernel.shmall = 2097152
kernel.shmmax = 8454799360
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 658576
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 1048536
net.core.wmem_max = 1048536
vm.nr_hugepages = 4096

[vieriParticipante]

complementando para não ficar coisa mal entendida…

O parâmetro SHMMAL ficou extrano para você com um valor
menor que o SHMMAX, porque para saber o valor total dele,
vc precisa multiplicar SHMMAX pelo PAGESIZE do S.O,
ai vc ira obter um valor similar(ou maior) ao SHMMAX.

ex:

[oracle@depdata02 ~]$ getconf PAGE_SIZE
4096

shmall:2097152

SQL> select 4096*2097152 from dual ;

4096*2097152

8589934592 = > Valor total da memória compartilhada

Ou seja você poderar ter 2097152 páginas de memôria de 4096bytes.

Acho que agora ficou mais claro.

Se tiver algum SA(sys admin) por ai querendo complementar ou até mesmo concertar algo fique a vontade. Mas acho que está tudo OK, nas
definições.
Só pesquisei a minha mente e ela ja está bombardeada de informações …rsrs

[vieriParticipante]

Esses dois parametros são mto parecidos a diferença básica é que o SHMMAX controla o valor máximo de uma aplicação.

E o SHMALL controla a valor máximo dessa área compartilhada.
Oque confunde é que o SHMALL não está em bytes e sim um valor inteiro,
que são as páginas definidas pelo parâmetro hugepages.

Acho que a informação que passei no primeito post que ele(SHMALL) controla o tamanho de segmento está errado.
Na verdade ele define que a quantidade de páginas que irão compor a memôria compartilhada e não o tamanho sequencial de diversos segmentos de 2Mb.. isso é falso OK…

Aonde entra diversos segmentos nessa história,
quando vc tem o SGMMAX com valor baixo e a SGA com valor alto, ai vc terá vários segmentos em memôria cfrme vc mostrou lá em cima com o comando ipcs.

Segmento= Aréa de memória compartilhada alocada para uma aplicação,
pode ser composta por diversos segmentos, ou apenas um segmento pode compor a memôria compartilhada usada por uma aplicação.

SHMMAX= Valor máximo de memôria compartilhada alocada para uma aplicação.
SHMALL=Qtd de paginas , que defini o tamanho total de uma memória compartilhada, por N processos.

Outro detalhe, vc só conseguiu alocar 4GB de SGA, pq o seu parâmetro
shmall=2097152 multiplicado pelo pagesize, é igual ou maior que 4Gb,
se não vc levaria erro de out of memory.

Pronto Acho que para um DBA já está mas que o suficiente, esse assunto é meio confuso pq no doc de instalação do Oracle tem apenas os valores,
mas não tem explicado seu porque nem oque representa.

[CleitonHanzenParticipante]

Opá…

Lembrando que a Oracle “Oficialmente” não suporta o SHMMAX > que 4GB. Note: 567506.1 no metalink…. 😉

[Sousa04Participante]

Boa tarde Vieri,

Vc aniquilou totalmente a dúvida quando no trecho “E o SHMALL controla a valor máximo dessa área compartilhada.
Oque confunde é que o SHMALL não está em bytes e sim um valor inteiro,
que são as páginas definidas pelo parâmetro hugepages. ”

“SHMALL=Qtd de paginas , que defini o tamanho total de uma memória compartilhada, por N processos. ”

Realmente esse é um assunto que confunde mesmo.

fiz o seguinte teste em uma pequena base
Perceba os dados
$ free -mt
total used free shared buffers cached
Mem: 502 215 286 0 12 156
-/+ buffers/cache: 46 456
Swap: 1023 0 1023
Total: 1526 215 1310

Total System Global Area 419430400 bytes
Fixed Size 1219760 bytes
Variable Size 96469840 bytes
Database Buffers 318767104 bytes
Redo Buffers 2973696 bytes

$ cat /proc/meminfo | grep Huge
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB

$ getconf PAGE_SIZE
4096

Memória 502 Mb
SGA 400 Mb
PAGE_SIZE 4096

kernel.shmmax=263372800
kernel.shmall=103168

shmmax 250 MB
shmall 103168 * 4096 = 403 Mb (Superior a SGA)

$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 – Production on Mon Aug 23 07:29:06 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area 419430400 bytes
Fixed Size 1219760 bytes
Variable Size 96469840 bytes
Database Buffers 318767104 bytes
Redo Buffers 2973696 bytes
Database mounted.
Database opened.

iniciado sem problema
BLZ!!!! Agora eu vou diminuir o parâmetro shmall para o mesmo valor da SGA

kernel.shmall=102400 * 4096 = 400Mb

eeee tham tham!!!!!

$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 – Production on Mon Aug 23 08:57:10 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to an idle instance.

SQL> startup
ORA-27102: out of memory
Linux Error: 28: No space left on device

Cabuloso!!!! rsrsrs
É como vc disse na documentação não tem explicado nem como funciona e nem para que serve. Aponta apenas valores. Eu tbm tinha em mente que esse valor (kernel.shmall = 2097152 ) era apenas um exemplo. Agora está bem mais claro.

Vlw

[vieriParticipante]

CleitonHanzen,

[oracle@depdata01 ~]$ ipcs -a

—— Shared Memory Segments ——–
key shmid owner perms bytes nattch status
0x00fa5a34 131073 oracle 600 132120576 16
0xccf0a4fc 163842 oracle 600 7585398784 177

—— Semaphore Arrays ——–
key semid owner perms nsems
0x57aff660 98304 oracle 640 44
0xa0e11f08 229377 oracle 660 125
0xa0e11f09 262146 oracle 660 125
0xa0e11f0a 294915 oracle 660 125
0xa0e11f0b 327684 oracle 660 125
0xa0e11f0c 360453 oracle 660 125
0xa0e11f0d 393222 oracle 660 125
0xa0e11f0e 425991 oracle 660 125
0xa0e11f0f 458760 oracle 660 125
0xa0e11f10 491529 oracle 660 125

—— Message Queues ——–
key msqid owner perms used-bytes messages

#Parametros recomendados na documentacao da Rightway para o Oracle Rac
kernel.shmall = 2097152
kernel.shmmax = 8454799360
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128

esse lance de 4Gb não seria para ambientes 32bits ?

Estou com meu parâmetro com 8Gb, e está alocando os 8Gb corretamente e não dois de 4Gb, caso o parâmetro só suportasse até 4Gb.

[vieriParticipante]

Sousa04,

seu teste foi perfeito para mostrar o funcionamento do
SHMMAL e aconteceu exatamente como lhe falei.

Esse assunto é complicado se ficar alguns meses se tocar nele,
quando vai ler já esqueceu denovo.

Mas depois destes post foi pro sangue!

[CleitonHanzenParticipante]

[quote=”vieri”:3425ibwd]CleitonHanzen,

.
.
.
.

esse lance de 4Gb não seria para ambientes 32bits ?

Estou com meu parâmetro com 8Gb, e está alocando os 8Gb corretamente e não dois de 4Gb, caso o parâmetro só suportasse até 4Gb.[/quote]

Vieri,

No começo também achei meio estranho esse note, mas como o mesmo explica:

”
Occasionally, Customers may erroneously think that that setting the SHMMAX as recommended in this NOTE limits the total SGA to just less than 4Gb. That is not true. Setting the SHMMAX as recommended only causes a few more “shared memory segments” to be used for whatever total SGA that you subsequently configure in Oracle.”

Outro ponto interessante:

“One last data point for 64-bit Linux systems: A SHMMAX value of 4Gb or greater will lead to coredump limitations.”

[vieriParticipante]

Acabei de ler a nota… e ela é em clara.
É uma recomendação e não uma limitação!

😉

Check Oracle metalink Doc ID:567506.1

“Oracle Global Customer Support officially recommends a ” maximum” for SHMMAX of just less than 4Gb, or 4294967295.

The maximum size of a shared memory segment is limited by the size of the available user address space. On 64-bit systems, this is a theoretical 2^64bytes. So the “theoretical limit” for SHMMAX is the amount of physical RAM that you have. However, to actually attempt to use such a value could potentially lead to a situation where no system memory is available for anything else. Therefore a more realistic “physical limit” for SHMMAX would probably be “physical RAM – 2Gb”.

In an Oracle RDBMS application, this “physical limit” still leaves inadequate system memory for other necessary functions. Therefore, the common “Oracle maximum” for SHMMAX that you will often see is “1/2 of physical RAM”. Many Oracle customers chose a higher fraction, at their discretion.

Occasionally, Customers may erroneously think that that setting the SHMMAX as recommended in this NOTE limits the total SGA to just less than 4Gb. That is not true. Setting the SHMMAX as recommended only causes a few more “shared memory segments” to be used for whatever total SGA that you subsequently configure in Oracle. For additional detail, please see Document 15566.1, “SGA, SHMMAX, Semaphores and Shared Memory Explained”

One last data point for 64-bit Linux systems: A SHMMAX value of 4Gb or greater will lead to coredump limitations. If a customer is willing to forfeit complete and successful core file generation under any and all circumstances, then a SHMMAX value of 4Gb or greater is fine. It is for this reason that Oracle Global Customer Support officially recommends a ” maximum” for SHMMAX of just less than 4Gb, or 4294967295.”

Quero ver me provar que é melhor ter vários segmentos pequenos do que alguns grandes.

Aúnica melhoria são para coredumps…

[CleitonHanzenParticipante]

[quote=”vieri”:326joli1]Acabei de ler a nota… e ela é em clara.
É uma recomendação e não uma limitação!

😉

[/quote]

Exatamente….não me expressei corretamente… 😛

[vieriParticipante]

Tudo claro como o tempo aqui no R.J , espero que continue assim
no feriado!

😉

[Autor]

Posts