2024. 6. 24. 23:23ㆍDBMS/ORACLE Admin
서버에서 동작하는 모든 프로세스는 메모리 블록을 사용하기 전에 다른 블록이 점유하고 있는지 확인하기 위해 해당 블록의 SEMAPHORE상태를 먼저 확인하고 SET으로 세팅되어 있으면 대기 후 RELEASE 로 UNSET 되는 순간 세마포어를 SET으로 세팅하여 자원을 사용한다.
SEMMSL (Semaphore Maximum Set Size)
시스템 내에서 여러개의 프로세스가 세마포어를 동시에 사용하여 사용량이 많아지면 여러개를 묶어서 사용하게 되고 SEMMSL은 한 세마포어 세트 내에서 사용할 수 있는 세마포어의 최대 수를 설정할 수 있다.
운영 서버일 경울 기본 값은 100~150개로 설정한다.
SEMMNI (Semaphore Maximum Number of Identifiers)
시스템 전체에서 사용할 수 있는 세마포어 세트의 최대 수를 설정한다.
SEMMNS (Semaphore Maximum Number of Semaphores)
시스템 전체에서 사용할 수 있는 세마포어의 총 수를 설정하며 SEMMSL과 SEMMNI의 곱보다 크거나 같아야 한다.
SEMOPM (Semaphore Operations per semop Call)
1개의 시스템 호출이 초당 호출 가능한 최대 세마포어 개수를 정의한다. 하나의 semop 시스템 호출에서 수행할 수 있는 세마포어 작업의 최대 수를 설정하는 것이다. SEMMSL과 동일하게 설정한다.
~$ ipcs -ls
------ Semaphore Limits --------
max number of arrays = 128 --SEMMNI 값
max semaphores per array = 250 --SEMMSL 값
max semaphores system wide = 32000 --SEMMSN 값
max ops per semop call = 100 --SEMOPM 값
semaphore max value = 32767
SHMMAX
공유 메모리 세그먼트의 최대 크기를 정의한다. ORACLE SGA 공유 메모리는 여러 프로세스가 동시에 접근할 수 있는 메모리 영역으로 용량이 큰 경우가 많기 때문에 커널이 응용 프로그램들에게 메모리를 할당해 줄 때 작게 여러 번 할당하지 않고 한꺼번에 주는 덩어리 세그먼트 사이즈를 SHMMAX라고 한다. 너무 큰 값을 설정하면 시스템 메모리 자원을 비효율적으로 사용할 수 있고, 너무 작은 값을 설정하면 필요한 메모리를 할당받지 못해 프로그램이 정상적으로 동작하지 않을 수 있다.
값을 작게 줬을 때 발생하는 오류
ORA-27123 : unable to attach to shared memory segment
~$ cat /proc/sys/kernel/shmmax
4398046511104
공유 메모리 세그먼트 최대 크기
[root@edydr1p1 ~]# echo "3221225472" > /proc/sys/kernel/shmmax
[root@edydr1p1 ~]# cat /proc/sys/kernel/shmmax
3221225472
[root@edydr1p1 ~]# sysctl -w kernel.shmmax=4398046511104
kernel.shmmax = 4398046511104
[root@edydr1p1 ~]# cat /proc/sys/kernel/shmmax
4398046511104
--적용
[root@edydr1p1 ~]# sysctl -p
크기 변경
SHMMNI
시스템 전체 공유 메모리 세그먼트의 최대 개수
SHMSEG
1개의 프로세스에 부여될 수 있는 공유메모리 세그먼트의 최대 개수를 의미한다. SGA로 사용할 공유 메모리를 오라클에 할당할 때 물리적 메모리가 충분할 경우 하나의 세그먼트에 전체 SGA가 할당될 수 있고 하나의 세그먼트에 할당할 수 없다면 연속된 여러 세그먼트로 분산시켜 할당할 수 있으며 하나의 세그먼트에 할당할 수 없다면 여러 연속 세그먼트로 분산시키거나 연속적이지 않게 분산하여 할당 할 수 있다.
'DBMS > ORACLE Admin' 카테고리의 다른 글
Checkpoint (0) | 2024.06.26 |
---|---|
DATABASE BUFFER CACHE (0) | 2024.06.25 |
증분 백업 (0) | 2024.06.23 |
HR 계정 추가 (0) | 2024.06.17 |
Redo log file과 archive redo log file (0) | 2024.05.27 |