Labrīt !

Jautājums par srahed memory uz 10.2.0.4 RAC, RHEL4 x64 (22GB RAM, 2
instances).

Kā pareizi būtu jāaprēķina kernel memory parametri kernel.shmall un
kernel.shmmax.
Atradu divas pieejas:

SHMMAX:
1. Sum of all SGAs
2. 75% of total memory

SHMALL:
1. Set shmall equal to the sum of all the SGAs on the system, divided
by the page size (getconf PAGE_SIZE)
2. Divide the SHMMAX value by the Hugepagesize (grep Hugepagesize /
proc/meminfo|awk '{print $2}')

Manā gadījumā Hugepagesize= 2048, bet pagesize = 4096

Jautājums:
Kuru pieeju izmantot ? Vai Hugepagesize kaut kā ir jāieslēdz ?

Un vai aprēķinos jāņem vērā PGA atmiņas apjoms ?

Piemērs - total RAM = 22Gb, 75% = 18.7 GB ->varu atdot ORACLE
(SHMMAX). Šeit "jāietilpst" SGA+PGA, piemēram 16 SGA, 2 PGA. Rēķinot
SHMALL dalu 18.7 (vai 16 ?) ar 4096 (vai 2048 ?)..

G-as

Sveiks,

shmall nosaka, cik sistēma kopumā ļaus rezervēt shared memory,
attiecīgi konfigurējot šo parametru jāņem vērā kopējais abu instanču
SGA apjoms.
shmmax nosaka viena segmenta max izmēru un tam jābūt lielākam par lielāko SGA.

Kādēļ shmmax iesaka aprēķināt kā " Sum of all SGAs" nezinu, ja ir kāds
speciālists, varbūt var pakomentēt !?

Ja Tu aprēķinos izmanto Hugepagesize, tad paŗliecinies par
Hugepagesize mērvienībām. Man šķiet, ka tie 2048 ir KB, nevis baiti
...

Sandijs

2010. gada 1. novembris 10:46 girtas <girts.api...@gmail.com> rakstīja:

Girts,

Personīgi es izmantoju Oracle rekomendētas formulas (75%, /PAGE_SIZE),
vienkārši tāpēc, ka šie divi parametri ir tikai maksimāli atļautie limiti.
Man negribas (nav atļauts), katru reizi, kad izdomāju palielināt sga izmēru,
mainīt kernel parametrus, tāpēc, es izmantoju pēc iespējas lielākas
vērtības.

Šeit ir ļoti labs apraksts, ko šie parametri īsti nozīme (kas sakrīt ar
Sandija teikto):

http://www.freelists.org/post/oracle-l/Calculating-SHMMAX,2

Par hugepagesize pilnīgi pievienojos Sandijam. Ja tu izmantosi SHMMAX
divided by the Hugepagesize, tad jebkurā gadījumā, tev SHMALL, būs lielāks
par Oracle rekomendēto SHMALL / 4k, tāpēc nekas briesmīgs nenotiks. Ja tu
izmantosi SHMMAX dividend by HugePagesize*1024, tad gan SHMALL būs pārāk
mazs.

Best regards,
 Edgar Chupit
 callto://edgar.chupit

2010/11/1 Sandijs <sand...@gmail.com>

Ja jau šajā grupā tauta sāka runāt par dziļi tehniskām lietām, tad gribēju
padalīties ar vienu secinājumu un jautājumu.
Secinājums: V$SEGMENT_STATISTICS lauks value pie kaut kāda maksimālā
lieluma rotē, t.i. atsāk skaitīties no nulles.
Rezultāts: pēc kāda laika informācija šajā viewā ir bezjēdzīga, izņemot
ķēpīgu un sarežģītu divu snapshotu ņemšanu un salīdzināšanu.
Jautājums: Vai kāds zin kur atrast kādai ORACLE versijai kāds ir šis
maksimālais lielums? Un vai tomēr kaut kur iespējams atrast pilno vērtību?
RX
P.S. Ar googoļonkuli aprunājos, jamais neko jēdzīgu nemācēja pateikt (vai
es nemācēju pajautāt ;-))

Nepateikšu pie kura lieluma šis rotē (droši vien kādas divnieka
pakāpes ;), bet info no šī skatījuma bez laika atskaites jebkurā
gadījumā ir diezgan bezjēdzīga, jo:
1) ko nozīmē tas, ka kāda tabulai piemēram ir miljons logical reads?
Praktiski neko, ja nav zināms cik ilgā laikā tas noticis.
2) ir ļoti būtiska starpība, vai piemēram šos miljons lasījumus
ģenerēja fona process naktī, kad visiem ir +- vienalga, kas notiek un
cik ātri notiek, vai tos ģenerē kāds pīķa stundā, kad visiem tā jau
velk uz necenzētiem vārdiem :)

Es teiktu, ka vienīgā jēga šim skatījumam ir tikai tad, ja to lieto kā
deltu pa kādu (relatīvi īsu) laika posmu. Citādi šādām kumulatīvām
statistikām kopš laiku sākumiem (ok instances starta) pa visām sesijām
jēgas ir praktiski 0. Ja vien tev nevajag priekšniecībai skaistu
vizuālu atskaiti - O mēs esam nolasījuši šai milzu tabulā tik un tik
daudz datus, bet šitai par tik mazāk :)

Gints
http://datubazes.wordpress.com

2010. gada 1. novembris 13:27  <Eriks.Mier...@seb.lv> rakstīja:

Analoģija, manuprāt ir sekojoša:
Jums ir office, piem 200 kv.m
Jums jāsadala vietu dažadu projektu (DB) vajadzībam
Kādu vietu aizņems kātra darbinieka personīga vieta, kādu projektiem
kopējas mantas gan visiem (caurstaigājama telpa, ēdnīca utt), gan
katram projektam specifiskas lietas (plaukti ar dokumentāciju, tafeles
utt.)
Jautājums kādas ir prasības lai izvelēties ofisu?
Dotāja situācija - cik vietas jāizdala uz Shared vajadzībam
(kopā=shmall ) un cik jābūt maksimāla Shared Telpa (shmmax).

Kā rēķināt - atkarīgs no jūsu projektu specifikas:
-- vai projektiez iz zināms dzīves cikls, darbi un darbinieku skaits
-- vai izmantotas iekartas (tas arī aizņem vietu) arī konstantas,
mainas
-- vai biežī paradas jaunie projekti vai ir fiksēts skaits

Attiecīgi no tas kas jums ir (zināms) var rēķināt sadalījumu.

Pieeja A - paņemt 75% no kopējas platības un proporcionāli darbinieku
un iekartas skaitam - sadalīt vietu projektiem,
ja tas mainas - var arī mainīt sadalījumu iekš projektos (kādam
pievienot, kādam samazināt), bet idēja - pēc iespējas sadalīt visu
pieejamu (ar kādu rezervi ārkartas situācijām) vietu visiem projketiem
- lai viņiem būtu ērti dzīvot (! bet ir situācijas kad pa daudz vietas
- tikai noslep ka projekts neefektīvi to izmanto, arī vairāk jāmaksa
par kopšanu jo atrītumi (papīrs utt.) aizņem vairak vietas -
management overhead)

Pieeja B - aprēķināt cik ir Min vai Opt ir vajadzīgs katrā projekta
Shared lietam (parasti tas atkarīgs no projekta specifikas un mazāk no
darbinieki skaita)
un attiecīgi skaitam kopēju Shared vietu un Max Shared vietu uz 1
projektu (atiecīgi kaut-kur ofisā jābūt tadai lielai telpai; vai lai
2-3 īstabas (segments)-tas protāms vai tik labi ka 1, bet var
izdzīvot).
Visu palikušu vietu var atstāt personīgai vietai (PGA) un attiecīgi
skaitīt cik darbinieku var sedēt ofisā.

Pieeja A - labāk der - dinamiskam videm - kad projektu (DB) skaits un/
vai dzīves cikls un attiecīgi vajadzīga vieta biežī mainas.
Mazsvārīgākus - krīzes laikā var vispār "apturēt" (lai strādā no majam
un komunicē caur Skype :)
DB - tas ir izstrādes, testēšanas vides (parasti pie izstrādātāja kur
nav tik kritiski lai RAM un citi resursi būtu līdzīgi produkcijai)

Pieeja B - labāk der - statiskam vidēm - ar ierobežotu projektu (DB)
skaitu un daudz-maz zināmu dzīves ciklu. Zinām cik Min/Opt. vajag
shared lietam.
DB - tas ir produkcijas vides - zinām cik vajag SGA lai tas normāli
izpilda regulārus darbus (naktī un dienā sadalījumu var mainīt bet
proporsijas arī ir zināmas).

Tas, manuprāt ir lietas būtība.

Hugepages izmērs ir parasti KB, bet to var precizēt kas tiešī ir jūsu
sistēmai.
Piem.: (Linux):
---------
-bash-3.00$ cat /proc/meminfo |grep -i huge
HugePages_Total:     0
HugePages_Free:      0
Hugepagesize:     2048 kB
------------------

Paldies !

G.A.

2010. gada 1. novembris 11:36 Andrejs Vorobjovs <andrejs.vorobj...@gmail.com

--
G.

Labvakar!

Gribu šo sarunu papildināt ar domas raisinošu citātu no Kevin Closson (
http://kevinclosson.wordpress.com/about/) OOW2010 prezentācijas:
"If you are running OLTP application and not using Hugepages, You are
Crazy!"

br,
Maris Elsins

2010/11/3 Girts Apinis <girts.api...@gmail.com>