| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 16. 운영 시스템의 환경 | Fast Forward | Next |
대규모 PostgreSQLInstallation에서는, 곧바로 각종 운영 시스템의 자원 제한을 넘어 버리는 일이 있습니다 (시스템에 따라서는, 실제로 "대규모"인 설치가 아니어도, 출하시의 기본값에서는 너무 낮은 것도 있습니다). 이런 종류의 문제가 발생하면, 이것들을 읽어 주세요.
공유 메모리와 semaphore는 "System V IPC"로 불립니다. (메시지 큐도 똑같습니다만, 이것은 PostgreSQL와는 관계 없습니다). 거의 모든 최신 운영시스템은 이러한 기능을 제공하고 있습니다만, 특히 BSD 유래로 유효하게 되고 있다고는 할 수 없고, 기본값으로 충분한 사이즈가 있다고도 한정하지 않습니다 (Windows판에서는, PostgreSQL는 독자적인 대체적인 구현으로 이러한 기능을 제공하고 있습니다. 이 때문에 본설의 대부분은 무시할 수가 있습니다).
이러한 기능의 완전한 결핍은, 서버 기동시의 Illegal system call에러에 의해 판명됩니다. 그 경우는 커넬을 다시 설정할 수 밖에 없습니다. PostgreSQL는 이러한 기능없이는 움직이지 않습니다.
PostgreSQL가 여러가지IPC의 하드 한도의 하나를 넘으면, 서버는 기동을 거부해, 발생한 문제 및 무엇을 해야 하는지를 설명하는 에러 메세지를 남깁니다 (Section 16.3.1 도 참조해 주세요). 관계하는 커넬 매개변수는 다른 시스템상에서도 통일해 이름이 붙여지고 있습니다 (Table 16-1로 개략을 알 수 있습니다). 그러나 이것들을 설정하기 위한 방법은 다릅니다. 이하에, 몇 개의 플랫폼에 제안을 듭니다. 이러한 설정을 바꾸려면 , 자주 머신을 재기동하는 것이 필요하게 되어, 커넬을 컴파일 다시 할 필요가 있는 경우마저 있을테니 주의해 주세요.
Table 16-1. System V IPC매개변수
| 이름 | 설명 | 적절한 값 |
|---|---|---|
| SHMMAX | 공유 메모리세그먼트의 최대 사이즈(바이트) | 최소 메가바이트(본문을 참조해 주세요) |
| SHMMIN | 공유 메모리세그먼트의 최소 사이즈(바이트) | 1 |
| SHMALL | 사용 가능한 공유 메모리의 총량(바이트 또는 페이지) | 바이트 지정의 경우SHMMAX와 같습니다. 페이지 지정의 경우는 ceil(SHMMAX/PAGE_SIZE)입니다. |
| SHMSEG | 프로세스마다의 공유 메모리세그먼트의 최대수 | 필요한 것은 1 세그먼트(segment) 뿐입니다만, 기본값은 좀 더 많아지고 있습니다 |
| SHMMNI | 시스템 전체의 공유 메모리세그먼트의 최대수 | SHMSEG와 같이 + 다른 어플리케이션용의 공간 |
| SEMMNI | semaphore 식별자의 최대수(즉 세트) | 최저 ceil((max_connections + autovacuum_max_workers) / 16) |
| SEMMNS | 시스템 전체의 semaphore의 최대수 | ceil((max_connections + autovacuum_max_workers) / 16) * 17 + 다른 어플리케이션용의 공간 |
| SEMMSL | 세트마다의 semaphore의 최대수 | |
| SEMMAP | semaphore 맵안의 항목의 수 | 본문을 참조 |
| SEMVMX | semaphore의 최대값 | 최저 1000(기본값은 보통 32767입니다만, 강제당하지 않는 한 바꾸지 말아 주세요) |
공유 메모리에 관한 제일 중요한 매개변수는, 공유 메모리세그먼트의 최대 사이즈의 바이트수 SHMMAX입니다.
만약 shmget로부터 Invalid argument와 같은 에러 메세지를 받았을 경우, 아마 이 상한을 넘고 있습니다.
필요한 공유 메모리세그먼트의 사이즈는 Table 16-2에 나타내는 각종의 PostgreSQL설정 매개변수에 의해 바뀝니다.
(에러시에 출력되는 메세지에는 모두, 할당 요구에 실패한 정확한 사이즈가 기재되어 있습니다. )
에러를 없애기 위한 일시적인 방법으로서 이러한 설정을 낮게 할 수도 있습니다.
SHMMAX를 2 메가바이트로서 PostgreSQL를 가동시킬 수가 있습니다만,
수용할 수 있는 성능을 확보하기 위해서는 꽤 보다 많은 사이즈가 필요합니다.
10 메가바이트 단위로부터 100 메가바이트 단위의 설정을 추천 합니다.
또, 시스템안에는, 시스템에 있어서의 공유 메모리의 총량(SHMALL)에 대한 제한이 있는 것이 있습니다. 이 값을 확실히, PostgreSQL와 공유 메모리세그먼트를 사용하는 다른 어플리케이션의 합계보다 충분히 크게 해 주세요 (경고: 많은 시스템으로, SHMALL는 바이트 단위는 아니고 페이지 단위입니다).
문제가 적은 것은 공유 메모리세그먼트의 최소 사이즈(SHMMIN)로, PostgreSQL에서는 최대에서도 대략 500킬로바이트일 것입니다(통상, 1입니다). 시스템 전체의 세그먼트(segment)의 최대수(SHMMNI) 혹은 프로세스마다의 세그먼트(segment)의 최대수(SHMSEG)에 관해서, 사용하고 있는 시스템에 0으로 설정되어 있지 않은 한, 문제가 일어나는 것은 거의 없습니다. 또, 시스템에 따라서는, 시스템내의 공유 메모리의 합계값에도 제한을 설정해 있습니다. 아래와 같은 플랫폼 고유의 지시를 참조해 주세요.
PostgreSQL는, 허가한 접속(max_connections)마다 1개의 semaphore를 사용해,
16개의 semaphore를 1 집합으로서 취급합니다. 이 집합 각각은 17개째의 semaphore를 가져,
그 semaphore는 다른 어플리케이션에 사용되고 있는 semaphore 세트와의 충돌을 검출하기 위한 "magic number-"를 가지고 있습니다.
시스템 내의 semaphore의 최대수는 SEMMNS에 의해 설정되는 허가된 접속 16개 마다 여분의 1개를 더한 값이상은 없으면 안됩니다
(Table 16-1의 공식을 참조해 주세요).
SEMMNI매개변수는 시스템상에 동시에 존재할 수 있는 semaphore 집합의 수의 상한을 결정합니다.
그러니까 이 매개변수는 적어도 ceil((max_connections + autovacuum_max_workers) / 16)이상은 없으면 안됩니다.
일시적인 실패의 회피책으로서는 허가되는 접속의 수를 내릴 수가 있습니다만, No space left on device라는
혼동하기 쉬운 말이 semget()함수로부터 표시됩니다.
경우에 따라서는 SEMMAP를 적어도 SEMMNS와 동일한 정도로 늘리는 것이 필요하게 되는 경우가 있을지도 모릅니다. 이 매개변수는 semaphore 자원 맵의 사이즈를 정의해, 그 중에서는 유효한 semaphore의 각각의 인접한 블록의 항목이 필요합니다. semaphore 집합이 해제되면, 해제된 블록에 인접하고 이미 존재하는 항목에 추가되는지, 혹은 새로운 맵의 항목아래에 등록됩니다. 맵이 가득찬 경우, 해제된 semaphore는(재기동할 때까지) 없어집니다. semaphore 공간의 단편화에 의해 시간이 지날 때 마다, 유효한 semaphore가 있어야 할 양보다 적게 될 가능성이 있습니다.
1개의 집합안에 몇 개의 semaphore가 있을지를 결정하는 SEMMSL는 PostgreSQL에서는 적어도 17은 없으면 안됩니다.
SEMMNU와 SEMUME와 같은, 그 외의 여러가지 "semaphore undo"에 관한 설정은 PostgreSQL에서는 문제삼을 필요가 없습니다.
공유 메모리. 기본값에서는, 4 메가바이트의 공유 메모리 밖에 지원되지 않습니다. 공유 메모리는 페이징 할 수 없는 것을 기억해 둬 주세요. RAM안에 락 되고 있습니다. 시스템으로 지원되는 공유 버퍼수를 증가하려면 , 커넬 설정 파일에 이하를 추가해 주세요.
options "SHMALL=8192" options "SHMMAX=\(SHMALL*PAGE_SIZE\)"
SHMALL는 4킬로바이트 페이지 단위이므로, 1024라고 하는 값은, 공유 메모리가 4 메가바이트인 것을 나타냅니다. 따라서, 상기에서는, 최대의 공유 메모리 영역을 32 메가바이트까지 증가하고 있습니다. 4.3이후에서는, 아마 KERNEL_VIRTUAL_MB를 기본값의 248보다 늘리지 않으면 안됩니다. 모든 변경을 실시한 후, 커넬을 재컴파일 해, 재부팅해 주세요.
4.0 이전의 릴리스에서는, bpatch를 사용해 현재의 커넬로부터 sysptsize를 검색해 주세요. 이것은 기동시에 자동적으로 계산됩니다.
$ bpatch -r sysptsize 0x9 = 9
그리고, SYSPTSIZE를 커넬 설정 파일내에 하드 코드 한 값으로 해서 추가해 주세요. 이 값을 bpatch를 사용해 찾아낸 값으로 늘려 주세요. 희망 공유 메모리를 4 메가바이트 늘릴 때 마다 1 증가해 주세요.
options "SYSPTSIZE=16"
sysptsize는 sysctl에서는 변경할 수 없습니다.
semaphore. semaphore의 수에 대해서도 늘리고 싶은 경우가 있을지도 모릅니다. 기본값의 시스템 합계인 60이라는 값으로는, 50개의 PostgreSQL접속 밖에 할 수 없습니다. 희망하는 값을 커넬 설정 파일로 설정해 주세요. 예를 들면,
options "SEMMNI=40" options "SEMMNS=240"
기본값의 설정은, 소규모의 설치에서만 적합합니다(예를 들면, 기본값의 SHMMAX는 32 메가바이트입니다). sysctl 또는 loader인터페이스를 사용해 변경을 실시할 수가 있습니다. 이하에서는 sysctl를 사용해 매개변수를 변경하고 있습니다.
$ sysctl -w kern.ipc.shmall=32768 $ sysctl -w kern.ipc.shmmax=134217728 $ sysctl -w kern.ipc.semmap=256
이러한 설정을 재부팅해도 영속화하려면, /etc/sysctl.conf를 변경합니다.
나머지의 semaphore 설정은 sysctl에서는 읽기만으로 간주되고 있습니다만, 기동전에 loaderprompt를 사용해 변경할 수가 있습니다.
(loader) set kern.ipc.semmni=256 (loader) set kern.ipc.semmns=512 (loader) set kern.ipc.semmnu=256
같이 이러한 설정을 재부팅해도 영속화 시키려면 /boot/loader.conf에 보존합니다.
또, 공유 메모리를 RAM상에 남겨, 스왑에의 페이지 아웃을 실시하지 못하게 하고 싶을지도 모릅니다. 이것은 sysctl의 kern.ipc.shm_use_phys설정을 사용해 실현될 수 있습니다.
sysctl의 security.jail.sysvipc_allowed를 유효하게 해 FreeBSD jail를 실행하고 있는 경우, 다른 jail로 실행하는 postmaster을 다른 운영 시스템 사용자로 실행해야합니다. 이것은, 비특권 사용자가 다른 jail의 공유 메모리나 semaphore에 간섭하는 것을 방지할 수 있기 때문에, 보안이 향상합니다. 또, 이것에 의해 PostgreSQL의 IPC를 정리하는 코드를 적절히 동작시킬 수 있습니다. (FreeBSD 6.0이후에서는, IPC 정리 코드는 다른 jail에 있어서의 프로세스를 적절히 검출하지 않고, 다른 jail로 동일 포트로 postmaster를 실행시킬 수가 없습니다. )
FreeBSD버젼 4.0 이전으로는, (후술의) NetBSD와 OpenBSD와 같게 동작합니다.
SYSVSHM옵션과 SYSVSEM옵션은 커넬의 컴파일시에 유효하게 할 필요가 있습니다(기본값에서는 유효하게 되어 있습니다). 공유 메모리의 최대 사이즈는 SHMMAXPGS옵션(페이지수)으로 결정됩니다. 이하에, 여러가지 매개변수의 설정 방법법의 예를 나타냅니다(OpenBSD에서는 대신에 option가 사용되고 있습니다).
options SYSVSHM options SHMMAXPGS=4096 options SHMSEG=256 options SYSVSEM options SEMMNI=256 options SEMMNS=512 options SEMMNU=256 options SEMMAP=256
또, 공유 메모리를 RAM안에 잠그도록 커넬을 설정하는 것으로, 스왑에 페이지 아웃 하지 않게도 할 수 있습니다. sysctl를 사용해 kern.ipc.shm_use_phys를 설정할 수가 있습니다.
기본값의 설정은 일반적인 설치에서는 충분합니다. HP-UX 10에서는 SEMMNS의 출하시의 기본값은 128입니다만, 이것은 대규모 데이터베이스 사이트에는 너무 낮을지도 모릅니다.
IPC매개변수는 시스템 관리 매니저(SAM)로부터 Kernel Configuration->Configurable Parameters아래에서, 설정할 수 있습니다. 끝나면 Create A New Kernel를 눌러 주세요.
기본값의 최대 세그먼트(segment) 사이즈는 32 메가바이트로, 소규모의 PostgreSQL설치에만 적합합니다. 그러나, 이 다른 기본값은 꽤 풍부하게 할당할 수 있어, 보통은 변경할 필요는 없습니다. sysctl인터페이스를 사용해, 최대 공유 메모리세그먼트사이즈를 변경할 수가 있습니다. 예를 들면, 이것을 128 MB로 해, 또, 명시적으로 최대총공유 메모 리사이즈를 2097152 페이지(기본값)로 설정하려면 이하와 같이 합니다.
$ sysctl -w kernel.shmmax=134217728 $ sysctl -w kernel.shmall=2097152
이러한 설정을 재부팅시에 /etc/sysctl.conf에 보존할 수가 있습니다.
오래된 배포물에서는 sysctl프로그램이 존재하지 않을 가능성이 있습니다. 이 경우, /proc파일 시스템에 대한 조작으로 동등의 변경을 실시할 수가 있습니다.
$ echo 134217728 >/proc/sys/kernel/shmmax $ echo 2097152 >/proc/sys/kernel/shmall
OS X 10.2 과 그 보다 일찍, /System/Library/StartupItems/SystemTuning/SystemTuning파일을 편집해 이하의 명령내의 값을 변경합니다.
sysctl -w kern.sysv.shmmax sysctl -w kern.sysv.shmmin sysctl -w kern.sysv.shmmni sysctl -w kern.sysv.shmseg sysctl -w kern.sysv.shmall
OS X 10.3이후에서는, 이러한 명령은 /etc/rc에 이동되었으므로, 거기서 편집해야합니다. 통상 /etc/rc는 OS X의 업데이트(10.3. 6에서 10.3. 7등)으로 덧쓰기되는 것에 주의해 주세요. 그러므로, 각 업데이트 이후에 다시 편집할 필요가 있는 것이라고 생각해야합니다.
OS X 10.3. 9와 그 이후에는, /etc/rc를 편집하는 것이 아니라, 이하와 같은 변수 대입문이 되는, /etc/sysctl.conf라는 명칭의 파일을 작성할 수가 있습니다.
kern.sysv.shmmax=4194304 kern.sysv.shmmin=1 kern.sysv.shmmni=32 kern.sysv.shmseg=8 kern.sysv.shmall=1024
이 방법은, 시스템을 갱신해도 변경점이 보존된다는 점으로, /etc/rc의 편집보다 우수합니다. /etc/sysctl.conf내에 공유 메모리 매개변수 5가지 모두 를 설정해야 한다는 점에 주의해 주세요. 아니면 값이 무시됩니다.
최근의 릴리스의 OS X는, SHMMAX를 4096의 배수 이외에 설정하려고 하면 무시하기 때문에, 주의해 주세요.
이 플랫폼에서는, SHMALL는 4킬로바이트 페이지 단위입니다.
OS X전버젼으로, 공유 메모리매개변수의 변경을 반영시키기 위해서 재부팅이 필요하게 됩니다.
기본값의 설정에서는, 세그먼트(segment) 당 512킬로바이트의 공유 메모리가 허용되고 있습니다. 이 설정을 증가시키려면, 우선, /etc/conf/cf.d디렉토리로 이동합니다. SHMMAX의 현재가를 표시하려면, 이하를 실행합니다.
./configure -y SHMMAX
SHMMAX에 새로운 값을 설정하려면, 이하를 실행합니다.
./configure SHMMAX= value
여기서, value 가 희망하는 새로운 값(바이트 단위)입니다. 그리고, 이하와 같이 커넬을 재구축 해, 재부팅합니다.
./link_unix
적어도 버젼 5.1에서는, 모든 메모리가 공유 메모리로서 사용할 수 있도록 설정되어 있는 것처럼 보입니다. SHMMAX등의 매개변수에 대해서 특별한 설정은 필요 없습니다. 이것은 DB/2등의 다른 데이터베이스에서도 사용되는, 일반적인 설정 방법법입니다.
그러나, /etc/security/limits내의 포괄적인 ulimit정보는 변경해야 할지도 모릅니다. 기본값의 파일 사이즈(fsize)와 파일수(nofiles) 용의 하드 한도는 너무 낮을지도 모르기 때문입니다.
적어도 버젼 2.6에서는, 공유 메모리세그먼트의 기본값의 최대 사이즈는 PostgreSQL에는 너무 낮은 설정이 되어 있습니다. 필요한 설정은 /etc/system로 바꿀 수가 있어 예를 들면 이하와 같이 됩니다.
set shmsys:shminfo_shmmax=0x2000000 set shmsys:shminfo_shmmin=1 set shmsys:shminfo_shmmni=256 set shmsys:shminfo_shmseg=256 set semsys:seminfo_semmap=256 set semsys:seminfo_semmni=512 set semsys:seminfo_semmns=512 set semsys:seminfo_semmsl=32
변경을 반영시키려면 재부팅할 필요가 있습니다.
Solaris환경에서의 공유 메모리에 관한 정보에 대해서는, http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html도 참조해 주세요. Solaris.
UnixWare 7에서는, 공유 메모리세그먼트의 최대 사이즈는 기본값 설정으로 512킬로바이트 밖에 없습니다. 현재의 SHMMAX값을 표시하기 위해서는 아래와 같이를 실행해 주세요.
/etc/conf/bin/idtune -g SHMMAX
이것은 현재가, 기본값, 최소값, 및 최대값을, 바이트 단위로 표시합니다.
/etc/conf/bin/idtune SHMMAX value
여기서 value 는, 희망하는 새로운 값(바이트)입니다. SHMMAX의 설정이 끝나면 커넬을 재구축 해, 재부팅합니다.
/etc/conf/bin/idbuild -B
Table 16-2. PostgreSQL의 공유 메모리 사용량에 영향을 주는 설정 매개변수
| 명칭 | 대체 승수( 1 늘렸을 경우의 바이트수) |
|---|---|
| max_connections | 1800 + 270 * max_locks_per_transaction |
| max_prepared_transactions | 700 + 270 * max_locks_per_transaction |
| shared_buffers | 8300 (BLCKSZ가 8 KB인 것이 전제입니다.) |
| wal_buffers | 8200 (XLOG_BLCKSZ가 8 KB인 것이 전제입니다. ) |
| max_fsm_relations | 70 |
| max_fsm_pages | 6 |
Unix 좋아하는 operating system에서는 PostgreSQL서버의 조작과 관계할 가능성이 있는 여러가지 종류의 자원 제한이 있습니다.
특히 중요한 것은, 사용자마다의 프로세스수의 제한, 프로세스마다의 오픈 파일의 수, 프로세스마다의 이용 가능한 메모리의 양입니다.
이러한 각각 "하드"와 "소프트"의 2개의 제한을 가지고 있습니다.
소프트 제한이 실제로 유효한 제한입니다만, 사용자에 의해 하드 제한까지 바꾸는 것이 가능합니다.
하드 제한은 루트사용자에 의해서만 바꿀 수가 있습니다.
setrlimit시스템 콜이 이러한 매개변수의 설정을 실시합니다.
쉘의 내장 명령ulimit(Bourne 쉘) 혹은 limit(csh)는,
명령 라인으로부터 자원 제한을 제어하기 위해서 사용됩니다.
BSD 파생 시스템상에서는 /etc/login.conf파일이, 로그인시 설정되는 여러가지 자원 제한을 제어합니다.
자세한 것은 운영시스템의 문서를 참조해 주세요.
관련하는 매개변수는 maxproc, openfiles, datasize입니다. 예를 들면,
default:\
...
:datasize-cur=256M:\
:maxproc-cur=256:\
:openfiles-cur=256:\
...
(-cur는 소프트 제한입니다. 하드 제한을 설정하기 위해서는 -max를 붙여 주세요. )
커넬은 몇개의 자원에 대해서, 시스템 전체의 제한을 가지는 도이 가능합니다.
Linux에서는, /proc/sys/fs/file-max가, 커넬이 지워하는 오픈 파일수의 최대를 결정합니다. 이 수를 바꾸기 위해서는, 그 파일에 다른 수를 기입하든가, 혹은 /etc/sysctl.conf에 대입식을 추가합니다. 프로세스마다의 파일의 최대 제한은 커넬이 컴파일 되었을 때에 고정됩니다. 자세한 정보는 /usr/src/linux/Documentation/proc.txt를 참조해 주세요.
PostgreSQL서버는 접속 마다 1개의 프로세스를 사용하므로, 적어도 허가된 접속의 수 만큼의 프로세스와 나머지의 시스템의 필요한 분을 추가한 것이 필요하게 됩니다. 통상, 이것은 문제가 아닙니다만, 1개의 머신상에서 몇개의 서버를 기동하고 있는 경우는 어려운 상황이 될지도 모릅니다.
오픈 파일의 제한의 출하시의 기본값은, 자주 대다수의 사용자는 머신상에서 시스템 자원의 부적절한 부분을 사용하지 않고 "사회적으로 우호적인"값을 설정해 버립니다. 1개의 머신상에서 복수의 서버를 기동하는 경우에 필요하겠지만, 전용 서버에서는 이 제한을 올리고 싶을지도 모릅니다.
반대로, 개개의 프로세스가 다수의 파일을 오픈하는 것을 허가하는 시스템도 있습니다. 그러한 프로세스가 몇 개 이상 있으면, 시스템 전체의 제한은 간단하게 넘어 버립니다. 이 발생을 감지해, 시스템 전체의 제한의 변경을 바라지 않는 경우는, PostgreSQL의 max_files_per_process설정 매개변수를 설정해, 오픈 파일의 소비를 제한할 수가 있습니다.
Linux 2.4이후에서는, 기본값의 가상 메모리의 동작은 PostgreSQL에는 최적이지는 않습니다. 커넬이 메모리 오버커밋을 구현하는 방법이기 때문에, 커넬은, 다른 프로세스에 의존하는 메모리가 시스템의 가상 메모리를 고갈시켰을 경우, PostgreSQL(마스터 서버 프로세스)를 종료시킬 가능성이 있습니다.
이것이 발생했을 경우, 이하와 같은 커넬 메세지가 나타납니다 (이러한 메세지를 검색하는 장소에 대해서는 시스템 문서와 설정을 참조해 주세요).
Out of Memory: Killed process 12345 (postgres).
이것은, postgres프로세스가 메모리 부족 때문에 종료해 버린 것을 나타냅니다. 기동중의 데이터베이스 접속은 정상적으로 작동합니다만, 새로운 접속은 받아들일 수 없습니다. 복구하려면, PostgreSQL를 재시작하지 않으면 안됩니다.
이 문제를 방지하는 1개의 방법으로서 PostgreSQL를 다른 프로세스가 그 머신의 메모리를 고갈시키지 않는 것이 확실하게 머신을 기동하는 것입니다.
Linux 2.6이후에는, 메모리를 "오버커밋"시키지 않게 커넬의 동작을 변경하는, 보다 뛰어난 해법이 있습니다. 이것은, sysctl를 사용해 엄밀한 오버 커밋 모드를 선택하는 것으로 실시됩니다.
sysctl -w vm.overcommit_memory=2
또, 관련하는 vm.overcommit_ratio설정을 변경하는 것이 좋을 것입니다. 자세한 것은 Documentation/vm/overcommit-accounting커넬 문서를 참조해 주세요.
Linux 2.4 커넬의 vender 중에는, 2.6의 오버 커밋sysctl매개변수를 가지는 것이 보고되고 있습니다.
그러나, 관계하는 코드를 가지지 않는 커넬인 vm.overcommit_memory를 2로 설정하는 것은 보다 상황을 악화시킵니다.
2.4의 설치에서는 이것을 시험하기 전에, 실제의 커넬 소스 코드를 조사해,
그 중에 지원하고 있는지 아닌지를 검증하는 것을 추천합니다(mm/mmap.c파일 내의 vm_enough_memory함수를 참조해 주세요).
overcommit-accounting문서 파일의 존재는, 이 기능이 존재하는지 아닌지를 증명하는 것이
없습니다
.
의심스러운 경우는, 사용중의 커넬 vender의 커넬 전문가에게 상담해 주세요.