Linux 核心引數 和 Oracle相關引數調整

us_yunleiwang發表於2013-12-05
Linux 核心引數 和 Oracle相關引數調整

 Linux 核心引數的大小和Oracle 有很大的關閉,比如ORA-27102的錯誤,就是因為核心引數的大小不當造成。具體參考Blog

       Upon startup of Linux database get ORA-27102: out of memory Linux-X86_64 Error: 28: No space left on device

       http://blog.itpub.net/23490154/viewspace-1062332/

 

Oracle 11gR2 裡也有一個類似的問題:

       Oracle 11gR2 RAC ORA-00845 MEMORY_TARGET not supported on this system 解決方法

       http://blog.itpub.net/23490154/viewspace-1062336/

 

       安裝Oracle的時候,可以參考Oracle 的安裝文件,來設定相關的值,但是有些引數的值還是需要根據我們自己的情況來進行調整。

 

 

1.  Linux 系統下的核心引數

# vi /etc/sysctl.conf

kernel.shmall = 2097152

kernel.shmmax = 2147483648

kernel.shmmni = 4096

kernel.sem = 250 32000 100 128

fs.file-max = 65536

net.ipv4.ip_local_port_range = 9000 65000

net.core.rmem_default = 4194304

net.core.rmem_max = 4194304

net.core.wmem_default = 262144

net.core.wmem_max = 262144

 

該引數儲存在/etc/sysctl.conf 下,修改該檔案不需要重啟OS,只需要使用如下命令:

# /sbin/sysctl -p

 

就可以讓修改的引數生效。

 

 

2.  kernel.shmmax 引數

2.1 說明

       SHMMAX Available physical memory Defines the maximum allowable size of one shared memory segment. The SHMMAX setting should be large enough to hold the entire SGA in one shared memory segment. A low setting can cause creation of multiple shared memory segments which may lead to performance degradation.

 

       Shmmax 是核心引數中最重要的引數之一,用於定義單個共享記憶體段的最大值,shmmax 設定應該足夠大,能在一個共享記憶體段下容納下整個的SGA ,設定的過低可能會導致需要建立多個共享記憶體段,這樣可能導致系統效能的下降。

       SHMMAX 僅僅是在共享記憶體段被建立的時候用來比較的一個數字,當共享記憶體段被一個程式(Process)建立,作業系統檢查是否被要求的共享記憶體段的值大於shmmax 的值 ,如果是,那麼將會丟擲一個錯誤。這個時候系統會建立另外的一個或多個共享記憶體段滿足程式的需求 。一般來說,共享記憶體段個數和系統效能沒有太直接的關係,也不會對效能產生太大的影響。

 

       在例項啟動以及Server Process 建立的時候,多個小的共享記憶體段可能會導致當時輕微的系統效能的降低(在啟動的時候 需要去建立多個虛擬地址段,在程式建立的時候要讓程式對多個段進行“識別”,會有一些影響),但是其他時候都不會有影響。這意味著如果你的程式不是經常Create Processes(以及Destroy Them,效能方面就不是考慮的問題。

 

     Oralce 建議 SHMMAX > SGA(SGA_MAX_SIZE),這樣在任何時候都不會有甚至輕微的效能下降的隱患。

 

2.2 示例

       在上節說了,如果shmmax 小與SGAOracle 會建立多個共享記憶體段,我們可以使用Ipcs -sa 檢視看到共享記憶體段個數。

 

1)檢視

[root@rac01 ~]# cat /etc/sysctl.conf | grep kernel.shmmax
kernel.shmmax = 20971520
[root@rac01 ~]# ipcs -sa

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status 
0x00000000 65537 oracle 640 4194304 27 
0x00000000 98306 oracle 640 20971520 27 
0x00000000 131075 oracle 640 20971520 27 
0x00000000 163844 oracle 640 20971520 27 
0x00000000 196613 oracle 640 20971520 27 
0x00000000 229382 oracle 640 20971520 27 
0x00000000 262151 oracle 640 20971520 27 
0x00000000 294920 oracle 640 20971520 27 
0xd2776b04 327689 oracle 640 20971520 27 

------ Semaphore Arrays --------
key semid owner perms nsems 
0xfafd7074 360449 oracle 640 104 

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

因為kernel.shmmax設定過小,導致分配了多個共享記憶體段。


下邊改大一些:
[root@rac01 ~]# cat /etc/sysctl.conf | grep kernel.shmmax
kernel.shmmax = 2147483648
[root@rac01 ~]# sysctl -p
[root@rac01 ~]# su - oracle
[oracle@rac01 ~]$ sqlplus '/as sysdba'

SQL*Plus: Release 10.2.0.1.0 - Production on Mon Nov 16 05:50:00 2009

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

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, Real Application Clusters, Oracle Label Security, OLAP
and Data Mining Scoring Engine options

SQL> startup force
ORACLE instance started.

Total System Global Area 167772160 bytes
Fixed Size 1218316 bytes
Variable Size 104859892 bytes
Database Buffers 58720256 bytes
Redo Buffers 2973696 bytes
Database mounted.
Database opened.
SQL> quit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, Real Application Clusters, Oracle Label Security, OLAP
and Data Mining Scoring Engine options

再看一下:
[root@rac01 ~]# ipcs -sa

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status 
0xd2776b04 360449 oracle 640 171966464 27 

------ Semaphore Arrays --------
key semid owner perms nsems 
0xfafd7074 491521 oracle 640 104 

------ Message Queues --------
key msqid owner perms used-bytes messages
只有一個記憶體段分配了

 

3.  kernel.shmall

 

       kernel.shmall 引數是控制共享記憶體頁數。該引數大小為實體記憶體除以pagesize;

 

檢視os系統頁的大小

#getconf PAGESIZE

4096

 

       這裡顯示的pagesize 4k假設一個共享記憶體段的最大大小是16G,那麼需要共享記憶體頁數是16GB/4KB=16777216KB/4KB=4194304 (頁),也就是64Bit 系統下16GB 實體記憶體,設定 kernel.shmall = 4194304 才符合要求,幾乎是原來設定2097152的兩倍。

 

 

4. kernel.shmmni 引數

       shmmni 核心引數是共享記憶體段的最大數量(注意這個引數不是 shmmin,

shmmni, shmmin 表示記憶體段最小大小 )。shmmni 預設值 4096 ,一般肯定是夠用了。

 

 

5. fs.file-max 引數

       fs.file-max512 乘以 processes

       128process,則file-max=512*128=65536

 

 

6.  Oracle 下需要做調整的引數

 

       Oracle 10g 中引入了一個非常重要的引數:SGA_TARGET這也是Oracle 10g的一個新特性。自動共享記憶體管理(Automatic Shared Memory Management ASMM),控制這一特性的,就僅僅是這個引數SGA_TARGE。設定這個引數後,你就不需要為每個記憶體區來指定大小了。SGA_TARGET 指定了SGA 可以使用的最大記憶體大小,而SGA 中各個記憶體的大小由Oracle 自行控制,不需要人為指定。

       Oracle 可以隨時調節各個區域的大小,使之達到系統效能最佳狀態的個最合理大小,並且控制他們之和在SGA_TARGET 指定的值之內。一旦給SGA_TARGET 指定值後(預設為0,即沒有啟動ASMM),就自動啟動了ASMM

特性。

 

       10g 下設定 SGA_TARGET 之後啟動ASSM 特性之後, 只有以下的這些區的記憶體大小動態共享起來:

* Buffer cache (DB_CACHE_SIZE)

* Shared pool (SHARED_POOL_SIZE)

* Large pool (LARGE_POOL_SIZE)

* Java pool (JAVA_POOL_SIZE)

* Streams pool (STREAMS_POOL_SIZE)

 

       SGA 中的其他區域的記憶體大小仍然是固定不共享的。它的含義和SGA_MAX_SIZE 的一樣,也表示SGA 最大的大小,於是它也就有了一個限制,那就是它的大小不能大於SGA_MAX_SIZE 的大小。

       Oracle10g 下, SGA_MAX_SIZE 仍然表示SGA 的大小的上限值,而SGA_TARGET SGA 的所有元件的大小的最大值之和,即當SGA_TARGET< SGA_MAX_SIZE 的時候,oracle 就會忽略SGA_MAX_SIZE 的值,SGA_TARGET 也就成了SGA 的在此例項中的上限制,它能動態改變大小,但是不能夠大於SGA_MAX_SIZE 的值。

 

       SGA_TARGET< SGA_MAX_SIZE 時,例項重啟以後SGA_MAX_SIZE 就變成SGA_TARGET 的大小了。

 

       11g 中,這個SGA_TARGET 只能設定是等於SGA_MAX_SIZE 的大小了,設定比它小,oracle 會自動幫你調整,設定比它大,那還是出錯。現在可以自己想想,oracleSGA_TARGET 的大小處理在往正確的簡單的方向前進中。

 

       SGA_TARGET 帶來一個重要的好處就是,能使SGA 的利用率達到最佳,從而節省記憶體成本。因為ASMM 啟動後,Oracle 會自動根據需要調整各個區域的大小,大大減少了某些區域記憶體緊張,而某些區域又有記憶體空閒的矛盾情況出現。

 

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23490154/viewspace-1062348/,如需轉載,請註明出處,否則將追究法律責任。

相關文章