I have 2 GB of RAM
After my Linux 32-bit server restarted I've tried to startup
database (11.2.0.1.0) and received error:
SQL> startup
ORA-00845: MEMORY_TARGET not supported on this system
SQL> startup
ORA-00845: MEMORY_TARGET not supported on this system
Quick look to alert log:
Warning: you are trying to use the MEMORY_TARGET feature.This feature requires the /dev/shm file system to be mounted for at least 524288000 bytes.
/dev/shm is either not mounted or is mounted wih available space less than this size.
Please fix this so that MEMORY_TARGET can work as expected.Current available is 503508992 and used is 154742784 bytes.Ensure that the MEMORY_TARGET needs larger /dev/shm.
I
had insufficient /dev/shm mount size for PGA and SGA
which was 400M.
Oracle 11g uses /dev/shm on Linux to manage both SGA and PGA memory as a part of new feature AMM (Automatic Memory Management).
To enable feature all we have to do is set up MEMORY_TARGET parameter which is used instead of SGA_TARGET, and MEMORY_MAX_TARGET which is used instead of SGA_MAX_SIZE.
So if my /dev/shm size is lower then MEMORY_MAX_TARGET I will receive error:
ORA-00845: MEMORY_TARGET not supported on this system
To workaround this problem I have to configure large enough tmpfs on /dev/shm.
So I configured my tmpfs (as root):
Oracle 11g uses /dev/shm on Linux to manage both SGA and PGA memory as a part of new feature AMM (Automatic Memory Management).
To enable feature all we have to do is set up MEMORY_TARGET parameter which is used instead of SGA_TARGET, and MEMORY_MAX_TARGET which is used instead of SGA_MAX_SIZE.
So if my /dev/shm size is lower then MEMORY_MAX_TARGET I will receive error:
ORA-00845: MEMORY_TARGET not supported on this system
To workaround this problem I have to configure large enough tmpfs on /dev/shm.
So I configured my tmpfs (as root):
Method First
# umount tmpfs
# mount -t tmpfs shmfs -o size=1500m /dev/shm
# df -h /dev/shm
Filesystem Size Used Avail Use% Mounted on
shmfs 1.5G 285M 1.2G 19% /dev/shm
But this isn't complete solution, because when your Linux server restarts it will recover old mount settings.
So you have to make this change persistent. To do that just add an entry in /etc/fstab similar to the following:
shmfs /dev/shm
tmpfs size=1500m 0 0
This solves problem!
Method Second
MEMORY_TARGET
Instead of use SGA_TARGET
MEMORY_MAX_SIZE
Instead of use SGA_MAX_SIZE
The default is
half of the physical RAM without swap. When I write something beyond the size
of this mount, it gives an error "No
space left on the disk".
#QUESTION
What happens if one of my processes is running and has used up
almost all of the space in /dev/shm and
I have another process running (outside of /dev/shm) which also
uses more than 50% of RAM space?
Which one is swapped out?
For example, let's say my total physical memory is 40 GB and
tmpfs is 20GB.
One of the processes is using /dev/shm and is about 20GB.
Now there is another process running which takes around 30GB.
Which one of the processes will swap out? Or it cannot be
determined?
#SOLUTION
tmpfs will use swap space when neccessary (it can happen even if
tmpfs size is half of the RAM size, as other things do use RAM too)
and 'half of the RAM' is just the default size (quite sane
defaul) of the filesystem. You may set it to whatever you want
while mounting or remounting it using the 'size' argument:
Mount options for tmpfs
size=nbytes
Override default maximum
size of the filesystem. The size
is
given in bytes, and rounded up to entire pages. The default
is
half of the memory. The size parameter also accepts a
suffix %
to limit this tmpfs instance to that percentage of your physical
RAM: the default, when
neither size nor nr_blocks is specified,
is size=50%
If your distribution uses fstab to mount the tmpfs you may add
e.g. 'size=40G' there. You can also remount it at any time using:
mount -o remount,size=40G /dev/shm
Be careful, though. If files on the tmpfs take too much of your
virtual memory (RAM+swap)
applications may get
killed (byt the OOM killer) and the whole system may crash.
No comments:
Post a Comment