oracle 執行過程中 /dev/shm 下是什麼

同事郵件問我oracle 的主機上 /dev/shm 下有好多檔案，快要把/dev/sdm目錄佔用完了，其實只佔用了62%  呵呵

一、/dev/shm理論
/dev/shm/是linux下一個非常有用的目錄，因為這個目錄不在硬碟上，而是在記憶體裡。因此在linux下，就不需要大費周折去建ramdisk，直接使用/dev/shm/就可達到很好的最佳化效果。 /dev /shm/需要注意的一個是容量問題，在linux下，它預設最大為記憶體的一半大小，使用df -h命令可以看到。但它並不會真正的佔用這塊記憶體，如果/dev/shm/下沒有任何檔案，它佔用的記憶體實際上就是0位元組；如果它最大為1G，裡頭放有 100M檔案，那剩餘的900M仍然可為其它應用程式所使用，但它所佔用的100M記憶體，是絕不會被系統回收重新劃分的，否則誰還敢往裡頭存檔案呢？

預設系統就會載入/dev/shm ，它就是所謂的tmpfs，有人說跟ramdisk（虛擬磁碟），但不一樣。象虛擬磁碟一樣，tmpfs 可以使用您的 RAM，但它也可以使用您的交換分割槽來儲存。而且傳統的虛擬磁碟是個塊裝置，並需要一個 mkfs 之類的命令才能真正地使用它，tmpfs 是一個檔案系統，而不是塊裝置；您只是安裝它，它就可以使用了。
　　tmpfs有以下優勢：
　　1，動態檔案系統的大小。
　　2，tmpfs 的另一個主要的好處是它閃電般的速度。因為典型的 tmpfs 檔案系統會完全駐留在 RAM 中，讀寫幾乎可以是瞬間的。
　　3，tmpfs 資料在重新啟動之後不會保留，因為虛擬記憶體本質上就是易失的。所以有必要做一些指令碼做諸如載入，繫結的操作。

二、修改/dev/shm大小
預設的最大一半記憶體大小在某些場合可能不夠用，並且預設的inode數量很低一般都要調高些，這時可以用mount命令來管理它。
#mount -o size=1500M -o nr_inodes=1000000 -o noatime,nodiratime -o remount /dev/shm
在2G的機器上，將最大容量調到1.5G，並且inode數量調到1000000，這意味著大致可存入最多一百萬個小檔案。

如果需要永久修改/dev/shm的值，需要修改/etc/fstab
tmpfs /dev/shm tmpfs defaults,size=1.5G 0 0
#mount -o remount /dev/shm

三、/dev/shm應用
　　首先在/dev/shm建個tmp資料夾，然後與實際/tmp繫結
　　#mkdir /dev/shm/tmp
　　#chmod 1777 /dev/shm/tmp
　　#mount –bind /dev/shm/tmp /tmp（–bind ）
　　在使用mount –bind olderdir newerdir命令來掛載一個目錄到另一個目錄後，newerdir的許可權和所有者等所有資訊會發生變化。掛載後的目錄繼承了被掛載目錄的所有屬性，除了名稱。Oracle 11g的amm記憶體管理模式就是使用/dev/shm，所以有時候修改MEMORY_TARGET或者MEMORY_MAX_TARGET會出現ORA-00845的錯誤

哪這些ora的一些檔案與asm  檔案是如何來的呢,mos 文件是如是說，原來這是oracle 設計就是這樣的

Oracle Server - Enterprise Edition - Version: 11.1.0.7 to 11.2.0.2 - Release: 11.1 to 11.2
Linux x86
Linux x86-64

Goal

Oracle is creating hundreds of thousands open file descriptors in /dev/shm (open files)

$ lsof -n | grep /dev/shm | wc -l
247455

But there are only just hundreds of files in  /dev/shm

$ ls -l /dev/shm/* | wc -l
262

1. Why is Oracle keeping hundreds of thousands Open File descriptors in /dev/shm while there are just hundreds of files ?

2. Is this a known issue? ( any notes/documents/bug reports/fixes exist).

3. Or is this expected behavior. of oracle?

Solution

1) Let's use a test database (11.1.0.7) to demonstrate how Automatic Memory Management uses file descriptors and why there are so many Open File descriptors.

    

A) Before starting the 11.1.0.7 database, /dev/shm is empty and there are no open files
$ ls -l /dev/shm
total 0
$ lsof -n | grep /dev/shm


B)  Let's start the database, then check /dev/shm

UNIX> sqlplus " / as sysdba"
       SQL*Plus: Release 11.1.0.7.0 - Production on Fri May 6 14:57:28 2011
       Copyright (c) 1982, 2008, Oracle. All rights reserved.
       Connected to an idle instance.

 SQL> startup
       ORACLE instance started.
       Total System Global Area 845348864 bytes
       Fixed Size 1316656 bytes
       Variable Size 578816208 bytes
       Database Buffers 260046848 bytes
       Redo Buffers 5169152 bytes
       Database mounted.
       Database opened.
 

SQL> show parameter memory_target
NAME           TYPE        VALUE
-------------- ----------- ------
memory_target  big integer 808M


SQL> show parameter memory_max_target
  NAME              TYPE          VALUE
 ----------------- ------------- ------
 memory_max_target  big integer  808M


C) let's check /dev/shm again

UNIX> ls -l /dev/shm/* | wc -l
           203
UNIX> lsof -n | grep /dev/shm | wc -l
            4872

Number of files in /dev/shm
-----------------------------------------
There are 203 files  ( 4 MB size, which is the granule size)
This is approximately MEMORY_TARGET/4MB
Since MEMORY_TARGET < 1 GB,  203 x 4 MB files are created

For a larger MEMORY_TARGET,  the number of files in /dev/shm = MEMORY_TARGET/granule size

See Note 947152.1 How to determine granule size.

Number of open files descriptors
------------------------------------------------
There are 4872 open files handles why ?

After starting the 11.1.0.7 database, 24 background processes were created
UNIX> ps -ef | grep -i | wc -l
24


Each background process open 203 files x 24 = 4872
UNIX> lsof -n | grep /dev/shm | wc -l
4872



Please note that there are no connections to the database yet. Oracle is not leaking file descriptors.

For each instance running on the server, each Oracle background process will open files under /dev/shm for the suitable instance. Those files will be opened as long as the database is running. No connections are required


In a dedicated server environment, a dedicated process is created for each database connection.
Each dedicated process needs to connect to /dev/shm shared memory segments, so opens  MEMORY_TARGET/ file descriptors.  In addition, it generates file descriptors for each datafile.

These file descriptors persist until the connections are terminated.


2) That is the expected behavior. and it is also documented in the Reference Manual

Oracle Database Administrator's Reference        
11g Release 1 (11.1) for Linux and UNIX-Based Operating Systems
Part Number B32009-09

Appendix C
Administering Oracle Database on Linux

C.6 Allocating Shared Resources

"The number of file descriptors for each Oracle instance are increased by 512*PROCESSES. Therefore, the maximum number of file descriptors should be at least this value, plus some more for the operating system requirements. For example, if the cat /proc/sys/fs/file-max command returns 32768 and PROCESSES are 100, you can set it to 6815744 or higher as root, to have 51200 available for Oracle."