Linux Hugepages beállítása Oracle adatbázis számára

     Előző alkalommal leírtam, hogy bizonyos körülmények között mennyire hasznos lehet a Hugepages beállítása, most pedig egy konkrét példát hozok a konfigurációra.

Kiinduló környezet:

     Virtuális környezetben (Természetesen Oracle Virtualbox) került telepítésre egy CentOS 5.10 64 bit 6 Gbyte memóriával, az adatbázis pedig egy 11gR2, létrehoztam egy PROBA nevű adatbázist. Az adatbázist direkt AMM-el hoztam létre, azaz a MEMORY_TARGET init.ora paraméter beállításával az adatbázist összesen 4G memória felhasználásra bíztattam. Korábban már megbeszéltük, hogy AMM esetén nem lehet Hugepages-t beállítani, ezért is kezdem innét.

Vágjunk bele!

     Első lépésben a legfontosabb dolog, hogy az AMM-et megszüntessük. Az AMM-et a memory_max_target és a memory_target initora paraméterek szabályozzák. Sys vagy system felhasználóval belépve először leellenőrizzük a jelenlegi memory_target beállításokat, majd töröljük őket az spfile-ból, végül beállítjuk az új sga_target és pga_aggregate_target értékeket. Íme a szükséges utasítások:

SQL> select NAME,VALUE from v$parameter where name like 'memory%target';
NAME
--------------------------------------------------------------------------------
VALUE
--------------------------------------------------------------------------------
memory_target
4294967296
memory_max_target
4294967296

SQL> alter system reset memory_target scope=spfile;
System altered.
SQL> alter system reset memory_max_target  scope=spfile;
alter system reset memory_max_target  scope=spfile
*
ERROR at line 1:
ORA-32010: cannot find entry to delete in SPFILE
SQL> alter system set sga_target=3G scope=spfile;
System altered.
SQL> alter system set pga_aggregate_target=1G scope=spfile;
System altered.
SQL> 

     A memory_max_target paraméter törlésénél a hiba teljesen normális, mivel az spfile-ban eleve nem volt meg ez a paraméter, értékét a memory_target beállításból kapta. Azért vettem bele most a leírásba, hogy ha valakinél ez is szerepelne, akkor azt is feltétlen törölni kell! Az SGA méretét a jelen beállítással 3Gbyte-ra, a PGA méretét pedig 1Gbyte-ra állítottam. (Figyelem! Ez az SGA/PGA arány most csak találomra lett beállítva, mivel az adatbázis üres, nem használja semmi. Az SGA/PGA arányt minden esetben egyedileg, az aktuális adatbázis felhasználásához szükséges hangolni! )

     Illetve, ha már init.ora paramétereket állítunk, akkor állítsuk be a következőt is:

alter system set use_large_pages=only scope=spfile;

     A use_large_pages=only paraméterrel beállítjuk, hogy az adatbázis csak Hugepages memória területet használhasson az SGA számára. Ezzel elkerüljük, hogy a beállított, lefoglalt Hugepages terület helyett mégis a hagyományos memória területre kerüljön az SGA. Amennyiben nincs jogosultsága, vagy nincs elegendő hely a Hugepages memóriában, akkor az adatbázis elindítása az ORA-27137 hibába fog ütközni.

     Az adatbázis újraindítása után ellenőrizzük le, hogy sikerültek-e a beállítások.

SQL> select NAME,VALUE from v$parameter where name in ('sga_target','memory_target','memory_max_target','pga_aggregate_target');
NAME
--------------------------------------------------------------------------------
VALUE
--------------------------------------------------------------------------------
sga_target
3221225472
memory_target
0
memory_max_target
0
pga_aggregate_target
1073741824
SQL> 

     Következő lépésben ellenőrizzük a szerver jelenlegi Hugepages beállításait, illetve ellenőrizzük a fizikai memória méretét. A /proc/meminfo -ban minden számunkra szükséges információ megtalálható. Fontos, hogy biztosak legyünk a fizikai memória és a Hugepagesize (a Huge memória lap) pontos méretével kapcsolatban.

[oracle@centos-proba ~]$ grep MemTotal /proc/meminfo 
MemTotal:      6113212 kB
[oracle@centos-proba ~]$ grep Huge /proc/meminfo 
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

     Látszik, hogy a szerverben tényleg 6 Gbyte memória van, hogy a Hugepagesize tényleg 2 Mbyte, illetve jelenleg nincs HugePages terület beállítva.

     És akkor most számolunk kicsit. Mekkora is legyen a Hugepages terület? Korábban írtam, hogy csak az SGA terület kerülhet Hugepages-be, a PGA nem. Tehát jelen esetben nagyon egyszerű, a Hugepages területnek 3 Gbyte-nak kell lennie, mivel annyi az SGA is. Amennyiben a szerveren több adatbázis is fut, akkor az összes SGA területet pontosan össze kell adni, és akkora Hugepages területre lesz szükségünk. Pontosan számoljunk, és ne felejtsük el, hogy a fizikai memóriában maradjon hely az összes adatbázis PGA területére, illetve az operációs rendszeren futó összes egyéb programnak is. Tehát

Hugepages memória terület < (Fizikai memória - sum(PGA) - operációs rendszernek és egyéb programoknak szükséges memória)

     A Hugepages terület méretét a vm.nr_hugepages kernel paraméter segítségével lehetséges beállítani. A paraméter a Hugepage lapok számát adja meg, tehát nem méretet, hanem a szükséges lapok számát kell megadunk. vm.nr_hugepages = sum(SGA)/Hugepagesize. Jelen esetben ez (3221225472/1024)kbyte/2048kbyte= 1536. Ami fontos még, hogy érdemes a HugePages területet ennél pár lappal nagyobbra venni, hogy maradjon üres memória lap. Tehát legyen jelen esetben 1540.

     A kernel paramétert a /etc/sysctl.conf állománmyban állíthatjuk be a legegyszerűbben, tehát adjuk hozzá a következő sort (természetesen root jogosultság szükséges)

vm.nr_hugepages=1540

     A kernel paramétert megpróbálhatjuk reboot nélkül is beállítani, de ez valószínű nem lesz sikeres, mivel a kernel a Hugepages területet csak akkor tudja lefoglalni, ha van éppen a fizikai memóriában ennyi összefüggő szabad terület. Azért egy próbát megér, root felhasználóval futtassuk a következő parancsot:

# sysctl -p

     Majd ellenőrizzük, hogy sikerült-e lefoglalni a memória területet:

[root@centos-proba ~]# grep Huge /proc/meminfo 
HugePages_Total:  238
HugePages_Free:   238
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

     Látszik, hogy csak 238 lapot sikerült lefoglalni, a szükséges 1540 helyett. Egy szerver reboot megoldja a problémánkat, de figyeljünk arra, hogy az Oracle adatbázis automatikus indulását még kapcsoljuk ki. Reboot után a következő a helyzet:

[oracle@centos-proba ~]$ grep Huge /proc/meminfo 
HugePages_Total:  1540
HugePages_Free:   1540
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

     Látszik, hogy sikeresen lefoglaltuk a szükséges területet, és jelenleg a teljes terület szabadon használható (mivel nem fut az adatbázisunk).

     Állítsuk be, hogy az oracle user tudja használni ezt a területet. Ehhez a memlock ulimit paramétert (soft és hard) kell beállítanunk. Ezt minimum akkorára állítsuk, amennyi a Hugepages terület mérete, de feltétlenül kisebb legyen, mint a teljes fizikai memória. A paramétert kbyte-ban kell megadni, és a /etc/security/limits.conf állományban lehetésges beállítani. Tehát adjuk hozzá a következő sorokat (természetesen root jogosultság szükséges):

oracle soft   memlock 4194304
oracle hard  memlock 4194304

     Így 4 Gbyte -ra állítottam az oracle user számára. Amennyiben nem oracle user futtatja az adatázist, akkor értelem szerűen az adott user számára kell a paramétert beállítani. Az oracle userrel történő ismételt belépés után ellenőrizzük a paraméter beállítását:

[oracle@centos-proba ~]$ ulimit -Sl
4194304
[oracle@centos-proba ~]$ ulimit -Hl
4194304

     Ezzel lényegében elkészültünk az alap beállítással. Próbáljuk meg elindítani az adatbázist, és ellenőrizzük, hogy tényleg a Hugepages-t használja-e. Amennyiben beállítottuk a use_large_pages=only paramétert, és elindult az adatbázis, akkor biztosak lehetünk benne, hogy Hugepages-t használunk, különben a már említett  ORA-27137 hibát kapnánk. Azért ennél többet is ellenőrizhetünk. Nézzük meg a szokásos /proc/meminfo mit árul el most a rendszerről.

[oracle@centos-proba ~]$ grep Huge /proc/meminfo 
HugePages_Total:  1540
HugePages_Free:   1253
HugePages_Rsvd:   1250
Hugepagesize:     2048 kB

     Mit is tudunk ebből kiolvasni. Látszik, hogy a teljes Hugepages terület a már korábban beállított 1540 lap, ez jó. Látszik, hogy van 1253 még jelenleg üres lap, ami ezért van, mert még csak most indítottuk az adatbázist, és egyszerűen még nem használ minden memóriát, mert nem volt rá szükség. Továbbá az 1253 üres nem használt lapból 1250 foglalva van már, más processz nem veheti el. A Hugepages használata az adatbázis alert.log-ban is látható, ahol minden általunk beállított paraméter szépen ellenőrizhető.

Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Parameter use_large_pages = ONLY
Per process system memlock (soft) limit = 4096 MB

Total Shared Global Region in Large Pages = 3074 MB (100%)

Large Pages used by this instance: 1537 (3074 MB)
Large Pages unused system wide = 3 (6144 KB)
Large Pages configured system wide = 1540 (3080 MB)
Large Page size = 2048 KB
********************************************************************

     A 6-os RedHat verziótól (Tehát Oracle Linux 6 és CentOS 6 is, Illetve SLES 11 szintén) bevezették a Transparent HugePages lehetőséget, ami alap értelmezésben be is van kapcsolva. Ez dinamikus Hugepages allokációt tesz lehetővé, ami elsőre nagyon jól hangzik, azonban sajnos jelenleg nem működik jól az Oracle adatbázissal (11g és 12c sem), tehát ezt ki kell kapcsolni, mielőtt bármit tennénk. A beállítás ellenőrzését a következő utasítással lehet elvégezni:

cat /sys/kernel/mm/transparent_hugepage/enabled

     Amennyiben always vagy madvise, az nekünk sajnos nem jó. A következő scripttel lehetséges a kikapcsolása (ezt célszerű egy ec scriptbe berakni, hogy boot-kor életbe lépjen):

if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
   echo never > /sys/kernel/mm/transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
   echo never > /sys/kernel/mm/transparent_hugepage/defrag
fi

Oracle adatbázis és a Linux Hugepages

     A napokban hívtak egy gyakran nagyon belassuló Red Hat 5 Linux-on futó Oracle 11.2.0 SE adatbázis szervert megvizsgálni. Sokadszorra találkozom a problémával, hogy a szerver a látszólag helyes memória beállítások ellenére intenzíven, egyre nagyobb mértékben használja a swap-et, és az I/O nagy százaléka már csak erre megy el. Az adatbázis persze egyre lassabban válaszol, csörögnek telefonon a felhasználók, hogy "lefagyott a program!".  A szerver csak az adatbázist futtatja, így nem nagyon lehet másra kenni a túlzó memória felhasználást.

     A vizsgálat során természetesen kiderült, hogy azok a memória beállítások mégsem teljesen megfelelőek. Kiderült, hogy nemrég egy új modul lett az alkalmazásban beüzemelve, ami valószínűleg nagyobb PGA területet igényel, és a sok felhasználó miatt rendszeresen túl allokál a PGA (Megjegyzés, hogy az Oracle 12c-ben már a PGA_AGGREGATE_LIMIT paraméter gondoskodhat erről a problémáról, de ezt majd egy másik alkalommal részletezem). Az adatbázis memória paramétereinek átgondolását most nem részletezném, az majd egyszer egy külön téma lesz, most másról szeretnék írni. A problémás szerveren a legnagyobb lassulást az okozta, hogy az Oralce SGA nagy része kikerült a swap területre, miközben a kernel még  pl. rengeteg filesystem cache-t is a memóriában tartott (swappiness kernel paraméterről szintén majd egy következő alkalommal). Tehát, ha el tudjuk érni, hogy az SGA ne kerülhessen swap területre, akkor sokat javulhat az ilyen helyzetekben adatbázisunk elérhetősége. Különösen fontos lehet ez egy olyan környezetben, ahol az adatbázisunk egy szerveren osztozik más memória intenzív alkalmazásokkal. A megoldás a Hugepages beállítása lehet.

     Mi az a Hugepages? Normál esetben az Oracle adatbázis SGA területe a hagyományos memória területre kerül, ami 4K méretű lapokból (pagesize) áll, és a kernel dönti el, hogy az aktuális lap éppen swap, vagy a fizikai memóriában legyen. Nagyobb SGA méret esetén érezhető, hogy a 4K lapméret elég kicsi, így nagyon sok lapot kell nyilvántartani. A sok lap nyilvántartása több memóriát, és több processzoridőt igényel a kernel számára. Ha a memóriában foglalunk területet a Hugepages számára, akkor ott a lapméret 2M lesz (ez a linux kernel alapértelmezése x86_64 környezetben, de bizonyos CPU-k támogatják az 1G méretet is, cpuinfo pdpe1gb). Azt hiszem rögtön érthető, hogy ez mennyivel barátságosabb, hiszen az új lapméret 512 db korábbi lapnak felel meg. Mondjuk egy 8G SGA terület a 4k lapokkal több mint 2 millió lapot tartalmaz, addig Hugepages esetében csupán 4096-ot. Viszont a legfontosabb, hogy a Hugepages terület csak a fizikai memóriában lehet, tehát a kernel semmilyen körülmények között nem írhatja ki a swap területre. A gyakorlatban ez annyit tesz, hogy boot után rögtön elfoglalásra kerül a megadott méretű memória terület. Tehát ez a fizikai memória mindenképp lefoglalásra kerül, még akkor is, ha épp nem fut adatbázisunk. Fontos megemlíteni, hogy mivel csak az oracle felhasználónak adunk jogot a memória területre, ezért nem járhatunk úgy, hogy pl. a szerveren futó java alkalmazás elhasználja a memóriát előlünk. Azt hiszem ez elég jól hangzik, de sajnos van egy dolog, amiről le kell cserébe mondanunk. Az Oracle adatbázis csak az SGA területet tudja Hugepages memóriában tárolni, a PGA-t nem. Ebből adódik, hogy az Oracle 11g-ben megjelent Automatic Memory Management (AMM, MEMORY_TARGET, MEMORY_MAX_TARGET) funkciót nem tudjuk használni. Tehát nem lehetséges az Oracle szerverre bízni az SGA - PGA memória méretek dinamikus állítását, hanem nekünk kell kiszámítani, hogy mennyi SGA-ra, és mennyi PGA-ra lesz szükségünk. Olyan dinamikus környezetekben, ahol gyakran van szükség az SGA / PGA memória arányának a változtatására, sajnos nem ajánlatos a módszer. További hátránya, hogy egy bekapcsolt, üzemelő szerveren szinte képtelenség a Hugepages terület növelése. Tehát, ha növelni szeretnénk az adatbázis SGA területét, ahhoz növelnünk kell a Hugepages területet (hacsak eleve nem volt nagyobb területünk), ami valószínűleg csak a szerver újraindításával lehetséges. 

Összefoglalva

Előnyök:

• jelentősen nagyobb lapméret miatt hatékonyabb, gyorsabb memória kezelés
• garantáltan mindig a fizikai memóriában van az SGA
• a szerveren garantált memória terület az adatbázis SGA számára

Hátrányok:

• Nem lehetséges az Oracle AMM használata
• Az SGA, PGA méretek pontos méretezést igényelnek
• Oracle memória paraméterek megváltoztatása után fontos a Hugepages beállításokat utánállítani
• Hugepages terület valószínűleg csak szerver újraindítással növelhető

Ha tetszik a Hugepages, és szeretnéd kipróbálni saját környezetedben is, akkor látogass vissza pár nap múlva! Nemsokára felteszek egy step by step leírást, ami egy 6Gb memóriával ellátott CentOS 5.10 64 bit-en futó Oracle 11gR2 adatbázis Hugepages beállítását tartalmazza.

Indul a BLOG

Igen, végre szakítottam időt, hogy elkezdjem a blog írását. Immáron több mint 13 éve foglalkozom —szinte kizárólag— Oracle adatbázisokkal, és már régóta érik bennem az ötlet, hogy egy blog formájában megosszam a nagyvilággal az aktuális munkáim során felmerült problémákat, megoldásokat, érdekességeket. Mivel a kezdetektől fogva szabadúszó, önálló szakértőként tevékenykedem, így elég sokféle problémával találkoztam. A blogban megpróbálok olyan megoldásokat adni, amik nem csak Enterprise, hanem Standard Edition verzióban is működnek, kitérve a különböző operációs rendszerek sajátosságaira. Terveimben a világos, egyértelmű technikai megoldások leírása mellett szerepelnek például licenceléssel kapcsolatos bejegyzések is.